diff --git a/src/static/support/dist-docs-branch-23.06/index.html b/src/static/support/dist-docs-branch-23.06/index.html new file mode 100644 index 00000000..410c9331 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/index.html @@ -0,0 +1,26 @@ + + + + Open vSwitch 23.06.3 Documentation + +

Open vSwitch 23.06.3 Manpages

+ + + + + + + + + + + + + + + + + + +
ovn-appctl(8)PDF, HTML, plain text
ovn-architecture(7)PDF, HTML, plain text
ovn-controller-vtep(8)PDF, HTML, plain text
ovn-controller(8)PDF, HTML, plain text
ovn-ctl(8)PDF, HTML, plain text
ovn-detrace(1)PDF, HTML, plain text
ovn-ic-nb(5)PDF, HTML, plain text
ovn-ic-nbctl(8)PDF, HTML, plain text
ovn-ic-sb(5)PDF, HTML, plain text
ovn-ic-sbctl(8)PDF, HTML, plain text
ovn-ic(8)PDF, HTML, plain text
ovn-nb(5)PDF, HTML, plain text
ovn-nbctl(8)PDF, HTML, plain text
ovn-northd(8)PDF, HTML, plain text
ovn-sb(5)PDF, HTML, plain text
ovn-sbctl(8)PDF, HTML, plain text
ovn-trace(8)PDF, HTML, plain text
+ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-appctl.8 b/src/static/support/dist-docs-branch-23.06/ovn-appctl.8 new file mode 100644 index 00000000..866f618e --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-appctl.8 @@ -0,0 +1,186 @@ +'\" p +.\" -*- nroff -*- +.TH "ovn-appctl" 8 "ovn-appctl" "OVN 23\[char46]06\[char46]3" "OVN Manual" +.fp 5 L CR \\" Make fixed-width font available as \\fL. +.de TQ +. br +. ns +. TP "\\$1" +.. +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +.de SU +. PP +. I "\\$1" +.. +.PP +.SH "NAME" +.PP +.PP +ovn-appctl \- utility for configuring running OVN daemons +.SH "SYNOPSIS" +.PP +.PP +\fB ovn\-appctl\fR [\-target=target | -t target] [-T secs | \-timeout=secs] \fIcommand\fR [\fIarg\fR\[char46]\[char46]\[char46]] +.PP +\fBovn\-appctl\fR \-help +.PP +\fBovn\-appctl\fR \-version +.SH "DESCRIPTION" +.PP +.PP +OVN daemons accept certain commands at runtime to control their behavior and query their settings\[char46] Every daemon accepts a common set of commands documented under COMMON COMMANDS below\[char46] Some daemons support additional commands documented in their own manpages\[char46] +.PP +.PP +The \fBovn\-appctl\fR program provides a simple way to invoke these commands\[char46] The command to be sent is specified on \fBovn\-appctl\(cqs\fR command line as non-option arguments\[char46] \fBovn\-appctl\fR sends the command and prints the daemon\(cqs response on standard output\[char46] +.PP +.PP +\fBovn\-ctl\fR is exactly similar to Open vSwitch \fBovs\-appctl\fR utility\[char46] +.SH "COMMAND COMMANDS" +.PP +.PP +Every OVN daemon supports a common set of commands, which are documented in this section\[char46] +.SS "General Commands" +.PP +.PP +These commands display daemon-specific commands and the running version\[char46] Note that these commands are different from the \-help and \-version options that return information about the \fBovn\-appctl\fR utility itself\[char46] +.RS +.TP +\fBlist\-commands\fR +Lists the commands supported by the target\[char46] +.TP +\fBversion\fR +Displays the version and compilation date of the target\[char46] +.RE +.SS "Logging Commands" +.PP +.PP +OVN has several log levels\[char46] The highest-severity log level is: +.RS +.TP +\fBoff\fR +No message is ever logged at this level, so setting a logging destination\(cqs log level to off disables logging to that destination\[char46] +.RE +.PP +.PP +The following log levels, in order of descending severity, are available: +.RS +.TP +\fBemer\fR +A major failure forced a process to abort\[char46] +.TP +\fBerr\fR +A high-level operation or a subsystem failed\[char46] Attention is warranted\[char46] +.TP +\fBwarn\fR +A low-level operation failed, but higher-level subsystems may be able to recover\[char46] +.TP +\fBinfo\fR +Information that may be useful in retrospect when investigating a problem\[char46] +.TP +\fBdbg\fR +Information useful only to someone with intricate knowledge of the system, or that would commonly cause too-voluminous log output\[char46] Log messages at this level are not logged by default\[char46] +.RE +.PP +.PP +Every OVN daemon supports the following commands for examining and adjusting log levels\[char46] +.RS +.TP +\fBvlog/list\fR +Lists the known logging modules and their current levels\[char46] +.TP +\fBvlog/list\-pattern\fR +Lists logging pattern used for each destination\[char46] +.TP +\fBvlog/set \fI[spec]\fB\fR +Sets logging levels\[char46] Without any spec, sets the log level for every module and destination to dbg\[char46] Otherwise, spec is a list of words separated by spaces or commas or colons, up to one from each category below: +.RS +.IP \(bu +A valid module name, as displayed by the vlog/list command on ovn-appctl(8), limits the log level change to the specified module\[char46] +.IP \(bu +\fBsyslog\fR, \fBconsole\fR, or \fBfile\fR, to limit the log level change to only to the system log, to the console, or to a file, respectively\[char46] +.IP +On Windows platform, \fBsyslog\fR is accepted as a word and is only useful if the target was started with the \fB\-\-syslog\-target\fR option (the word has no effect otherwise)\[char46] +.IP \(bu +\fBoff\fR, \fBemer\fR, \fBerr\fR, \fBwarn\fR, \fBinfo\fR, or \fBdbg\fR, to control the log level\[char46] Messages of the given severity or higher will be logged, and messages of lower severity will be filtered out\[char46] \fBoff\fR filters out all messages\[char46] +.RE +.IP +Case is not significant within \fIspec\fR\[char46] +.TP +\fBvlog/set PATTERN\fR:\fIdestination\fR: \fIpattern\fR +Sets the log pattern for \fIdestination\fR to \fIpattern\fR\[char46] Each time a message is logged to destination, pattern determines the message\(cqs formatting\[char46] Most characters in pattern are copied literally to the log, but special escapes beginning with \fB%\fR are expanded as follows: +.RS +.IP \(bu +\fB%A\fR : The name of the application logging the message, e\[char46]g\[char46] ovn-controller\[char46] +.IP \(bu +\fB%B\fR : The RFC5424 syslog PRI of the message\[char46] +.IP \(bu +\fB%c\fR : The name of the module (as shown by ovn-appctl \-list) logging the message\[char46] +.IP \(bu +\fB%d\fR : The current date and time in ISO 8601 format (YYYY-MM-DD HH:MM:SS)\[char46] +.IP \(bu +\fB%d\fI{format}\fB\fR : The current date and time in the specified format, which takes the same format as the template argument to strftime(3)\[char46] As an extension, any # characters in format will be replaced by fractional seconds, e\[char46]g\[char46] use \fB%H:%M:%S\[char46]###\fR for the time to the nearest millisecond\[char46] Sub-second times are only approximate and currently decimal places after the third will always be reported as zero\[char46] +.IP \(bu +\fB%D\fR : The current UTC date and time in ISO 8601 format \fB(YYYY\-MM\-DD HH:MM:SS)\fR\[char46] +.IP \(bu +\fB%D\fI{format}\fB\fR : The current UTC date and time in the specified format, which takes the same format as the template argument to strftime(3)\[char46] Supports the same extension for sub-second resolution as \fB%d{\[char46]\[char46]\[char46]}\fR\[char46] +.IP \(bu +\fB%E\fR : The hostname of the node running the application\[char46] +.IP \(bu +\fB%m\fR : The message being logged\[char46] +.IP \(bu +\fB%N\fR : A serial number for this message within this run of the program, as a decimal number\[char46] The first message a program logs has serial number 1, the second one has serial number 2, and so on\[char46] +.IP \(bu +\fB%n\fR : A new-line\[char46] +.IP \(bu +\fB%p\fR : The level at which the message is logged, e\[char46]g\[char46] \fBDBG\fR\[char46] +.IP \(bu +\fB%P\fR : The program\(cqs process ID (pid), as a decimal number\[char46] +.IP \(bu +\fB%r\fR : The number of milliseconds elapsed from the start of the application to the time the message was logged\[char46] +.IP \(bu +\fB%t\fR : The subprogram name, that is, an identifying name for the process or thread that emitted the log message, such as monitor for the process used for \-monitor or main for the primary process or thread in a program\[char46] +.IP \(bu +\fB%T\fR : The subprogram name enclosed in parentheses, e\[char46]g\[char46] (monitor), or the empty string for the primary process or thread in a program\[char46] +.IP \(bu +\fB%%\fR : A literal %\[char46] +.RE +.IP +A few options may appear between the % and the format specifier character, in this order: +.RS +.IP \(bu +\fB\-\fR : Left justify the escape\(cqs expansion within its field width\[char46] Right justification is the default\[char46] +.IP \(bu +\fB\-\fR : Pad the field to the field width with 0s\[char46] Padding with spaces is the default\[char46] +.RE +.IP +\fIwidth\fR A number specifies the minimum field width\[char46] If the escape expands to fewer characters than width then it is padded to fill the field width\[char46] (A field wider than width is not truncated to fit\[char46]) +.IP +The default pattern for console and file output is \fB%D{%Y\-%m\-%dT %H:%M:%SZ}|%05N|%c|%p|%m;\fR for syslog output, \fB%05N|%c|%p|%m\fR\[char46] +.TP +\fBvlog/set FACILITY:\fIfacility\fB\fR +Sets the RFC5424 facility of the log message\[char46] facility can be one of \fBkern\fR, \fBuser\fR, \fBmail\fR, \fBdaemon\fR, \fBauth\fR, \fBsyslog\fR, \fBlpr\fR, \fBnews\fR, \fBuucp\fR, \fBclock\fR, \fBftp\fR, \fBntp\fR, \fBaudit\fR, \fBalert\fR, \fBclock2\fR, \fBlocal0\fR, \fBlocal1\fR, \fBlocal2\fR, \fBlocal3\fR, \fBlocal4\fR, \fBlocal5\fR, \fBlocal6\fR or \fBlocal7\fR\[char46] +.TP +\fBvlog/close\fR +Causes the daemon to close its log file, if it is open\[char46] (Use \fBvlog/reopen\fR to reopen it later\[char46]) +.TP +\fBvlog/reopen\fR +Causes the daemon to close its log file, if it is open, and then reopen it\[char46] (This is useful after rotating log files, to cause a new log file to be used\[char46]) +.IP +This has no effect if the target application was not invoked with the \fB\-\-log\-file\fR option\[char46] +.RE +.SH "OPTIONS" +.TP +\fB\-h\fR +.TQ .5in +\fB\-\-help\fR +Prints a brief help message to the console\[char46] +.TP +\fB\-V\fR +.TQ .5in +\fB\-\-version\fR +Prints version information to the console\[char46] diff --git a/src/static/support/dist-docs-branch-23.06/ovn-appctl.8.html b/src/static/support/dist-docs-branch-23.06/ovn-appctl.8.html new file mode 100644 index 00000000..dac90fb5 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-appctl.8.html @@ -0,0 +1,224 @@ +
+ovn-appctl(8)                     OVN Manual                     ovn-appctl(8)
+
+NAME
+       ovn-appctl - utility for configuring running OVN daemons
+
+SYNOPSIS
+        ovn-appctl [-target=target | -t target] [-T secs | -timeout=secs] comā€
+       mand [arg...]
+
+       ovn-appctl -help
+
+       ovn-appctl -version
+
+DESCRIPTION
+       OVN  daemons accept certain commands at runtime to control their behavā€
+       ior and query their settings. Every daemon accepts a common set of comā€
+       mands documented under COMMON COMMANDS below. Some daemons support  adā€
+       ditional commands documented in their own manpages.
+
+       The  ovn-appctl program provides a simple way to invoke these commands.
+       The command to be sent is specified on  ovn-appctlā€™ā€™s  command  line  as
+       non-option  arguments. ovn-appctl sends the command and prints the daeā€
+       monā€™s response on standard output.
+
+       ovn-ctl is exactly similar to Open vSwitch ovs-appctl utility.
+
+COMMAND COMMANDS
+       Every OVN daemon supports a common set of  commands,  which  are  docuā€
+       mented in this section.
+
+   General Commands
+       These  commands  display  daemon-specific commands and the running verā€
+       sion. Note that these commands are different from the -help  and  -verā€
+       sion  options  that return information about the ovn-appctl utility itā€
+       self.
+
+              list-commands
+                     Lists the commands supported by the target.
+
+              version
+                     Displays the version and compilation date of the target.
+
+   Logging Commands
+       OVN has several log levels. The highest-severity log level is:
+
+              off    No message is ever logged at this  level,  so  setting  a
+                     logging  destinationā€™s  log level to off disables logging
+                     to that destination.
+
+       The following log levels, in order of descending severity,  are  availā€
+       able:
+
+              emer   A major failure forced a process to abort.
+
+              err    A  high-level  operation or a subsystem failed. Attention
+                     is warranted.
+
+              warn   A low-level operation failed, but higher-level subsystems
+                     may be able to recover.
+
+              info   Information that may be useful in retrospect when  invesā€
+                     tigating a problem.
+
+              dbg    Information  useful only to someone with intricate knowlā€
+                     edge of the system, or that would commonly cause  too-voā€
+                     luminous  log  output. Log messages at this level are not
+                     logged by default.
+
+       Every OVN daemon supports the following commands for examining and  adā€
+       justing log levels.
+
+              vlog/list
+                     Lists the known logging modules and their current levels.
+
+              vlog/list-pattern
+                     Lists logging pattern used for each destination.
+
+              vlog/set [spec]
+                     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  on  ovn-appctl(8),  limits  the log level
+                            change to the specified 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.
+
+                            On Windows platform, syslog is accepted as a  word
+                            and  is only useful if the target was started 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.
+
+                     Case is not significant within spec.
+
+              vlog/set PATTERN:destination: pattern
+                     Sets the log pattern for  destination  to  pattern.  Each
+                     time  a  message is logged to destination, pattern deterā€
+                     mines the messageā€™s formatting. Most characters  in  patā€
+                     tern are copied literally to the log, but special escapes
+                     beginning with % are expanded as follows:
+
+                     ā€¢      %A  : The name of the application logging the mesā€
+                            sage, e.g. ovn-controller.
+
+                     ā€¢      %B : The RFC5424 syslog PRI of the message.
+
+                     ā€¢      %c : The name of the module (as shown  by  ovn-apā€
+                            pctl -list) logging the message.
+
+                     ā€¢      %d  : The current date and time in ISO 8601 format
+                            (YYYY-MM-DD HH:MM:SS).
+
+                     ā€¢      %d{format} : The current  date  and  time  in  the
+                            specified  format,  which takes the same format as
+                            the template argument to strftime(3). As an extenā€
+                            sion, any # characters in format will be  replaced
+                            by  fractional  seconds, e.g. use %H:%M:%S.### for
+                            the time to the  nearest  millisecond.  Sub-second
+                            times  are  only approximate and currently decimal
+                            places after the third will always be reported  as
+                            zero.
+
+                     ā€¢      %D  :  The  current  UTC date and time in ISO 8601
+                            format (YYYY-MM-DD HH:MM:SS).
+
+                     ā€¢      %D{format} : The current UTC date and time in  the
+                            specified  format,  which takes the same format as
+                            the template argument to strftime(3). Supports the
+                            same  extension  for  sub-second   resolution   as
+                            %d{...}.
+
+                     ā€¢      %E : The hostname of the node running the applicaā€
+                            tion.
+
+                     ā€¢      %m : The message being logged.
+
+                     ā€¢      %N  : A serial number for this message within this
+                            run of the program, as a decimal number. The first
+                            message a program logs has serial  number  1,  the
+                            second one has serial number 2, and so on.
+
+                     ā€¢      %n : A new-line.
+
+                     ā€¢      %p  :  The  level  at which the message is logged,
+                            e.g. DBG.
+
+                     ā€¢      %P : The programā€™s process ID (pid), as a  decimal
+                            number.
+
+                     ā€¢      %r  :  The number of milliseconds elapsed from the
+                            start of the application to the time  the  message
+                            was logged.
+
+                     ā€¢      %t  : The subprogram name, that is, an identifying
+                            name for the process or thread  that  emitted  the
+                            log  message, such as monitor for the process used
+                            for -monitor or main for the  primary  process  or
+                            thread in a program.
+
+                     ā€¢      %T  : The subprogram name enclosed in parentheses,
+                            e.g. (monitor), or the empty string for  the  priā€
+                            mary process or thread in a program.
+
+                     ā€¢      %% : A literal %.
+
+                     A  few  options  may  appear between the % and the format
+                     specifier character, in this order:
+
+                     ā€¢      - : Left justify the escapeā€™s expansion within its
+                            field width. Right justification is the default.
+
+                     ā€¢      - : Pad the field to  the  field  width  with  0s.
+                            Padding with spaces is the default.
+
+                     width  A number specifies the minimum field width. If the
+                     escape expands to fewer characters than width then it  is
+                     padded to fill the field width. (A field wider than width
+                     is not truncated to fit.)
+
+                     The  default  pattern  for  console  and  file  output is
+                     %D{%Y-%m-%dT %H:%M:%SZ}|%05N|%c|%p|%m; for syslog output,
+                     %05N|%c|%p|%m.
+
+              vlog/set 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, local4, local5, local6 or
+                     local7.
+
+              vlog/close
+                     Causes  the  daemon to close its log file, if it is open.
+                     (Use vlog/reopen to reopen it later.)
+
+              vlog/reopen
+                     Causes the daemon to close its log file, if it  is  open,
+                     and  then  reopen  it. (This is useful after rotating log
+                     files, to cause a new log file to be used.)
+
+                     This has no effect if the target application was not  inā€
+                     voked with the --log-file option.
+
+OPTIONS
+       -h
+       --help
+            Prints a brief help message to the console.
+
+       -V
+       --version
+            Prints version information to the console.
+
+OVN 23.06.3                       ovn-appctl                     ovn-appctl(8)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-appctl.8.pdf b/src/static/support/dist-docs-branch-23.06/ovn-appctl.8.pdf new file mode 100644 index 00000000..25f310d7 Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-appctl.8.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-appctl.8.txt b/src/static/support/dist-docs-branch-23.06/ovn-appctl.8.txt new file mode 100644 index 00000000..914a460a --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-appctl.8.txt @@ -0,0 +1,222 @@ +ovn-appctl(8) OVN Manual ovn-appctl(8) + +NAME + ovn-appctl - utility for configuring running OVN daemons + +SYNOPSIS + ovn-appctl [-target=target | -t target] [-T secs | -timeout=secs] comā€ + mand [arg...] + + ovn-appctl -help + + ovn-appctl -version + +DESCRIPTION + OVN daemons accept certain commands at runtime to control their behavā€ + ior and query their settings. Every daemon accepts a common set of comā€ + mands documented under COMMON COMMANDS below. Some daemons support adā€ + ditional commands documented in their own manpages. + + The ovn-appctl program provides a simple way to invoke these commands. + The command to be sent is specified on ovn-appctlā€ā€™s command line as + non-option arguments. ovn-appctl sends the command and prints the daeā€ + monā€™s response on standard output. + + ovn-ctl is exactly similar to Open vSwitch ovs-appctl utility. + +COMMAND COMMANDS + Every OVN daemon supports a common set of commands, which are docuā€ + mented in this section. + + General Commands + These commands display daemon-specific commands and the running verā€ + sion. Note that these commands are different from the -help and -verā€ + sion options that return information about the ovn-appctl utility itā€ + self. + + list-commands + Lists the commands supported by the target. + + version + Displays the version and compilation date of the target. + + Logging Commands + OVN has several log levels. The highest-severity log level is: + + off No message is ever logged at this level, so setting a + logging destinationā€™s log level to off disables logging + to that destination. + + The following log levels, in order of descending severity, are availā€ + able: + + emer A major failure forced a process to abort. + + err A high-level operation or a subsystem failed. Attention + is warranted. + + warn A low-level operation failed, but higher-level subsystems + may be able to recover. + + info Information that may be useful in retrospect when invesā€ + tigating a problem. + + dbg Information useful only to someone with intricate knowlā€ + edge of the system, or that would commonly cause too-voā€ + luminous log output. Log messages at this level are not + logged by default. + + Every OVN daemon supports the following commands for examining and adā€ + justing log levels. + + vlog/list + Lists the known logging modules and their current levels. + + vlog/list-pattern + Lists logging pattern used for each destination. + + vlog/set [spec] + 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 on ovn-appctl(8), limits the log level + change to the specified 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. + + On Windows platform, syslog is accepted as a word + and is only useful if the target was started 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. + + Case is not significant within spec. + + vlog/set PATTERN:destination: pattern + Sets the log pattern for destination to pattern. Each + time a message is logged to destination, pattern deterā€ + mines the messageā€™s formatting. Most characters in patā€ + tern are copied literally to the log, but special escapes + beginning with % are expanded as follows: + + ā€¢ %A : The name of the application logging the mesā€ + sage, e.g. ovn-controller. + + ā€¢ %B : The RFC5424 syslog PRI of the message. + + ā€¢ %c : The name of the module (as shown by ovn-apā€ + pctl -list) logging the message. + + ā€¢ %d : The current date and time in ISO 8601 format + (YYYY-MM-DD HH:MM:SS). + + ā€¢ %d{format} : The current date and time in the + specified format, which takes the same format as + the template argument to strftime(3). As an extenā€ + sion, any # characters in format will be replaced + by fractional seconds, e.g. use %H:%M:%S.### for + the time to the nearest millisecond. Sub-second + times are only approximate and currently decimal + places after the third will always be reported as + zero. + + ā€¢ %D : The current UTC date and time in ISO 8601 + format (YYYY-MM-DD HH:MM:SS). + + ā€¢ %D{format} : The current UTC date and time in the + specified format, which takes the same format as + the template argument to strftime(3). Supports the + same extension for sub-second resolution as + %d{...}. + + ā€¢ %E : The hostname of the node running the applicaā€ + tion. + + ā€¢ %m : The message being logged. + + ā€¢ %N : A serial number for this message within this + run of the program, as a decimal number. The first + message a program logs has serial number 1, the + second one has serial number 2, and so on. + + ā€¢ %n : A new-line. + + ā€¢ %p : The level at which the message is logged, + e.g. DBG. + + ā€¢ %P : The programā€™s process ID (pid), as a decimal + number. + + ā€¢ %r : The number of milliseconds elapsed from the + start of the application to the time the message + was logged. + + ā€¢ %t : The subprogram name, that is, an identifying + name for the process or thread that emitted the + log message, such as monitor for the process used + for -monitor or main for the primary process or + thread in a program. + + ā€¢ %T : The subprogram name enclosed in parentheses, + e.g. (monitor), or the empty string for the priā€ + mary process or thread in a program. + + ā€¢ %% : A literal %. + + A few options may appear between the % and the format + specifier character, in this order: + + ā€¢ - : Left justify the escapeā€™s expansion within its + field width. Right justification is the default. + + ā€¢ - : Pad the field to the field width with 0s. + Padding with spaces is the default. + + width A number specifies the minimum field width. If the + escape expands to fewer characters than width then it is + padded to fill the field width. (A field wider than width + is not truncated to fit.) + + The default pattern for console and file output is + %D{%Y-%m-%dT %H:%M:%SZ}|%05N|%c|%p|%m; for syslog output, + %05N|%c|%p|%m. + + vlog/set 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, local4, local5, local6 or + local7. + + vlog/close + Causes the daemon to close its log file, if it is open. + (Use vlog/reopen to reopen it later.) + + vlog/reopen + Causes the daemon to close its log file, if it is open, + and then reopen it. (This is useful after rotating log + files, to cause a new log file to be used.) + + This has no effect if the target application was not inā€ + voked with the --log-file option. + +OPTIONS + -h + --help + Prints a brief help message to the console. + + -V + --version + Prints version information to the console. + +OVN 23.06.3 ovn-appctl ovn-appctl(8) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-architecture.7 b/src/static/support/dist-docs-branch-23.06/ovn-architecture.7 new file mode 100644 index 00000000..d21ae4dc --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-architecture.7 @@ -0,0 +1,1207 @@ +'\" p +.\" -*- nroff -*- +.TH "ovn-architecture" 7 "OVN Architecture" "OVN 23\[char46]06\[char46]3" "OVN Manual" +.fp 5 L CR \\" Make fixed-width font available as \\fL. +.de TQ +. br +. ns +. TP "\\$1" +.. +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +.de SU +. PP +. I "\\$1" +.. +.PP +.SH "NAME" +.PP +.PP +ovn-architecture \- Open Virtual Network architecture +.SH "DESCRIPTION" +.PP +.PP +OVN, the Open Virtual Network, is a system to support logical network abstraction in virtual machine and container environments\[char46] OVN complements the existing capabilities of OVS to add native support for logical network abstractions, such as logical L2 and L3 overlays and security groups\[char46] Services such as DHCP are also desirable features\[char46] Just like OVS, OVN\(cqs design goal is to have a production-quality implementation that can operate at significant scale\[char46] +.PP +.PP +A physical network comprises physical wires, switches, and routers\[char46] A \fIvirtual network\fR extends a physical network into a hypervisor or container platform, bridging VMs or containers into the physical network\[char46] An OVN \fIlogical network\fR is a network implemented in software that is insulated from physical (and thus virtual) networks by tunnels or other encapsulations\[char46] This allows IP and other address spaces used in logical networks to overlap with those used on physical networks without causing conflicts\[char46] Logical network topologies can be arranged without regard for the topologies of the physical networks on which they run\[char46] Thus, VMs that are part of a logical network can migrate from one physical machine to another without network disruption\[char46] See \fBLogical Networks\fR, below, for more information\[char46] +.PP +.PP +The encapsulation layer prevents VMs and containers connected to a logical network from communicating with nodes on physical networks\[char46] For clustering VMs and containers, this can be acceptable or even desirable, but in many cases VMs and containers do need connectivity to physical networks\[char46] OVN provides multiple forms of \fIgateways\fR for this purpose\[char46] See \fBGateways\fR, below, for more information\[char46] +.PP +.PP +An OVN deployment consists of several components: +.RS +.IP \(bu +A \fICloud Management System\fR (\fICMS\fR), which is OVN\(cqs ultimate client (via its users and administrators)\[char46] OVN integration requires installing a CMS-specific plugin and related software (see below)\[char46] OVN initially targets OpenStack as CMS\[char46] +.IP +We generally speak of ``the\(cq\(cq CMS, but one can imagine scenarios in which multiple CMSes manage different parts of an OVN deployment\[char46] +.IP \(bu +An OVN Database physical or virtual node (or, eventually, cluster) installed in a central location\[char46] +.IP \(bu +One or more (usually many) \fIhypervisors\fR\[char46] Hypervisors must run Open vSwitch and implement the interface described in \fBDocumentation/topics/integration\[char46]rst\fR in the Open vSwitch source tree\[char46] Any hypervisor platform supported by Open vSwitch is acceptable\[char46] +.IP \(bu +Zero or more \fIgateways\fR\[char46] A gateway extends a tunnel-based logical network into a physical network by bidirectionally forwarding packets between tunnels and a physical Ethernet port\[char46] This allows non-virtualized machines to participate in logical networks\[char46] A gateway may be a physical host, a virtual machine, or an ASIC-based hardware switch that supports the \fBvtep\fR(5) schema\[char46] +.IP +Hypervisors and gateways are together called \fItransport node\fR or \fIchassis\fR\[char46] +.RE +.PP +.PP +The diagram below shows how the major components of OVN and related software interact\[char46] Starting at the top of the diagram, we have: +.RS +.IP \(bu +The Cloud Management System, as defined above\[char46] +.IP \(bu +The \fIOVN/CMS Plugin\fR is the component of the CMS that interfaces to OVN\[char46] In OpenStack, this is a Neutron plugin\[char46] The plugin\(cqs main purpose is to translate the CMS\(cqs notion of logical network configuration, stored in the CMS\(cqs configuration database in a CMS-specific format, into an intermediate representation understood by OVN\[char46] +.IP +This component is necessarily CMS-specific, so a new plugin needs to be developed for each CMS that is integrated with OVN\[char46] All of the components below this one in the diagram are CMS-independent\[char46] +.IP \(bu +The \fIOVN Northbound Database\fR receives the intermediate representation of logical network configuration passed down by the OVN/CMS Plugin\[char46] The database schema is meant to be ``impedance matched\(cq\(cq with the concepts used in a CMS, so that it directly supports notions of logical switches, routers, ACLs, and so on\[char46] See \fBovn\-nb\fR(5) for details\[char46] +.IP +The OVN Northbound Database has only two clients: the OVN/CMS Plugin above it and \fBovn\-northd\fR below it\[char46] +.IP \(bu +\fBovn\-northd\fR(8) connects to the OVN Northbound Database above it and the OVN Southbound Database below it\[char46] It translates the logical network configuration in terms of conventional network concepts, taken from the OVN Northbound Database, into logical datapath flows in the OVN Southbound Database below it\[char46] +.IP \(bu +The \fIOVN Southbound Database\fR is the center of the system\[char46] Its clients are \fBovn\-northd\fR(8) above it and \fBovn\-controller\fR(8) on every transport node below it\[char46] +.IP +The OVN Southbound Database contains three kinds of data: \fIPhysical +Network\fR (PN) tables that specify how to reach hypervisor and other nodes, \fILogical Network\fR (LN) tables that describe the logical network in terms of ``logical datapath flows,\(cq\(cq and \fIBinding\fR tables that link logical network components\(cq locations to the physical network\[char46] The hypervisors populate the PN and Port_Binding tables, whereas \fBovn\-northd\fR(8) populates the LN tables\[char46] +.IP +OVN Southbound Database performance must scale with the number of transport nodes\[char46] This will likely require some work on \fBovsdb\-server\fR(1) as we encounter bottlenecks\[char46] Clustering for availability may be needed\[char46] +.RE +.PP +.PP +The remaining components are replicated onto each hypervisor: +.RS +.IP \(bu +\fBovn\-controller\fR(8) is OVN\(cqs agent on each hypervisor and software gateway\[char46] Northbound, it connects to the OVN Southbound Database to learn about OVN configuration and status and to populate the PN table and the \fBChassis\fR column in \fBBinding\fR table with the hypervisor\(cqs status\[char46] Southbound, it connects to \fBovs\-vswitchd\fR(8) as an OpenFlow controller, for control over network traffic, and to the local \fBovsdb\-server\fR(1) to allow it to monitor and control Open vSwitch configuration\[char46] +.IP \(bu +\fBovs\-vswitchd\fR(8) and \fBovsdb\-server\fR(1) are conventional components of Open vSwitch\[char46] +.RE +.PP +.nf +\fL +.br +\fL CMS +.br +\fL | +.br +\fL | +.br +\fL +\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-+ +.br +\fL | | | +.br +\fL | OVN/CMS Plugin | +.br +\fL | | | +.br +\fL | | | +.br +\fL | OVN Northbound DB | +.br +\fL | | | +.br +\fL | | | +.br +\fL | ovn\-northd | +.br +\fL | | | +.br +\fL +\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-+ +.br +\fL | +.br +\fL | +.br +\fL +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ +.br +\fL | OVN Southbound DB | +.br +\fL +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ +.br +\fL | +.br +\fL | +.br +\fL +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ +.br +\fL | | | +.br +\fL HV 1 | | HV n | +.br +\fL+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ \[char46] +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ +.br +\fL| | | \[char46] | | | +.br +\fL| ovn\-controller | \[char46] | ovn\-controller | +.br +\fL| | | | \[char46] | | | | +.br +\fL| | | | | | | | +.br +\fL| ovs\-vswitchd ovsdb\-server | | ovs\-vswitchd ovsdb\-server | +.br +\fL| | | | +.br +\fL+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ +.br +\fL \fR +.fi +.SS "Information Flow in OVN" +.PP +.PP +Configuration data in OVN flows from north to south\[char46] The CMS, through its OVN/CMS plugin, passes the logical network configuration to \fBovn\-northd\fR via the northbound database\[char46] In turn, \fBovn\-northd\fR compiles the configuration into a lower-level form and passes it to all of the chassis via the southbound database\[char46] +.PP +.PP +Status information in OVN flows from south to north\[char46] OVN currently provides only a few forms of status information\[char46] First, \fBovn\-northd\fR populates the \fBup\fR column in the northbound \fBLogical_Switch_Port\fR table: if a logical port\(cqs \fBchassis\fR column in the southbound \fBPort_Binding\fR table is nonempty, it sets \fBup\fR to \fBtrue\fR, otherwise to \fBfalse\fR\[char46] This allows the CMS to detect when a VM\(cqs networking has come up\[char46] +.PP +.PP +Second, OVN provides feedback to the CMS on the realization of its configuration, that is, whether the configuration provided by the CMS has taken effect\[char46] This feature requires the CMS to participate in a sequence number protocol, which works the following way: +.RS +.IP 1. .4in +When the CMS updates the configuration in the northbound database, as part of the same transaction, it increments the value of the \fBnb_cfg\fR column in the \fBNB_Global\fR table\[char46] (This is only necessary if the CMS wants to know when the configuration has been realized\[char46]) +.IP 2. .4in +When \fBovn\-northd\fR updates the southbound database based on a given snapshot of the northbound database, it copies \fBnb_cfg\fR from northbound \fBNB_Global\fR into the southbound database \fBSB_Global\fR table, as part of the same transaction\[char46] (Thus, an observer monitoring both databases can determine when the southbound database is caught up with the northbound\[char46]) +.IP 3. .4in +After \fBovn\-northd\fR receives confirmation from the southbound database server that its changes have committed, it updates \fBsb_cfg\fR in the northbound \fBNB_Global\fR table to the \fBnb_cfg\fR version that was pushed down\[char46] (Thus, the CMS or another observer can determine when the southbound database is caught up without a connection to the southbound database\[char46]) +.IP 4. .4in +The \fBovn\-controller\fR process on each chassis receives the updated southbound database, with the updated \fBnb_cfg\fR\[char46] This process in turn updates the physical flows installed in the chassis\(cqs Open vSwitch instances\[char46] When it receives confirmation from Open vSwitch that the physical flows have been updated, it updates \fBnb_cfg\fR in its own \fBChassis\fR record in the southbound database\[char46] +.IP 5. .4in +\fBovn\-northd\fR monitors the \fBnb_cfg\fR column in all of the \fBChassis\fR records in the southbound database\[char46] It keeps track of the minimum value among all the records and copies it into the \fBhv_cfg\fR column in the northbound \fBNB_Global\fR table\[char46] (Thus, the CMS or another observer can determine when all of the hypervisors have caught up to the northbound configuration\[char46]) +.RE +.SS "Chassis Setup" +.PP +.PP +Each chassis in an OVN deployment must be configured with an Open vSwitch bridge dedicated for OVN\(cqs use, called the \fIintegration bridge\fR\[char46] System startup scripts may create this bridge prior to starting \fBovn\-controller\fR if desired\[char46] If this bridge does not exist when ovn-controller starts, it will be created automatically with the default configuration suggested below\[char46] The ports on the integration bridge include: +.RS +.IP \(bu +On any chassis, tunnel ports that OVN uses to maintain logical network connectivity\[char46] \fBovn\-controller\fR adds, updates, and removes these tunnel ports\[char46] +.IP \(bu +On a hypervisor, any VIFs that are to be attached to logical networks\[char46] For instances connected through software emulated ports such as TUN/TAP or VETH pairs, the hypervisor itself will normally create ports and plug them into the integration bridge\[char46] For instances connected through representor ports, typically used with hardware offload, the \fBovn\-controller\fR may on CMS direction consult a VIF plug provider for representor port lookup and plug them into the integration bridge (please refer to \fBDocumentation/topics/vif\-plug\-providers/vif\-plug\-providers\[char46]rst +\fR for more information)\[char46] In both cases the conventions described in \fBDocumentation/topics/integration\[char46]rst\fR in the Open vSwitch source tree is followed to ensure mapping between OVN logical port and VIF\[char46] (This is pre-existing integration work that has already been done on hypervisors that support OVS\[char46]) +.IP \(bu +On a gateway, the physical port used for logical network connectivity\[char46] System startup scripts add this port to the bridge prior to starting \fBovn\-controller\fR\[char46] This can be a patch port to another bridge, instead of a physical port, in more sophisticated setups\[char46] +.RE +.PP +.PP +Other ports should not be attached to the integration bridge\[char46] In particular, physical ports attached to the underlay network (as opposed to gateway ports, which are physical ports attached to logical networks) must not be attached to the integration bridge\[char46] Underlay physical ports should instead be attached to a separate Open vSwitch bridge (they need not be attached to any bridge at all, in fact)\[char46] +.PP +.PP +The integration bridge should be configured as described below\[char46] The effect of each of these settings is documented in \fBovs\-vswitchd\[char46]conf\[char46]db\fR(5): +.RS +.TP +\fBfail\-mode=secure\fR +Avoids switching packets between isolated logical networks before \fBovn\-controller\fR starts up\[char46] See \fBController Failure +Settings\fR in \fBovs\-vsctl\fR(8) for more information\[char46] +.TP +\fBother\-config:disable\-in\-band=true\fR +Suppresses in-band control flows for the integration bridge\[char46] It would be unusual for such flows to show up anyway, because OVN uses a local controller (over a Unix domain socket) instead of a remote controller\[char46] It\(cqs possible, however, for some other bridge in the same system to have an in-band remote controller, and in that case this suppresses the flows that in-band control would ordinarily set up\[char46] Refer to the documentation for more information\[char46] +.RE +.PP +.PP +The customary name for the integration bridge is \fBbr\-int\fR, but another name may be used\[char46] +.SS "Logical Networks" +.PP +.PP +Logical network concepts in OVN include \fIlogical switches\fR and \fIlogical routers\fR, the logical version of Ethernet switches and IP routers, respectively\[char46] Like their physical cousins, logical switches and routers can be connected into sophisticated topologies\[char46] Logical switches and routers are ordinarily purely logical entities, that is, they are not associated or bound to any physical location, and they are implemented in a distributed manner at each hypervisor that participates in OVN\[char46] +.PP +.PP +\fILogical switch ports\fR (LSPs) are points of connectivity into and out of logical switches\[char46] There are many kinds of logical switch ports\[char46] The most ordinary kind represent VIFs, that is, attachment points for VMs or containers\[char46] A VIF logical port is associated with the physical location of its VM, which might change as the VM migrates\[char46] (A VIF logical port can be associated with a VM that is powered down or suspended\[char46] Such a logical port has no location and no connectivity\[char46]) +.PP +.PP +\fILogical router ports\fR (LRPs) are points of connectivity into and out of logical routers\[char46] A LRP connects a logical router either to a logical switch or to another logical router\[char46] Logical routers only connect to VMs, containers, and other network nodes indirectly, through logical switches\[char46] +.PP +.PP +Logical switches and logical routers have distinct kinds of logical ports, so properly speaking one should usually talk about logical switch ports or logical router ports\[char46] However, an unqualified ``logical port\(cq\(cq usually refers to a logical switch port\[char46] +.PP +.PP +When a VM sends a packet to a VIF logical switch port, the Open vSwitch flow tables simulate the packet\(cqs journey through that logical switch and any other logical routers and logical switches that it might encounter\[char46] This happens without transmitting the packet across any physical medium: the flow tables implement all of the switching and routing decisions and behavior\[char46] If the flow tables ultimately decide to output the packet at a logical port attached to another hypervisor (or another kind of transport node), then that is the time at which the packet is encapsulated for physical network transmission and sent\[char46] +.ST "Logical Switch Port Types" +.PP +.PP +OVN supports a number of kinds of logical switch ports\[char46] VIF ports that connect to VMs or containers, described above, are the most ordinary kind of LSP\[char46] In the OVN northbound database, VIF ports have an empty string for their \fBtype\fR\[char46] This section describes some of the additional port types\[char46] +.PP +.PP +A \fBrouter\fR logical switch port connects a logical switch to a logical router, designating a particular LRP as its peer\[char46] +.PP +.PP +A \fBlocalnet\fR logical switch port bridges a logical switch to a physical VLAN\[char46] A logical switch may have one or more \fBlocalnet\fR ports\[char46] Such a logical switch is used in two scenarios: +.RS +.IP \(bu +With one or more \fBrouter\fR logical switch ports, to attach L3 gateway routers and distributed gateways to a physical network\[char46] +.IP \(bu +With one or more VIF logical switch ports, to attach VMs or containers directly to a physical network\[char46] In this case, the logical switch is not really logical, since it is bridged to the physical network rather than insulated from it, and therefore cannot have independent but overlapping IP address namespaces, etc\[char46] A deployment might nevertheless choose such a configuration to take advantage of the OVN control plane and features such as port security and ACLs\[char46] +.RE +.PP +.PP +When a logical switch contains multiple \fBlocalnet\fR ports, the following is assumed\[char46] +.RS +.IP \(bu +Each chassis has a bridge mapping for one of the \fBlocalnet\fR physical networks only\[char46] +.IP \(bu +To facilitate interconnectivity between VIF ports of the switch that are located on different chassis with different physical network connectivity, the fabric implements L3 routing between these adjacent physical network segments\[char46] +.RE +.PP +.PP +Note: nothing said above implies that a chassis cannot be plugged to multiple physical networks as long as they belong to different switches\[char46] +.PP +.PP +A \fBlocalport\fR logical switch port is a special kind of VIF logical switch port\[char46] These ports are present in every chassis, not bound to any particular one\[char46] Traffic to such a port will never be forwarded through a tunnel, and traffic from such a port is expected to be destined only to the same chassis, typically in response to a request it received\[char46] OpenStack Neutron uses a \fBlocalport\fR port to serve metadata to VMs\[char46] A metadata proxy process is attached to this port on every host and all VMs within the same network will reach it at the same IP/MAC address without any traffic being sent over a tunnel\[char46] For further details, see the OpenStack documentation for networking-ovn\[char46] +.PP +.PP +LSP types \fBvtep\fR and \fBl2gateway\fR are used for gateways\[char46] See \fBGateways\fR, below, for more information\[char46] +.ST "Implementation Details" +.PP +.PP +These concepts are details of how OVN is implemented internally\[char46] They might still be of interest to users and administrators\[char46] +.PP +.PP +\fILogical datapaths\fR are an implementation detail of logical networks in the OVN southbound database\[char46] \fBovn\-northd\fR translates each logical switch or router in the northbound database into a logical datapath in the southbound database \fBDatapath_Binding\fR table\[char46] +.PP +.PP +For the most part, \fBovn\-northd\fR also translates each logical switch port in the OVN northbound database into a record in the southbound database \fBPort_Binding\fR table\[char46] The latter table corresponds roughly to the northbound \fBLogical_Switch_Port\fR table\[char46] It has multiple types of logical port bindings, of which many types correspond directly to northbound LSP types\[char46] LSP types handled this way include VIF (empty string), \fBlocalnet\fR, \fBlocalport\fR, \fBvtep\fR, and \fBl2gateway\fR\[char46] +.PP +.PP +The \fBPort_Binding\fR table has some types of port binding that do not correspond directly to logical switch port types\[char46] The common is \fBpatch\fR port bindings, known as \fIlogical patch ports\fR\[char46] These port bindings always occur in pairs, and a packet that enters on either side comes out on the other\[char46] \fBovn\-northd\fR connects logical switches and logical routers together using logical patch ports\[char46] +.PP +.PP +Port bindings with types \fBvtep\fR, \fBl2gateway\fR, \fBl3gateway\fR, and \fBchassisredirect\fR are used for gateways\[char46] These are explained in \fBGateways\fR, below\[char46] +.SS "Gateways" +.PP +.PP +Gateways provide limited connectivity between logical networks and physical ones\[char46] They can also provide connectivity between different OVN deployments\[char46] This section will focus on the former, and the latter will be described in details in section \fBOVN Deployments Interconnection\fR\[char46] +.PP +.PP +OVN support multiple kinds of gateways\[char46] +.ST "VTEP Gateways" +.PP +.PP +A ``VTEP gateway\(cq\(cq connects an OVN logical network to a physical (or virtual) switch that implements the OVSDB VTEP schema that accompanies Open vSwitch\[char46] (The ``VTEP gateway\(cq\(cq term is a misnomer, since a VTEP is just a VXLAN Tunnel Endpoint, but it is a well established name\[char46]) See \fBLife +Cycle of a VTEP gateway\fR, below, for more information\[char46] +.PP +.PP +The main intended use case for VTEP gateways is to attach physical servers to an OVN logical network using a physical top-of-rack switch that supports the OVSDB VTEP schema\[char46] +.ST "L2 Gateways" +.PP +.PP +A L2 gateway simply attaches a designated physical L2 segment available on some chassis to a logical network\[char46] The physical network effectively becomes part of the logical network\[char46] +.PP +.PP +To set up a L2 gateway, the CMS adds an \fBl2gateway\fR LSP to an appropriate logical switch, setting LSP options to name the chassis on which it should be bound\[char46] \fBovn\-northd\fR copies this configuration into a southbound \fBPort_Binding\fR record\[char46] On the designated chassis, \fBovn\-controller\fR forwards packets appropriately to and from the physical segment\[char46] +.PP +.PP +L2 gateway ports have features in common with \fBlocalnet\fR ports\[char46] However, with a \fBlocalnet\fR port, the physical network becomes the transport between hypervisors\[char46] With an L2 gateway, packets are still transported between hypervisors over tunnels and the \fBl2gateway\fR port is only used for the packets that are on the physical network\[char46] The application for L2 gateways is similar to that for VTEP gateways, e\[char46]g\[char46] to add non-virtualized machines to a logical network, but L2 gateways do not require special support from top-of-rack hardware switches\[char46] +.ST "L3 Gateway Routers" +.PP +.PP +As described above under \fBLogical Networks\fR, ordinary OVN logical routers are distributed: they are not implemented in a single place but rather in every hypervisor chassis\[char46] This is a problem for stateful services such as SNAT and DNAT, which need to be implemented in a centralized manner\[char46] +.PP +.PP +To allow for this kind of functionality, OVN supports L3 gateway routers, which are OVN logical routers that are implemented in a designated chassis\[char46] Gateway routers are typically used between distributed logical routers and physical networks\[char46] The distributed logical router and the logical switches behind it, to which VMs and containers attach, effectively reside on each hypervisor\[char46] The distributed router and the gateway router are connected by another logical switch, sometimes referred to as a ``join\(cq\(cq logical switch\[char46] (OVN logical routers may be connected to one another directly, without an intervening switch, but the OVN implementation only supports gateway logical routers that are connected to logical switches\[char46] Using a join logical switch also reduces the number of IP addresses needed on the distributed router\[char46]) On the other side, the gateway router connects to another logical switch that has a \fBlocalnet\fR port connecting to the physical network\[char46] +.PP +.PP +The following diagram shows a typical situation\[char46] One or more logical switches LS1, \[char46]\[char46]\[char46], LSn connect to distributed logical router LR1, which in turn connects through LSjoin to gateway logical router GLR, which also connects to logical switch LSlocal, which includes a \fBlocalnet\fR port to attach to the physical network\[char46] +.PP +.nf +\fL +.br +\fL LSlocal +.br +\fL | +.br +\fL GLR +.br +\fL | +.br +\fL LSjoin +.br +\fL | +.br +\fL LR1 +.br +\fL | +.br +\fL +\-\-\-\-+\-\-\-\-+ +.br +\fL | | | +.br +\fL LS1 \[char46]\[char46]\[char46] LSn +.br +\fL \fR +.fi +.PP +.PP +To configure an L3 gateway router, the CMS sets \fBoptions:chassis\fR in the router\(cqs northbound \fBLogical_Router\fR to the chassis\(cqs name\[char46] In response, \fBovn\-northd\fR uses a special \fBl3gateway\fR port binding (instead of a \fBpatch\fR binding) in the southbound database to connect the logical router to its neighbors\[char46] In turn, \fBovn\-controller\fR tunnels packets to this port binding to the designated L3 gateway chassis, instead of processing them locally\[char46] +.PP +.PP +DNAT and SNAT rules may be associated with a gateway router, which provides a central location that can handle one-to-many SNAT (aka IP masquerading)\[char46] Distributed gateway ports, described below, also support NAT\[char46] +.ST "Distributed Gateway Ports" +.PP +.PP +A \fIdistributed gateway port\fR is a logical router port that is specially configured to designate one distinguished chassis, called the \fIgateway chassis\fR, for centralized processing\[char46] A distributed gateway port should connect to a logical switch that has an LSP that connects externally, that is, either a \fBlocalnet\fR LSP or a connection to another OVN deployment (see \fBOVN Deployments +Interconnection\fR)\[char46] Packets that traverse the distributed gateway port are processed without involving the gateway chassis when they can be, but when needed they do take an extra hop through it\[char46] +.PP +.PP +The following diagram illustrates the use of a distributed gateway port\[char46] A number of logical switches LS1, \[char46]\[char46]\[char46], LSn connect to distributed logical router LR1, which in turn connects through the distributed gateway port to logical switch LSlocal that includes a \fBlocalnet\fR port to attach to the physical network\[char46] +.PP +.nf +\fL +.br +\fL LSlocal +.br +\fL | +.br +\fL LR1 +.br +\fL | +.br +\fL +\-\-\-\-+\-\-\-\-+ +.br +\fL | | | +.br +\fL LS1 \[char46]\[char46]\[char46] LSn +.br +\fL \fR +.fi +.PP +.PP +\fBovn\-northd\fR creates two southbound \fBPort_Binding\fR records to represent a distributed gateway port, instead of the usual one\[char46] One of these is a \fBpatch\fR port binding named for the LRP, which is used for as much traffic as it can\[char46] The other one is a port binding with type \fBchassisredirect\fR, named \fBcr\-\fIport\fB\fR\[char46] The \fBchassisredirect\fR port binding has one specialized job: when a packet is output to it, the flow table causes it to be tunneled to the gateway chassis, at which point it is automatically output to the \fBpatch\fR port binding\[char46] Thus, the flow table can output to this port binding in cases where a particular task has to happen on the gateway chassis\[char46] The \fBchassisredirect\fR port binding is not otherwise used (for example, it never receives packets)\[char46] +.PP +.PP +The CMS may configure distributed gateway ports three different ways\[char46] See \fBDistributed Gateway Ports\fR in the documentation for \fBLogical_Router_Port\fR in \fBovn\-nb\fR(5) for details\[char46] +.PP +.PP +Distributed gateway ports support high availability\[char46] When more than one chassis is specified, OVN only uses one at a time as the gateway chassis\[char46] OVN uses BFD to monitor gateway connectivity, preferring the highest-priority gateway that is online\[char46] +.PP +.PP +A logical router can have multiple distributed gateway ports, each connecting different external networks\[char46] Load balancing is not yet supported for logical routers with more than one distributed gateway port configured\[char46] +.SU "Physical VLAN MTU Issues" +.PP +.PP +Consider the preceding diagram again: +.PP +.nf +\fL +.br +\fL LSlocal +.br +\fL | +.br +\fL LR1 +.br +\fL | +.br +\fL +\-\-\-\-+\-\-\-\-+ +.br +\fL | | | +.br +\fL LS1 \[char46]\[char46]\[char46] LSn +.br +\fL \fR +.fi +.PP +.PP +Suppose that each logical switch LS1, \[char46]\[char46]\[char46], LSn is bridged to a physical VLAN-tagged network attached to a \fBlocalnet\fR port on LSlocal, over a distributed gateway port on LR1\[char46] If a packet originating on LS\fIi\fR is destined to the external network, OVN sends it to the gateway chassis over a tunnel\[char46] There, the packet traverses LR1\(cqs logical router pipeline, possibly undergoes NAT, and eventually ends up at LSlocal\(cqs \fBlocalnet\fR port\[char46] If all of the physical links in the network have the same MTU, then the packet\(cqs transit across a tunnel causes an MTU problem: tunnel overhead prevents a packet that uses the full physical MTU from crossing the tunnel to the gateway chassis (without fragmentation)\[char46] +.PP +.PP +OVN offers two solutions to this problem, the \fBreside\-on\-redirect\-chassis\fR and \fBredirect\-type\fR options\[char46] Both solutions require each logical switch LS1, \[char46]\[char46]\[char46], LSn to include a \fBlocalnet\fR logical switch port LN1, \[char46]\[char46]\[char46], LNn respectively, that is present on each chassis\[char46] Both cause packets to be sent over the \fBlocalnet\fR ports instead of tunnels\[char46] They differ in which packets\-some or all\-are sent this way\[char46] The most prominent tradeoff between these options is that \fBreside\-on\-redirect\-chassis\fR is easier to configure and that \fBredirect\-type\fR performs better for east-west traffic\[char46] +.PP +.PP +The first solution is the \fBreside\-on\-redirect\-chassis\fR option for logical router ports\[char46] Setting this option on a LRP from (e\[char46]g\[char46]) LS1 to LR1 disables forwarding from LS1 to LR1 except on the gateway chassis\[char46] On chassis other than the gateway chassis, this single change means that packets that would otherwise have been forwarded to LR1 are instead forwarded to LN1\[char46] The instance of LN1 on the gateway chassis then receives the packet and forwards it to LR1\[char46] The packet traverses the LR1 logical router pipeline, possibly undergoes NAT, and eventually ends up at LSlocal\(cqs \fBlocalnet\fR port\[char46] The packet never traverses a tunnel, avoiding the MTU issue\[char46] +.PP +.PP +This option has the further consequence of centralizing ``distributed\(cq\(cq logical router LR1, since no packets are forwarded from LS1 to LR1 on any chassis other than the gateway chassis\[char46] Therefore, east-west traffic passes through the gateway chassis, not just north-south\[char46] (The naive ``fix\(cq\(cq of allowing east-west traffic to flow directly between chassis over LN1 does not work because routing sets the Ethernet source address to LR1\(cqs source address\[char46] Seeing this single Ethernet source address originate from all of the chassis will confuse the physical switch\[char46]) +.PP +.PP +Do not set the \fBreside\-on\-redirect\-chassis\fR option on a distributed gateway port\[char46] In the diagram above, it would be set on the LRPs connecting LS1, \[char46]\[char46]\[char46], LSn to LR1\[char46] +.PP +.PP +The second solution is the \fBredirect\-type\fR option for distributed gateway ports\[char46] Setting this option to \fBbridged\fR causes packets that are redirected to the gateway chassis to go over the \fBlocalnet\fR ports instead of being tunneled\[char46] This option does not change how OVN treats packets not redirected to the gateway chassis\[char46] +.PP +.PP +The \fBredirect\-type\fR option requires the administrator or the CMS to configure each participating chassis with a unique Ethernet address for the logical router by setting \fBovn\-chassis\-mac\-mappings\fR in the Open vSwitch database, for use by \fBovn\-controller\fR\[char46] This makes it more difficult to configure than \fBreside\-on\-redirect\-chassis\fR\[char46] +.PP +.PP +Set the \fBredirect\-type\fR option on a distributed gateway port\[char46] +.SU "Using Distributed Gateway Ports For Scalability" +.PP +.PP +Although the primary goal of distributed gateway ports is to provide connectivity to external networks, there is a special use case for scalability\[char46] +.PP +.PP +In some deployments, such as the ones using \fBovn\-kubernetes\fR, logical switches are bound to individual chassises, and are connected by a distributed logical router\[char46] In such deployments, the chassis level logical switches are centralized on the chassis instead of distributed, which means the \fBovn\-controller\fR on each chassis doesn\(cqt need to process flows and ports of logical switches on other chassises\[char46] However, without any specific hint, \fBovn\-controller\fR would still process all the logical switches as if they are fully distributed\[char46] In this case, distributed gateway port can be very useful\[char46] The chassis level logical switches can be connected to the distributed router using distributed gateway ports, by setting the gateway chassis (or HA chassis groups with only a single chassis in it) to the chassis that each logical switch is bound to\[char46] \fBovn\-controller\fR would then skip processing the logical switches on all the other chassises, largely improving the scalability, especially when there are a big number of chassises\[char46] +.SS "Life Cycle of a VIF" +.PP +.PP +Tables and their schemas presented in isolation are difficult to understand\[char46] Here\(cqs an example\[char46] +.PP +.PP +A VIF on a hypervisor is a virtual network interface attached either to a VM or a container running directly on that hypervisor (This is different from the interface of a container running inside a VM)\[char46] +.PP +.PP +The steps in this example refer often to details of the OVN and OVN Northbound database schemas\[char46] Please see \fBovn\-sb\fR(5) and \fBovn\-nb\fR(5), respectively, for the full story on these databases\[char46] +.RS +.IP 1. .4in +A VIF\(cqs life cycle begins when a CMS administrator creates a new VIF using the CMS user interface or API and adds it to a switch (one implemented by OVN as a logical switch)\[char46] The CMS updates its own configuration\[char46] This includes associating unique, persistent identifier \fIvif-id\fR and Ethernet address \fImac\fR with the VIF\[char46] +.IP 2. .4in +The CMS plugin updates the OVN Northbound database to include the new VIF, by adding a row to the \fBLogical_Switch_Port\fR table\[char46] In the new row, \fBname\fR is \fIvif-id\fR, \fBmac\fR is \fImac\fR, \fBswitch\fR points to the OVN logical switch\(cqs Logical_Switch record, and other columns are initialized appropriately\[char46] +.IP 3. .4in +\fBovn\-northd\fR receives the OVN Northbound database update\[char46] In turn, it makes the corresponding updates to the OVN Southbound database, by adding rows to the OVN Southbound database \fBLogical_Flow\fR table to reflect the new port, e\[char46]g\[char46] add a flow to recognize that packets destined to the new port\(cqs MAC address should be delivered to it, and update the flow that delivers broadcast and multicast packets to include the new port\[char46] It also creates a record in the \fBBinding\fR table and populates all its columns except the column that identifies the \fBchassis\fR\[char46] +.IP 4. .4in +On every hypervisor, \fBovn\-controller\fR receives the \fBLogical_Flow\fR table updates that \fBovn\-northd\fR made in the previous step\[char46] As long as the VM that owns the VIF is powered off, \fBovn\-controller\fR cannot do much; it cannot, for example, arrange to send packets to or receive packets from the VIF, because the VIF does not actually exist anywhere\[char46] +.IP 5. .4in +Eventually, a user powers on the VM that owns the VIF\[char46] On the hypervisor where the VM is powered on, the integration between the hypervisor and Open vSwitch (described in \fBDocumentation/topics/integration\[char46]rst\fR in the Open vSwitch source tree) adds the VIF to the OVN integration bridge and stores \fIvif-id\fR in \fBexternal_ids\fR:\fBiface\-id\fR to indicate that the interface is an instantiation of the new VIF\[char46] (None of this code is new in OVN; this is pre-existing integration work that has already been done on hypervisors that support OVS\[char46]) +.IP 6. .4in +On the hypervisor where the VM is powered on, \fBovn\-controller\fR notices \fBexternal_ids\fR:\fBiface\-id\fR in the new Interface\[char46] In response, in the OVN Southbound DB, it updates the \fBBinding\fR table\(cqs \fBchassis\fR column for the row that links the logical port from \fBexternal_ids\fR:\fB +iface\-id\fR to the hypervisor\[char46] Afterward, \fBovn\-controller\fR updates the local hypervisor\(cqs OpenFlow tables so that packets to and from the VIF are properly handled\[char46] +.IP 7. .4in +Some CMS systems, including OpenStack, fully start a VM only when its networking is ready\[char46] To support this, \fBovn\-northd\fR notices the \fBchassis\fR column updated for the row in \fBBinding\fR table and pushes this upward by updating the \fBup\fR column in the OVN Northbound database\(cqs \fBLogical_Switch_Port\fR table to indicate that the VIF is now up\[char46] The CMS, if it uses this feature, can then react by allowing the VM\(cqs execution to proceed\[char46] +.IP 8. .4in +On every hypervisor but the one where the VIF resides, \fBovn\-controller\fR notices the completely populated row in the \fBBinding\fR table\[char46] This provides \fBovn\-controller\fR the physical location of the logical port, so each instance updates the OpenFlow tables of its switch (based on logical datapath flows in the OVN DB \fBLogical_Flow\fR table) so that packets to and from the VIF can be properly handled via tunnels\[char46] +.IP 9. .4in +Eventually, a user powers off the VM that owns the VIF\[char46] On the hypervisor where the VM was powered off, the VIF is deleted from the OVN integration bridge\[char46] +.IP 10. .4in +On the hypervisor where the VM was powered off, \fBovn\-controller\fR notices that the VIF was deleted\[char46] In response, it removes the \fBChassis\fR column content in the \fBBinding\fR table for the logical port\[char46] +.IP 11. .4in +On every hypervisor, \fBovn\-controller\fR notices the empty \fBChassis\fR column in the \fBBinding\fR table\(cqs row for the logical port\[char46] This means that \fBovn\-controller\fR no longer knows the physical location of the logical port, so each instance updates its OpenFlow table to reflect that\[char46] +.IP 12. .4in +Eventually, when the VIF (or its entire VM) is no longer needed by anyone, an administrator deletes the VIF using the CMS user interface or API\[char46] The CMS updates its own configuration\[char46] +.IP 13. .4in +The CMS plugin removes the VIF from the OVN Northbound database, by deleting its row in the \fBLogical_Switch_Port\fR table\[char46] +.IP 14. .4in +\fBovn\-northd\fR receives the OVN Northbound update and in turn updates the OVN Southbound database accordingly, by removing or updating the rows from the OVN Southbound database \fBLogical_Flow\fR table and \fBBinding\fR table that were related to the now-destroyed VIF\[char46] +.IP 15. .4in +On every hypervisor, \fBovn\-controller\fR receives the \fBLogical_Flow\fR table updates that \fBovn\-northd\fR made in the previous step\[char46] \fBovn\-controller\fR updates OpenFlow tables to reflect the update, although there may not be much to do, since the VIF had already become unreachable when it was removed from the \fBBinding\fR table in a previous step\[char46] +.RE +.SS "Life Cycle of a Container Interface Inside a VM" +.PP +.PP +OVN provides virtual network abstractions by converting information written in OVN_NB database to OpenFlow flows in each hypervisor\[char46] Secure virtual networking for multi-tenants can only be provided if OVN controller is the only entity that can modify flows in Open vSwitch\[char46] When the Open vSwitch integration bridge resides in the hypervisor, it is a fair assumption to make that tenant workloads running inside VMs cannot make any changes to Open vSwitch flows\[char46] +.PP +.PP +If the infrastructure provider trusts the applications inside the containers not to break out and modify the Open vSwitch flows, then containers can be run in hypervisors\[char46] This is also the case when containers are run inside the VMs and Open vSwitch integration bridge with flows added by OVN controller resides in the same VM\[char46] For both the above cases, the workflow is the same as explained with an example in the previous section (\(dqLife Cycle of a VIF\(dq)\[char46] +.PP +.PP +This section talks about the life cycle of a container interface (CIF) when containers are created in the VMs and the Open vSwitch integration bridge resides inside the hypervisor\[char46] In this case, even if a container application breaks out, other tenants are not affected because the containers running inside the VMs cannot modify the flows in the Open vSwitch integration bridge\[char46] +.PP +.PP +When multiple containers are created inside a VM, there are multiple CIFs associated with them\[char46] The network traffic associated with these CIFs need to reach the Open vSwitch integration bridge running in the hypervisor for OVN to support virtual network abstractions\[char46] OVN should also be able to distinguish network traffic coming from different CIFs\[char46] There are two ways to distinguish network traffic of CIFs\[char46] +.PP +.PP +One way is to provide one VIF for every CIF (1:1 model)\[char46] This means that there could be a lot of network devices in the hypervisor\[char46] This would slow down OVS because of all the additional CPU cycles needed for the management of all the VIFs\[char46] It would also mean that the entity creating the containers in a VM should also be able to create the corresponding VIFs in the hypervisor\[char46] +.PP +.PP +The second way is to provide a single VIF for all the CIFs (1:many model)\[char46] OVN could then distinguish network traffic coming from different CIFs via a tag written in every packet\[char46] OVN uses this mechanism and uses VLAN as the tagging mechanism\[char46] +.RS +.IP 1. .4in +A CIF\(cqs life cycle begins when a container is spawned inside a VM by the either the same CMS that created the VM or a tenant that owns that VM or even a container Orchestration System that is different than the CMS that initially created the VM\[char46] Whoever the entity is, it will need to know the \fIvif-id\fR that is associated with the network interface of the VM through which the container interface\(cqs network traffic is expected to go through\[char46] The entity that creates the container interface will also need to choose an unused VLAN inside that VM\[char46] +.IP 2. .4in +The container spawning entity (either directly or through the CMS that manages the underlying infrastructure) updates the OVN Northbound database to include the new CIF, by adding a row to the \fBLogical_Switch_Port\fR table\[char46] In the new row, \fBname\fR is any unique identifier, \fBparent_name\fR is the \fIvif-id\fR of the VM through which the CIF\(cqs network traffic is expected to go through and the \fBtag\fR is the VLAN tag that identifies the network traffic of that CIF\[char46] +.IP 3. .4in +\fBovn\-northd\fR receives the OVN Northbound database update\[char46] In turn, it makes the corresponding updates to the OVN Southbound database, by adding rows to the OVN Southbound database\(cqs \fBLogical_Flow\fR table to reflect the new port and also by creating a new row in the \fBBinding\fR table and populating all its columns except the column that identifies the \fBchassis\fR\[char46] +.IP 4. .4in +On every hypervisor, \fBovn\-controller\fR subscribes to the changes in the \fBBinding\fR table\[char46] When a new row is created by \fBovn\-northd\fR that includes a value in \fBparent_port\fR column of \fBBinding\fR table, the \fBovn\-controller\fR in the hypervisor whose OVN integration bridge has that same value in \fIvif-id\fR in \fBexternal_ids\fR:\fBiface\-id\fR updates the local hypervisor\(cqs OpenFlow tables so that packets to and from the VIF with the particular VLAN \fBtag\fR are properly handled\[char46] Afterward it updates the \fBchassis\fR column of the \fBBinding\fR to reflect the physical location\[char46] +.IP 5. .4in +One can only start the application inside the container after the underlying network is ready\[char46] To support this, \fBovn\-northd\fR notices the updated \fBchassis\fR column in \fBBinding\fR table and updates the \fBup\fR column in the OVN Northbound database\(cqs \fBLogical_Switch_Port\fR table to indicate that the CIF is now up\[char46] The entity responsible to start the container application queries this value and starts the application\[char46] +.IP 6. .4in +Eventually the entity that created and started the container, stops it\[char46] The entity, through the CMS (or directly) deletes its row in the \fBLogical_Switch_Port\fR table\[char46] +.IP 7. .4in +\fBovn\-northd\fR receives the OVN Northbound update and in turn updates the OVN Southbound database accordingly, by removing or updating the rows from the OVN Southbound database \fBLogical_Flow\fR table that were related to the now-destroyed CIF\[char46] It also deletes the row in the \fBBinding\fR table for that CIF\[char46] +.IP 8. .4in +On every hypervisor, \fBovn\-controller\fR receives the \fBLogical_Flow\fR table updates that \fBovn\-northd\fR made in the previous step\[char46] \fBovn\-controller\fR updates OpenFlow tables to reflect the update\[char46] +.RE +.SS "Architectural Physical Life Cycle of a Packet" +.PP +.PP +This section describes how a packet travels from one virtual machine or container to another through OVN\[char46] This description focuses on the physical treatment of a packet; for a description of the logical life cycle of a packet, please refer to the \fBLogical_Flow\fR table in \fBovn\-sb\fR(5)\[char46] +.PP +.PP +This section mentions several data and metadata fields, for clarity summarized here: +.RS +.TP +tunnel key +When OVN encapsulates a packet in Geneve or another tunnel, it attaches extra data to it to allow the receiving OVN instance to process it correctly\[char46] This takes different forms depending on the particular encapsulation, but in each case we refer to it here as the ``tunnel key\[char46]\(cq\(cq See \fBTunnel Encapsulations\fR, below, for details\[char46] +.TP +logical datapath field +A field that denotes the logical datapath through which a packet is being processed\[char46] OVN uses the field that OpenFlow 1\[char46]1+ simply (and confusingly) calls ``metadata\(cq\(cq to store the logical datapath\[char46] (This field is passed across tunnels as part of the tunnel key\[char46]) +.TP +logical input port field +A field that denotes the logical port from which the packet entered the logical datapath\[char46] OVN stores this in Open vSwitch extension register number 14\[char46] +.IP +Geneve and STT tunnels pass this field as part of the tunnel key\[char46] Ramp switch VXLAN tunnels do not explicitly carry a logical input port, but since they are used to communicate with gateways that from OVN\(cqs perspective consist of only a single logical port, so that OVN can set the logical input port field to this one on ingress to the OVN logical pipeline\[char46] As for regular VXLAN tunnels, they don\(cqt carry input port field at all\[char46] This puts additional limitations on cluster capabilities that are described in \fBTunnel Encapsulations\fR section\[char46] +.TP +logical output port field +A field that denotes the logical port from which the packet will leave the logical datapath\[char46] This is initialized to 0 at the beginning of the logical ingress pipeline\[char46] OVN stores this in Open vSwitch extension register number 15\[char46] +.IP +Geneve, STT and regular VXLAN tunnels pass this field as part of the tunnel key\[char46] Ramp switch VXLAN tunnels do not transmit the logical output port field, and since they do not carry a logical output port field in the tunnel key, when a packet is received from ramp switch VXLAN tunnel by an OVN hypervisor, the packet is resubmitted to table 8 to determine the output port(s); when the packet reaches table 39, these packets are resubmitted to table 40 for local delivery by checking a MLF_RCV_FROM_RAMP flag, which is set when the packet arrives from a ramp tunnel\[char46] +.TP +conntrack zone field for logical ports +A field that denotes the connection tracking zone for logical ports\[char46] The value only has local significance and is not meaningful between chassis\[char46] This is initialized to 0 at the beginning of the logical ingress pipeline\[char46] OVN stores this in Open vSwitch extension register number 13\[char46] +.TP +conntrack zone fields for routers +Fields that denote the connection tracking zones for routers\[char46] These values only have local significance and are not meaningful between chassis\[char46] OVN stores the zone information for north to south traffic (for DNATting or ECMP symmetric replies) in Open vSwitch extension register number 11 and zone information for south to north traffic (for SNATing) in Open vSwitch extension register number 12\[char46] +.TP +logical flow flags +The logical flags are intended to handle keeping context between tables in order to decide which rules in subsequent tables are matched\[char46] These values only have local significance and are not meaningful between chassis\[char46] OVN stores the logical flags in Open vSwitch extension register number 10\[char46] +.TP +VLAN ID +The VLAN ID is used as an interface between OVN and containers nested inside a VM (see \fBLife Cycle of a container interface inside a +VM\fR, above, for more information)\[char46] +.RE +.PP +.PP +Initially, a VM or container on the ingress hypervisor sends a packet on a port attached to the OVN integration bridge\[char46] Then: +.RS +.IP 1. .4in +OpenFlow table 0 performs physical-to-logical translation\[char46] It matches the packet\(cqs ingress port\[char46] Its actions annotate the packet with logical metadata, by setting the logical datapath field to identify the logical datapath that the packet is traversing and the logical input port field to identify the ingress port\[char46] Then it resubmits to table 8 to enter the logical ingress pipeline\[char46] +.IP +Packets that originate from a container nested within a VM are treated in a slightly different way\[char46] The originating container can be distinguished based on the VIF-specific VLAN ID, so the physical-to-logical translation flows additionally match on VLAN ID and the actions strip the VLAN header\[char46] Following this step, OVN treats packets from containers just like any other packets\[char46] +.IP +Table 0 also processes packets that arrive from other chassis\[char46] It distinguishes them from other packets by ingress port, which is a tunnel\[char46] As with packets just entering the OVN pipeline, the actions annotate these packets with logical datapath metadata\[char46] For tunnel types that support it, they are also annotated with logical ingress port metadata\[char46] In addition, the actions set the logical output port field, which is available because in OVN tunneling occurs after the logical output port is known\[char46] These pieces of information are obtained from the tunnel encapsulation metadata (see \fBTunnel +Encapsulations\fR for encoding details)\[char46] Then the actions resubmit to table 38 to enter the logical egress pipeline\[char46] +.IP 2. .4in +OpenFlow tables 8 through 31 execute the logical ingress pipeline from the \fBLogical_Flow\fR table in the OVN Southbound database\[char46] These tables are expressed entirely in terms of logical concepts like logical ports and logical datapaths\[char46] A big part of \fBovn\-controller\fR\(cqs job is to translate them into equivalent OpenFlow (in particular it translates the table numbers: \fBLogical_Flow\fR tables 0 through 23 become OpenFlow tables 8 through 31)\[char46] +.IP +Each logical flow maps to one or more OpenFlow flows\[char46] An actual packet ordinarily matches only one of these, although in some cases it can match more than one of these flows (which is not a problem because all of them have the same actions)\[char46] \fBovn\-controller\fR uses the first 32 bits of the logical flow\(cqs UUID as the cookie for its OpenFlow flow or flows\[char46] (This is not necessarily unique, since the first 32 bits of a logical flow\(cqs UUID is not necessarily unique\[char46]) +.IP +Some logical flows can map to the Open vSwitch ``conjunctive match\(cq\(cq extension (see \fBovs\-fields\fR(7))\[char46] Flows with a \fBconjunction\fR action use an OpenFlow cookie of 0, because they can correspond to multiple logical flows\[char46] The OpenFlow flow for a conjunctive match includes a match on \fBconj_id\fR\[char46] +.IP +Some logical flows may not be represented in the OpenFlow tables on a given hypervisor, if they could not be used on that hypervisor\[char46] For example, if no VIF in a logical switch resides on a given hypervisor, and the logical switch is not otherwise reachable on that hypervisor (e\[char46]g\[char46] over a series of hops through logical switches and routers starting from a VIF on the hypervisor), then the logical flow may not be represented there\[char46] +.IP +Most OVN actions have fairly obvious implementations in OpenFlow (with OVS extensions), e\[char46]g\[char46] \fBnext;\fR is implemented as \fBresubmit\fR, \fB\fIfield\fB = +\fIconstant\fB;\fR as \fBset_field\fR\[char46] A few are worth describing in more detail: +.RS +.TP +\fBoutput:\fR +Implemented by resubmitting the packet to table 37\[char46] If the pipeline executes more than one \fBoutput\fR action, then each one is separately resubmitted to table 37\[char46] This can be used to send multiple copies of the packet to multiple ports\[char46] (If the packet was not modified between the \fBoutput\fR actions, and some of the copies are destined to the same hypervisor, then using a logical multicast output port would save bandwidth between hypervisors\[char46]) +.TP +\fBget_arp(\fIP\fB, \fIA\fB);\fR +.TQ .5in +\fBget_nd(\fIP\fB, \fIA\fB);\fR +Implemented by storing arguments into OpenFlow fields, then resubmitting to table 66, which \fBovn\-controller\fR populates with flows generated from the \fBMAC_Binding\fR table in the OVN Southbound database\[char46] If there is a match in table 66, then its actions store the bound MAC in the Ethernet destination address field\[char46] +.IP +(The OpenFlow actions save and restore the OpenFlow fields used for the arguments, so that the OVN actions do not have to be aware of this temporary use\[char46]) +.TP +\fBput_arp(\fIP\fB, \fIA\fB, \fIE\fB);\fR +.TQ .5in +\fBput_nd(\fIP\fB, \fIA\fB, \fIE\fB);\fR +Implemented by storing the arguments into OpenFlow fields, then outputting a packet to \fBovn\-controller\fR, which updates the \fBMAC_Binding\fR table\[char46] +.IP +(The OpenFlow actions save and restore the OpenFlow fields used for the arguments, so that the OVN actions do not have to be aware of this temporary use\[char46]) +.TP +\fB\fIR\fB = lookup_arp(\fIP\fB, \fIA\fB, \fIM\fB);\fR +.TQ .5in +\fB\fIR\fB = lookup_nd(\fIP\fB, \fIA\fB, \fIM\fB);\fR +Implemented by storing arguments into OpenFlow fields, then resubmitting to table 67, which \fBovn\-controller\fR populates with flows generated from the \fBMAC_Binding\fR table in the OVN Southbound database\[char46] If there is a match in table 67, then its actions set the logical flow flag \fBMLF_LOOKUP_MAC\fR\[char46] +.IP +(The OpenFlow actions save and restore the OpenFlow fields used for the arguments, so that the OVN actions do not have to be aware of this temporary use\[char46]) +.RE +.IP 3. .4in +OpenFlow tables 37 through 41 implement the \fBoutput\fR action in the logical ingress pipeline\[char46] Specifically, table 37 serves as an entry point to egress pipeline\[char46] Table 37 detects IP packets that are too big for a corresponding interface\[char46] Table 38 produces ICMPv4 Fragmentation Needed (or ICMPv6 Too Big) errors and deliver them back to the offending port\[char46] table 39 handles packets to remote hypervisors, table 40 handles packets to the local hypervisor, and table 41 checks whether packets whose logical ingress and egress port are the same should be discarded\[char46] +.IP +Logical patch ports are a special case\[char46] Logical patch ports do not have a physical location and effectively reside on every hypervisor\[char46] Thus, flow table 40, for output to ports on the local hypervisor, naturally implements output to unicast logical patch ports too\[char46] However, applying the same logic to a logical patch port that is part of a logical multicast group yields packet duplication, because each hypervisor that contains a logical port in the multicast group will also output the packet to the logical patch port\[char46] Thus, multicast groups implement output to logical patch ports in table 39\[char46] +.IP +Each flow in table 39 matches on a logical output port for unicast or multicast logical ports that include a logical port on a remote hypervisor\[char46] Each flow\(cqs actions implement sending a packet to the port it matches\[char46] For unicast logical output ports on remote hypervisors, the actions set the tunnel key to the correct value, then send the packet on the tunnel port to the correct hypervisor\[char46] (When the remote hypervisor receives the packet, table 0 there will recognize it as a tunneled packet and pass it along to table 40\[char46]) For multicast logical output ports, the actions send one copy of the packet to each remote hypervisor, in the same way as for unicast destinations\[char46] If a multicast group includes a logical port or ports on the local hypervisor, then its actions also resubmit to table 40\[char46] Table 39 also includes: +.RS +.IP \(bu +A higher-priority rule to match packets received from ramp switch tunnels, based on flag MLF_RCV_FROM_RAMP, and resubmit these packets to table 40 for local delivery\[char46] Packets received from ramp switch tunnels reach here because of a lack of logical output port field in the tunnel key and thus these packets needed to be submitted to table 8 to determine the output port\[char46] +.IP \(bu +A higher-priority rule to match packets received from ports of type \fBlocalport\fR, based on the logical input port, and resubmit these packets to table 40 for local delivery\[char46] Ports of type \fBlocalport\fR exist on every hypervisor and by definition their traffic should never go out through a tunnel\[char46] +.IP \(bu +A higher-priority rule to match packets that have the MLF_LOCAL_ONLY logical flow flag set, and whose destination is a multicast address\[char46] This flag indicates that the packet should not be delivered to remote hypervisors, even if the multicast destination includes ports on remote hypervisors\[char46] This flag is used when \fBovn\-controller\fR is the originator of the multicast packet\[char46] Since each \fBovn\-controller\fR instance is originating these packets, the packets only need to be delivered to local ports\[char46] +.IP \(bu +A fallback flow that resubmits to table 40 if there is no other match\[char46] +.RE +.IP +Flows in table 40 resemble those in table 39 but for logical ports that reside locally rather than remotely\[char46] For unicast logical output ports on the local hypervisor, the actions just resubmit to table 41\[char46] For multicast output ports that include one or more logical ports on the local hypervisor, for each such logical port \fIP\fR, the actions change the logical output port to \fIP\fR, then resubmit to table 41\[char46] +.IP +A special case is that when a localnet port exists on the datapath, remote port is connected by switching to the localnet port\[char46] In this case, instead of adding a flow in table 39 to reach the remote port, a flow is added in table 40 to switch the logical outport to the localnet port, and resubmit to table 40 as if it were unicasted to a logical port on the local hypervisor\[char46] +.IP +Table 41 matches and drops packets for which the logical input and output ports are the same and the MLF_ALLOW_LOOPBACK flag is not set\[char46] It also drops MLF_LOCAL_ONLY packets directed to a localnet port\[char46] It resubmits other packets to table 42\[char46] +.IP 4. .4in +OpenFlow tables 42 through 62 execute the logical egress pipeline from the \fBLogical_Flow\fR table in the OVN Southbound database\[char46] The egress pipeline can perform a final stage of validation before packet delivery\[char46] Eventually, it may execute an \fBoutput\fR action, which \fBovn\-controller\fR implements by resubmitting to table 64\[char46] A packet for which the pipeline never executes \fBoutput\fR is effectively dropped (although it may have been transmitted through a tunnel across a physical network)\[char46] +.IP +The egress pipeline cannot change the logical output port or cause further tunneling\[char46] +.IP 5. .4in +Table 64 bypasses OpenFlow loopback when MLF_ALLOW_LOOPBACK is set\[char46] Logical loopback was handled in table 41, but OpenFlow by default also prevents loopback to the OpenFlow ingress port\[char46] Thus, when MLF_ALLOW_LOOPBACK is set, OpenFlow table 64 saves the OpenFlow ingress port, sets it to zero, resubmits to table 65 for logical-to-physical transformation, and then restores the OpenFlow ingress port, effectively disabling OpenFlow loopback prevents\[char46] When MLF_ALLOW_LOOPBACK is unset, table 64 flow simply resubmits to table 65\[char46] +.IP 6. .4in +OpenFlow table 65 performs logical-to-physical translation, the opposite of table 0\[char46] It matches the packet\(cqs logical egress port\[char46] Its actions output the packet to the port attached to the OVN integration bridge that represents that logical port\[char46] If the logical egress port is a container nested with a VM, then before sending the packet the actions push on a VLAN header with an appropriate VLAN ID\[char46] +.RE +.SS "Logical Routers and Logical Patch Ports" +.PP +.PP +Typically logical routers and logical patch ports do not have a physical location and effectively reside on every hypervisor\[char46] This is the case for logical patch ports between logical routers and logical switches behind those logical routers, to which VMs (and VIFs) attach\[char46] +.PP +.PP +Consider a packet sent from one virtual machine or container to another VM or container that resides on a different subnet\[char46] The packet will traverse tables 0 to 65 as described in the previous section \fBArchitectural Physical Life Cycle of a Packet\fR, using the logical datapath representing the logical switch that the sender is attached to\[char46] At table 39, the packet will use the fallback flow that resubmits locally to table 40 on the same hypervisor\[char46] In this case, all of the processing from table 0 to table 65 occurs on the hypervisor where the sender resides\[char46] +.PP +.PP +When the packet reaches table 65, the logical egress port is a logical patch port\[char46] \fBovn\-controller\fR implements output to the logical patch is packet by cloning and resubmitting directly to the first OpenFlow flow table in the ingress pipeline, setting the logical ingress port to the peer logical patch port, and using the peer logical patch port\(cqs logical datapath (that represents the logical router)\[char46] +.PP +.PP +The packet re-enters the ingress pipeline in order to traverse tables 8 to 65 again, this time using the logical datapath representing the logical router\[char46] The processing continues as described in the previous section \fBArchitectural Physical Life Cycle of a Packet\fR\[char46] When the packet reaches table 65, the logical egress port will once again be a logical patch port\[char46] In the same manner as described above, this logical patch port will cause the packet to be resubmitted to OpenFlow tables 8 to 65, this time using the logical datapath representing the logical switch that the destination VM or container is attached to\[char46] +.PP +.PP +The packet traverses tables 8 to 65 a third and final time\[char46] If the destination VM or container resides on a remote hypervisor, then table 39 will send the packet on a tunnel port from the sender\(cqs hypervisor to the remote hypervisor\[char46] Finally table 65 will output the packet directly to the destination VM or container\[char46] +.PP +.PP +The following sections describe two exceptions, where logical routers and/or logical patch ports are associated with a physical location\[char46] +.ST "Gateway Routers" +.PP +.PP +A \fIgateway router\fR is a logical router that is bound to a physical location\[char46] This includes all of the logical patch ports of the logical router, as well as all of the peer logical patch ports on logical switches\[char46] In the OVN Southbound database, the \fBPort_Binding\fR entries for these logical patch ports use the type \fBl3gateway\fR rather than \fBpatch\fR, in order to distinguish that these logical patch ports are bound to a chassis\[char46] +.PP +.PP +When a hypervisor processes a packet on a logical datapath representing a logical switch, and the logical egress port is a \fBl3gateway\fR port representing connectivity to a gateway router, the packet will match a flow in table 39 that sends the packet on a tunnel port to the chassis where the gateway router resides\[char46] This processing in table 39 is done in the same manner as for VIFs\[char46] +.ST "Distributed Gateway Ports" +.PP +.PP +This section provides additional details on distributed gateway ports, outlined earlier\[char46] +.PP +.PP +The primary design goal of distributed gateway ports is to allow as much traffic as possible to be handled locally on the hypervisor where a VM or container resides\[char46] Whenever possible, packets from the VM or container to the outside world should be processed completely on that VM\(cqs or container\(cqs hypervisor, eventually traversing a localnet port instance or a tunnel to the physical network or a different OVN deployment\[char46] Whenever possible, packets from the outside world to a VM or container should be directed through the physical network directly to the VM\(cqs or container\(cqs hypervisor\[char46] +.PP +.PP +In order to allow for the distributed processing of packets described in the paragraph above, distributed gateway ports need to be logical patch ports that effectively reside on every hypervisor, rather than \fBl3gateway\fR ports that are bound to a particular chassis\[char46] However, the flows associated with distributed gateway ports often need to be associated with physical locations, for the following reasons: +.RS +.IP \(bu +The physical network that the localnet port is attached to typically uses L2 learning\[char46] Any Ethernet address used over the distributed gateway port must be restricted to a single physical location so that upstream L2 learning is not confused\[char46] Traffic sent out the distributed gateway port towards the localnet port with a specific Ethernet address must be sent out one specific instance of the distributed gateway port on one specific chassis\[char46] Traffic received from the localnet port (or from a VIF on the same logical switch as the localnet port) with a specific Ethernet address must be directed to the logical switch\(cqs patch port instance on that specific chassis\[char46] +.IP +Due to the implications of L2 learning, the Ethernet address and IP address of the distributed gateway port need to be restricted to a single physical location\[char46] For this reason, the user must specify one chassis associated with the distributed gateway port\[char46] Note that traffic traversing the distributed gateway port using other Ethernet addresses and IP addresses (e\[char46]g\[char46] one-to-one NAT) is not restricted to this chassis\[char46] +.IP +Replies to ARP and ND requests must be restricted to a single physical location, where the Ethernet address in the reply resides\[char46] This includes ARP and ND replies for the IP address of the distributed gateway port, which are restricted to the chassis that the user associated with the distributed gateway port\[char46] +.IP \(bu +In order to support one-to-many SNAT (aka IP masquerading), where multiple logical IP addresses spread across multiple chassis are mapped to a single external IP address, it will be necessary to handle some of the logical router processing on a specific chassis in a centralized manner\[char46] Since the SNAT external IP address is typically the distributed gateway port IP address, and for simplicity, the same chassis associated with the distributed gateway port is used\[char46] +.RE +.PP +.PP +The details of flow restrictions to specific chassis are described in the \fBovn\-northd\fR documentation\[char46] +.PP +.PP +While most of the physical location dependent aspects of distributed gateway ports can be handled by restricting some flows to specific chassis, one additional mechanism is required\[char46] When a packet leaves the ingress pipeline and the logical egress port is the distributed gateway port, one of two different sets of actions is required at table 39: +.RS +.IP \(bu +If the packet can be handled locally on the sender\(cqs hypervisor (e\[char46]g\[char46] one-to-one NAT traffic), then the packet should just be resubmitted locally to table 40, in the normal manner for distributed logical patch ports\[char46] +.IP \(bu +However, if the packet needs to be handled on the chassis associated with the distributed gateway port (e\[char46]g\[char46] one-to-many SNAT traffic or non-NAT traffic), then table 39 must send the packet on a tunnel port to that chassis\[char46] +.RE +.PP +.PP +In order to trigger the second set of actions, the \fBchassisredirect\fR type of southbound \fBPort_Binding\fR has been added\[char46] Setting the logical egress port to the type \fBchassisredirect\fR logical port is simply a way to indicate that although the packet is destined for the distributed gateway port, it needs to be redirected to a different chassis\[char46] At table 39, packets with this logical egress port are sent to a specific chassis, in the same way that table 39 directs packets whose logical egress port is a VIF or a type \fBl3gateway\fR port to different chassis\[char46] Once the packet arrives at that chassis, table 40 resets the logical egress port to the value representing the distributed gateway port\[char46] For each distributed gateway port, there is one type \fBchassisredirect\fR port, in addition to the distributed logical patch port representing the distributed gateway port\[char46] +.ST "High Availability for Distributed Gateway Ports" +.PP +.PP +OVN allows you to specify a prioritized list of chassis for a distributed gateway port\[char46] This is done by associating multiple \fBGateway_Chassis\fR rows with a \fBLogical_Router_Port\fR in the \fBOVN_Northbound\fR database\[char46] +.PP +.PP +When multiple chassis have been specified for a gateway, all chassis that may send packets to that gateway will enable BFD on tunnels to all configured gateway chassis\[char46] The current master chassis for the gateway is the highest priority gateway chassis that is currently viewed as active based on BFD status\[char46] +.PP +.PP +For more information on L3 gateway high availability, please refer to http://docs\[char46]ovn\[char46]org/en/latest/topics/high-availability\[char46]html\[char46] +.ST "Restrictions of Distributed Gateway Ports" +.PP +.PP +Distributed gateway ports are used to connect to an external network, which can be a physical network modeled by a logical switch with a localnet port, and can also be a logical switch that interconnects different OVN deployments (see \fBOVN Deployments Interconnection\fR)\[char46] Usually there can be many logical routers connected to the same external logical switch, as shown in below diagram\[char46] +.PP +.nf +\fL +.br +\fL +\-\-LS\-EXT\-+ +.br +\fL | | | +.br +\fL | | | +.br +\fL LR1 \[char46]\[char46]\[char46] LRn +.br +\fL \fR +.fi +.PP +.PP +In this diagram, there are n logical routers connected to a logical switch LS-EXT, each with a distributed gateway port, so that traffic sent to external world is redirected to the gateway chassis that is assigned to the distributed gateway port of respective logical router\[char46] +.PP +.PP +In the logical topology, nothing can prevent an user to add a route between the logical routers via the connected distributed gateway ports on LS-EXT\[char46] However, the route works only if the LS-EXT is a physical network (modeled by a logical switch with a localnet port)\[char46] In that case the packet will be delivered between the gateway chassises through the localnet port via physical network\[char46] If the LS-EXT is a regular logical switch (backed by tunneling only, as in the use case of OVN interconnection), then the packet will be dropped on the source gateway chassis\[char46] The limitation is due the fact that distributed gateway ports are tied to physical location, and without physical network connection, we will end up with either dropping the packet or transferring it over the tunnels which could cause bigger problems such as broadcast packets being redirect repeatedly by different gateway chassises\[char46] +.PP +.PP +With the limitation in mind, if a user do want the direct connectivity between the logical routers, it is better to create an internal logical switch connected to the logical routers with regular logical router ports, which are completely distributed and the packets don\(cqt have to leave a chassis unless necessary, which is more optimal than routing via the distributed gateway ports\[char46] +.ST "ARP request and ND NS packet processing" +.PP +.PP +Due to the fact that ARP requests and ND NA packets are usually broadcast packets, for performance reasons, OVN deals with requests that target OVN owned IP addresses (i\[char46]e\[char46], IP addresses configured on the router ports, VIPs, NAT IPs) in a specific way and only forwards them to the logical router that owns the target IP address\[char46] This behavior is different than that of traditional switches and implies that other routers/hosts connected to the logical switch will not learn the MAC/IP binding from the request packet\[char46] +.PP +.PP +All other ARP and ND packets are flooded in the L2 broadcast domain and to all attached logical patch ports\[char46] +.ST "VIFs on the logical switch connected by a distributed gateway port" +.PP +.PP +Typically the logical switch connected by a distributed gateway port is for external connectivity, usually to a physical network through a localnet port on the logical switch, or to a remote OVN deployment through OVN Interconnection\[char46] In these cases there is no VIF ports required on the logical switch\[char46] +.PP +.PP +While not very common, it is still possible to create VIF ports on the logical switch connected by a distributed gateway port, but there is a limitation that the logical ports need to reside on the gateway chassis where the distributed gateway port resides to get connectivity to other logical switches through the distributed gateway port\[char46] There is no limitation for the VIFs to connect within the logical switch, or beyond the logical switch through other regular distributed logical router ports\[char46] +.PP +.PP +A special case is when using distributed gateway ports for scalability purpose, as mentioned earlier in this document\[char46] The logical switches connected by distributed gateway ports are not for connectivity but just for regular VIFs\[char46] However, the above limitation usually does not matter because in this use case all the VIFs on the logical switch are located on the same chassis with the distributed gateway port that connects the logical switch\[char46] +.SS "Multiple localnet logical switches connected to a Logical Router" +.PP +.PP +It is possible to have multiple logical switches each with a localnet port (representing physical networks) connected to a logical router, in which one localnet logical switch may provide the external connectivity via a distributed gateway port and rest of the localnet logical switches use VLAN tagging in the physical network\[char46] It is expected that \fBovn\-bridge\-mappings\fR is configured appropriately on the chassis for all these localnet networks\[char46] +.ST "East West routing" +.PP +.PP +East-West routing between these localnet VLAN tagged logical switches work almost the same way as normal logical switches\[char46] When the VM sends such a packet, then: +.RS +.IP 1. .4in +It first enters the ingress pipeline, and then egress pipeline of the source localnet logical switch datapath\[char46] It then enters the ingress pipeline of the logical router datapath via the logical router port in the source chassis\[char46] +.IP 2. .4in +Routing decision is taken\[char46] +.IP 3. .4in +From the router datapath, packet enters the ingress pipeline and then egress pipeline of the destination localnet logical switch datapath and goes out of the integration bridge to the provider bridge ( belonging to the destination logical switch) via the localnet port\[char46] While sending the packet to provider bridge, we also replace router port MAC as source MAC with a chassis unique MAC\[char46] +.IP +This chassis unique MAC is configured as global ovs config on each chassis (eg\[char46] via \(dq\fBovs\-vsctl set open \[char46] external\-ids: +ovn\-chassis\-mac\-mappings=\(dqphys:aa:bb:cc:dd:ee:$i$i\(dq\fR\(dq)\[char46] For more details, see \fBovn\-controller\fR(8)\[char46] +.IP +If the above is not configured, then source MAC would be the router port MAC\[char46] This could create problem if we have more than one chassis\[char46] This is because, since the router port is distributed, the same (MAC,VLAN) tuple will seen by physical network from other chassis as well, which could cause these issues: +.RS +.IP \(bu +Continuous MAC moves in top-of-rack switch (ToR)\[char46] +.IP \(bu +ToR dropping the traffic, which is causing continuous MAC moves\[char46] +.IP \(bu +ToR blocking the ports from which MAC moves are happening\[char46] +.RE +.IP 4. .4in +The destination chassis receives the packet via the localnet port and sends it to the integration bridge\[char46] Before entering the integration bridge the source mac of the packet will be replaced with router port mac again\[char46] The packet enters the ingress pipeline and then egress pipeline of the destination localnet logical switch and finally gets delivered to the destination VM port\[char46] +.RE +.ST "External traffic" +.PP +.PP +The following happens when a VM sends an external traffic (which requires NATting) and the chassis hosting the VM doesn\(cqt have a distributed gateway port\[char46] +.RS +.IP 1. .4in +The packet first enters the ingress pipeline, and then egress pipeline of the source localnet logical switch datapath\[char46] It then enters the ingress pipeline of the logical router datapath via the logical router port in the source chassis\[char46] +.IP 2. .4in +Routing decision is taken\[char46] Since the gateway router or the distributed gateway port doesn\(cqt reside in the source chassis, the traffic is redirected to the gateway chassis via the tunnel port\[char46] +.IP 3. .4in +The gateway chassis receives the packet via the tunnel port and the packet enters the egress pipeline of the logical router datapath\[char46] NAT rules are applied here\[char46] The packet then enters the ingress pipeline and then egress pipeline of the localnet logical switch datapath which provides external connectivity and finally goes out via the localnet port of the logical switch which provides external connectivity\[char46] +.RE +.PP +.PP +Although this works, the VM traffic is tunnelled when sent from the compute chassis to the gateway chassis\[char46] In order for it to work properly, the MTU of the localnet logical switches must be lowered to account for the tunnel encapsulation\[char46] +.SS "Centralized routing for localnet VLAN tagged logical switches connected to a Logical Router" +.PP +.PP +To overcome the tunnel encapsulation problem described in the previous section, \fBOVN\fR supports the option of enabling centralized routing for localnet VLAN tagged logical switches\[char46] CMS can configure the option \fBoptions:reside-on-redirect-chassis\fR to \fBtrue\fR for each \fBLogical_Router_Port\fR which connects to the localnet VLAN tagged logical switches\[char46] This causes the gateway chassis (hosting the distributed gateway port) to handle all the routing for these networks, making it centralized\[char46] It will reply to the ARP requests for the logical router port IPs\[char46] +.PP +.PP +If the logical router doesn\(cqt have a distributed gateway port connecting to the localnet logical switch which provides external connectivity, or if it has more than one distributed gateway ports, then this option is ignored by \fBOVN\fR\[char46] +.PP +.PP +The following happens when a VM sends an east-west traffic which needs to be routed: +.RS +.IP 1. .4in +The packet first enters the ingress pipeline, and then egress pipeline of the source localnet logical switch datapath and is sent out via a localnet port of the source localnet logical switch (instead of sending it to router pipeline)\[char46] +.IP 2. .4in +The gateway chassis receives the packet via a localnet port of the source localnet logical switch and sends it to the integration bridge\[char46] The packet then enters the ingress pipeline, and then egress pipeline of the source localnet logical switch datapath and enters the ingress pipeline of the logical router datapath\[char46] +.IP 3. .4in +Routing decision is taken\[char46] +.IP 4. .4in +From the router datapath, packet enters the ingress pipeline and then egress pipeline of the destination localnet logical switch datapath\[char46] It then goes out of the integration bridge to the provider bridge ( belonging to the destination logical switch) via a localnet port\[char46] +.IP 5. .4in +The destination chassis receives the packet via a localnet port and sends it to the integration bridge\[char46] The packet enters the ingress pipeline and then egress pipeline of the destination localnet logical switch and finally delivered to the destination VM port\[char46] +.RE +.PP +.PP +The following happens when a VM sends an external traffic which requires NATting: +.RS +.IP 1. .4in +The packet first enters the ingress pipeline, and then egress pipeline of the source localnet logical switch datapath and is sent out via a localnet port of the source localnet logical switch (instead of sending it to router pipeline)\[char46] +.IP 2. .4in +The gateway chassis receives the packet via a localnet port of the source localnet logical switch and sends it to the integration bridge\[char46] The packet then enters the ingress pipeline, and then egress pipeline of the source localnet logical switch datapath and enters the ingress pipeline of the logical router datapath\[char46] +.IP 3. .4in +Routing decision is taken and NAT rules are applied\[char46] +.IP 4. .4in +From the router datapath, packet enters the ingress pipeline and then egress pipeline of the localnet logical switch datapath which provides external connectivity\[char46] It then goes out of the integration bridge to the provider bridge (belonging to the logical switch which provides external connectivity) via a localnet port\[char46] +.RE +.PP +.PP +The following happens for the reverse external traffic\[char46] +.RS +.IP 1. .4in +The gateway chassis receives the packet from a localnet port of the logical switch which provides external connectivity\[char46] The packet then enters the ingress pipeline and then egress pipeline of the localnet logical switch (which provides external connectivity)\[char46] The packet then enters the ingress pipeline of the logical router datapath\[char46] +.IP 2. .4in +The ingress pipeline of the logical router datapath applies the unNATting rules\[char46] The packet then enters the ingress pipeline and then egress pipeline of the source localnet logical switch\[char46] Since the source VM doesn\(cqt reside in the gateway chassis, the packet is sent out via a localnet port of the source logical switch\[char46] +.IP 3. .4in +The source chassis receives the packet via a localnet port and sends it to the integration bridge\[char46] The packet enters the ingress pipeline and then egress pipeline of the source localnet logical switch and finally gets delivered to the source VM port\[char46] +.RE +.PP +.PP +As an alternative to \fBreside\-on\-redirect\-chassis\fR, OVN supports VLAN-based redirection\[char46] Whereas \fBreside\-on\-redirect\-chassis\fR centralizes all router functionality, VLAN-based redirection only changes how OVN redirects packets to the gateway chassis\[char46] By setting \fBoptions:redirect\-type\fR to \fBbridged\fR on a distributed gateway port, OVN redirects packets to the gateway chassis using the \fBlocalnet\fR port of the router\(cqs peer logical switch, instead of a tunnel\[char46] +.PP +.PP +If the logical router doesn\(cqt have a distributed gateway port connecting to the localnet logical switch which provides external connectivity, or if it has more than one distributed gateway ports, then this option is ignored by \fBOVN\fR\[char46] +.PP +.PP +Following happens for bridged redirection: +.RS +.IP 1. .4in +On compute chassis, packet passes though logical router\(cqs ingress pipeline\[char46] +.IP 2. .4in +If logical outport is gateway chassis attached router port then packet is \(dqredirected\(dq to gateway chassis using peer logical switch\(cqs localnet port\[char46] +.IP 3. .4in +This redirected packet has destination mac as router port mac (the one to which gateway chassis is attached)\[char46] Its VLAN id is that of localnet port (peer logical switch of the logical router port)\[char46] +.IP 4. .4in +On the gateway chassis packet will enter the logical router pipeline again and this time it will passthrough egress pipeline as well\[char46] +.IP 5. .4in +Reverse traffic packet flows stays the same\[char46] +.RE +.PP +.PP +Some guidelines and expections with bridged redirection: +.RS +.IP 1. .4in +Since router port mac is destination mac, hence it has to be ensured that physical network learns it on ONLY from the gateway chassis\[char46] Which means that \fBovn\-chassis\-mac\-mappings\fR should be configure on all the compute nodes, so that physical network never learn router port mac from compute nodes\[char46] +.IP 2. .4in +Since packet enters logical router ingress pipeline twice (once on compute chassis and again on gateway chassis), hence ttl will be decremented twice\[char46] +.IP 3. .4in +Default redirection type continues to be \fBoverlay\fR\[char46] User can switch the redirect-type between \fBbridged\fR and \fBoverlay\fR by changing the value of \fBoptions:redirect\-type\fR +.RE +.SS "Life Cycle of a VTEP gateway" +.PP +.PP +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\[char46] +.PP +.PP +The steps below refer often to details of the OVN and VTEP database schemas\[char46] Please see \fBovn\-sb\fR(5), \fBovn\-nb\fR(5) and \fBvtep\fR(5), respectively, for the full story on these databases\[char46] +.RS +.IP 1. .4in +A VTEP gateway\(cqs life cycle begins with the administrator registering the VTEP gateway as a \fBPhysical_Switch\fR table entry in the \fBVTEP\fR database\[char46] The \fBovn\-controller\-vtep\fR connected to this VTEP database, will recognize the new VTEP gateway and create a new \fBChassis\fR table entry for it in the \fBOVN_Southbound\fR database\[char46] +.IP 2. .4in +The administrator can then create a new \fBLogical_Switch\fR table entry, and bind a particular vlan on a VTEP gateway\(cqs port to any VTEP logical switch\[char46] Once a VTEP logical switch is bound to a VTEP gateway, the \fBovn\-controller\-vtep\fR will detect it and add its name to the \fIvtep_logical_switches\fR column of the \fBChassis\fR table in the \fB +OVN_Southbound\fR database\[char46] Note, the \fItunnel_key\fR column of VTEP logical switch is not filled at creation\[char46] The \fBovn\-controller\-vtep\fR will set the column when the corresponding vtep logical switch is bound to an OVN logical network\[char46] +.IP 3. .4in +Now, the administrator can use the CMS to add a VTEP logical switch to the OVN logical network\[char46] To do that, the CMS must first create a new \fBLogical_Switch_Port\fR table entry in the \fB +OVN_Northbound\fR database\[char46] Then, the \fItype\fR column of this entry must be set to \(dqvtep\(dq\[char46] Next, the \fI +vtep-logical-switch\fR and \fIvtep-physical-switch\fR keys in the \fIoptions\fR column must also be specified, since multiple VTEP gateways can attach to the same VTEP logical switch\[char46] Next, the \fIaddresses\fR column of this logical port must be set to \(dqunknown\(dq, it will add a priority 0 entry in \(dqls_in_l2_lkup\(dq stage of logical switch ingress pipeline\[char46] So, traffic with unrecorded mac by OVN would go through the \fBLogical_Switch_Port\fR to physical network\[char46] +.IP 4. .4in +The newly created logical port in the \fBOVN_Northbound\fR database and its configuration will be passed down to the \fB +OVN_Southbound\fR database as a new \fBPort_Binding\fR table entry\[char46] The \fBovn\-controller\-vtep\fR will recognize the change and bind the logical port to the corresponding VTEP gateway chassis\[char46] Configuration of binding the same VTEP logical switch to a different OVN logical networks is not allowed and a warning will be generated in the log\[char46] +.IP 5. .4in +Beside binding to the VTEP gateway chassis, the \fB +ovn\-controller\-vtep\fR will update the \fItunnel_key\fR column of the VTEP logical switch to the corresponding \fB +Datapath_Binding\fR table entry\(cqs \fItunnel_key\fR for the bound OVN logical network\[char46] +.IP 6. .4in +Next, the \fBovn\-controller\-vtep\fR will keep reacting to the configuration change in the \fBPort_Binding\fR in the \fBOVN_Northbound\fR database, and updating the \fBUcast_Macs_Remote\fR table in the \fBVTEP\fR database\[char46] This allows the VTEP gateway to understand where to forward the unicast traffic coming from the extended external network\[char46] +.IP 7. .4in +Eventually, the VTEP gateway\(cqs life cycle ends when the administrator unregisters the VTEP gateway from the \fBVTEP\fR database\[char46] The \fBovn\-controller\-vtep\fR will recognize the event and remove all related configurations (\fBChassis\fR table entry and port bindings) in the \fBOVN_Southbound\fR database\[char46] +.IP 8. .4in +When the \fBovn\-controller\-vtep\fR is terminated, all related configurations in the \fBOVN_Southbound\fR database and the \fBVTEP\fR database will be cleaned, including \fBChassis\fR table entries for all registered VTEP gateways and their port bindings, and all \fBUcast_Macs_Remote\fR table entries and the \fBLogical_Switch\fR tunnel keys\[char46] +.RE +.SS "OVN Deployments Interconnection" +.PP +.PP +It is not uncommon for an operator to deploy multiple OVN clusters, for two main reasons\[char46] Firstly, an operator may prefer to deploy one OVN cluster for each availability zone, e\[char46]g\[char46] in different physical regions, to avoid single point of failure\[char46] Secondly, there is always an upper limit for a single OVN control plane to scale\[char46] +.PP +.PP +Although the control planes of the different availability zone (AZ)s are independent from each other, the workloads from different AZs may need to communicate across the zones\[char46] The OVN interconnection feature provides a native way to interconnect different AZs by L3 routing through transit overlay networks between logical routers of different AZs\[char46] +.PP +.PP +A global OVN Interconnection Northbound database is introduced for the operator (probably through CMS systems) to configure transit logical switches that connect logical routers from different AZs\[char46] A transit switch is similar to a regular logical switch, but it is used for interconnection purpose only\[char46] Typically, each transit switch can be used to connect all logical routers that belong to same tenant across all AZs\[char46] +.PP +.PP +A dedicated daemon process \fBovn\-ic\fR, OVN interconnection controller, in each AZ will consume this data and populate corresponding logical switches to their own northbound databases for each AZ, so that logical routers can be connected to the transit switch by creating patch port pairs in their northbound databases\[char46] Any router ports connected to the transit switches are considered interconnection ports, which will be exchanged between AZs\[char46] +.PP +.PP +Physically, when workloads from different AZs communicate, packets need to go through multiple hops: source chassis, source gateway, destination gateway and destination chassis\[char46] All these hops are connected through tunnels so that the packets never leave overlay networks\[char46] A distributed gateway port is required to connect the logical router to a transit switch, with a gateway chassis specified, so that the traffic can be forwarded through the gateway chassis\[char46] +.PP +.PP +A global OVN Interconnection Southbound database is introduced for exchanging control plane information between the AZs\[char46] The data in this database is populated and consumed by the \fBovn\-ic\fR, of each AZ\[char46] The main information in this database includes: +.RS +.IP \(bu +Datapath bindings for transit switches, which mainly contains the tunnel keys generated for each transit switch\[char46] Separate key ranges are reserved for transit switches so that they will never conflict with any tunnel keys locally assigned for datapaths within each AZ\[char46] +.IP \(bu +Availability zones, which are registered by \fBovn\-ic\fR from each AZ\[char46] +.IP \(bu +Gateways\[char46] Each AZ specifies chassises that are supposed to work as interconnection gateways, and the \fBovn\-ic\fR will populate this information to the interconnection southbound DB\[char46] The \fBovn\-ic\fR from all the other AZs will learn the gateways and populate to their own southbound DB as a chassis\[char46] +.IP \(bu +Port bindings for logical switch ports created on the transit switch\[char46] Each AZ maintains their logical router to transit switch connections independently, but \fBovn\-ic\fR automatically populates local port bindings on transit switches to the global interconnection southbound DB, and learns remote port bindings from other AZs back to its own northbound and southbound DBs, so that logical flows can be produced and then translated to OVS flows locally, which finally enables data plane communication\[char46] +.IP \(bu +Routes that are advertised between different AZs\[char46] If enabled, routes are automatically exchanged by \fBovn\-ic\fR\[char46] Both static routes and directly connected subnets are advertised\[char46] Options in \fBoptions\fR column of the \fBNB_Global\fR table of \fBOVN_NB\fR database control the behavior of route advertisement, such as enable/disable the advertising/learning routes, whether default routes are advertised/learned, and blacklisted CIDRs\[char46] See \fBovn\-nb\fR(5) for more details\[char46] +.RE +.PP +.PP +The tunnel keys for transit switch datapaths and related port bindings must be agreed across all AZs\[char46] This is ensured by generating and storing the keys in the global interconnection southbound database\[char46] Any \fBovn\-ic\fR from any AZ can allocate the key, but race conditions are solved by enforcing unique index for the column in the database\[char46] +.PP +.PP +Once each AZ\(cqs NB and SB databases are populated with interconnection switches and ports, and agreed upon the tunnel keys, data plane communication between the AZs are established\[char46] +.PP +.PP +When VXLAN tunneling is enabled in an OVN cluster, due to the limited range available for VNIs, Interconnection feature is not supported\[char46] +.ST "A day in the life of a packet crossing AZs" +.RS +.IP 1. .4in +An IP packet is sent out from a VIF on a hypervisor (HV1) of AZ1, with destination IP belonging to a VIF in AZ2\[char46] +.IP 2. .4in +In HV1\(cqs OVS flow tables, the packet goes through logical switch and logical router pipelines, and in a logical router pipeline, the routing stage finds out the next hop for the destination IP, which belongs to a remote logical router port in AZ2, and the output port, which is a chassis-redirect port located on an interconnection gateway (GW1 in AZ1), so HV1 sends the packet to GW1 through tunnel\[char46] +.IP 3. .4in +On GW1, it continues with the logical router pipe line and switches to the transit switch\(cqs pipeline through the peer port of the chassis redirect port\[char46] In the transit switch\(cqs pipeline it outputs to the remote logical port which is located on a gateway (GW2) in AZ2, so the GW1 sends the packet to GW2 in tunnel\[char46] +.IP 4. .4in +On GW2, it continues with the transit switch pipeline and switches to the logical router pipeline through the peer port, which is a chassis redirect port that is located on GW2\[char46] The logical router pipeline then forwards the packet to relevant logical pipelines according to the destination IP address, and figures out the MAC and location of the destination VIF port - a hypervisor (HV2)\[char46] The GW2 then sends the packet to HV2 in tunnel\[char46] +.IP 5. .4in +On HV2, the packet is delivered to the final destination VIF port by the logical switch egress pipeline, just the same way as for intra-AZ communications\[char46] +.RE +.SS "Native OVN services for external logical ports" +.PP +.PP +To support OVN native services (like DHCP/IPv6 RA/DNS lookup) to the cloud resources which are external, OVN supports \fBexternal\fR logical ports\[char46] +.PP +.PP +Below are some of the use cases where \fBexternal\fR ports can be used\[char46] +.RS +.IP \(bu +VMs connected to SR-IOV nics - Traffic from these VMs by passes the kernel stack and local \fBovn\-controller\fR do not bind these ports and cannot serve the native services\[char46] +.IP \(bu +When CMS supports provisioning baremetal servers\[char46] +.RE +.PP +.PP +OVN will provide the native services if CMS has done the below configuration in the \fIOVN Northbound Database\fR\[char46] +.RS +.IP \(bu +A row is created in \fBLogical_Switch_Port\fR, configuring the \fBaddresses\fR column and setting the \fBtype\fR to \fBexternal\fR\[char46] +.IP \(bu +\fBha_chassis_group\fR column is configured\[char46] +.IP \(bu +The HA chassis which belongs to the HA chassis group has the \fBovn\-bridge\-mappings\fR configured and has proper L2 connectivity so that it can receive the DHCP and other related request packets from these external resources\[char46] +.IP \(bu +The Logical_Switch of this port has a \fBlocalnet\fR port\[char46] +.IP \(bu +Native OVN services are enabled by configuring the DHCP and other options like the way it is done for the normal logical ports\[char46] +.RE +.PP +.PP +It is recommended to use the same HA chassis group for all the external ports of a logical switch\[char46] Otherwise, the physical switch might see MAC flap issue when different chassis provide the native services\[char46] For example when supporting native DHCPv4 service, DHCPv4 server mac (configured in \fBoptions:server_mac\fR column in table \fBDHCP_Options\fR) originating from different ports can cause MAC flap issue\[char46] 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\[char46] +.SH "SECURITY" +.SS "Role\-Based Access Controls for the Southbound DB" +.PP +.PP +In order to provide additional security against the possibility of an OVN chassis becoming compromised in such a way as to allow rogue software to make arbitrary modifications to the southbound database state and thus disrupt the OVN network, role-based access controls (see \fBovsdb\-server(1)\fR for additional details) are provided for the southbound database\[char46] +.PP +.PP +The implementation of role-based access controls (RBAC) requires the addition of two tables to an OVSDB schema: the \fBRBAC_Role\fR table, which is indexed by role name and maps the the names of the various tables that may be modifiable for a given role to individual rows in a permissions table containing detailed permission information for that role, and the permission table itself which consists of rows containing the following information: +.RS +.TP +\fBTable Name\fR +The name of the associated table\[char46] This column exists primarily as an aid for humans reading the contents of this table\[char46] +.TP +\fBAuth Criteria\fR +A set of strings containing the names of columns (or column:key pairs for columns containing string:string maps)\[char46] The contents of at least one of the columns or column:key values in a row to be modified, inserted, or deleted must be equal to the ID of the client attempting to act on the row in order for the authorization check to pass\[char46] If the authorization criteria is empty, authorization checking is disabled and all clients for the role will be treated as authorized\[char46] +.TP +\fBInsert/Delete\fR +Row insertion/deletion permission; boolean value indicating whether insertion and deletion of rows is allowed for the associated table\[char46] If true, insertion and deletion of rows is allowed for authorized clients\[char46] +.TP +\fBUpdatable Columns\fR +A set of strings containing the names of columns or column:key pairs that may be updated or mutated by authorized clients\[char46] Modifications to columns within a row are only permitted when the authorization check for the client passes and all columns to be modified are included in this set of modifiable columns\[char46] +.RE +.PP +.PP +RBAC configuration for the OVN southbound database is maintained by ovn-northd\[char46] With RBAC enabled, modifications are only permitted for the \fBChassis\fR, \fBEncap\fR, \fBPort_Binding\fR, and \fBMAC_Binding\fR tables, and are restricted as follows: +.RS +.TP +\fBChassis\fR +\fBAuthorization\fR: client ID must match the chassis name\[char46] +.IP +\fBInsert/Delete\fR: authorized row insertion and deletion are permitted\[char46] +.IP +\fBUpdate\fR: The columns \fBnb_cfg\fR, \fBexternal_ids\fR, \fBencaps\fR, and \fBvtep_logical_switches\fR may be modified when authorized\[char46] +.TP +\fBEncap\fR +\fBAuthorization\fR: client ID must match the chassis name\[char46] +.IP +\fBInsert/Delete\fR: row insertion and row deletion are permitted\[char46] +.IP +\fBUpdate\fR: The columns \fBtype\fR, \fBoptions\fR, and \fBip\fR can be modified\[char46] +.TP +\fBPort_Binding\fR +\fBAuthorization\fR: disabled (all clients are considered authorized\[char46] A future enhancement may add columns (or keys to \fBexternal_ids\fR) in order to control which chassis are allowed to bind each port\[char46] +.IP +\fBInsert/Delete\fR: row insertion/deletion are not permitted (ovn-northd maintains rows in this table\[char46] +.IP +\fBUpdate\fR: Only modifications to the \fBchassis\fR column are permitted\[char46] +.TP +\fBMAC_Binding\fR +\fBAuthorization\fR: disabled (all clients are considered to be authorized)\[char46] +.IP +\fBInsert/Delete\fR: row insertion/deletion are permitted\[char46] +.IP +\fBUpdate\fR: The columns \fBlogical_port\fR, \fBip\fR, \fBmac\fR, and \fBdatapath\fR may be modified by ovn-controller\[char46] +.TP +\fBIGMP_Group\fR +\fBAuthorization\fR: disabled (all clients are considered to be authorized)\[char46] +.IP +\fBInsert/Delete\fR: row insertion/deletion are permitted\[char46] +.IP +\fBUpdate\fR: The columns \fBaddress\fR, \fBchassis\fR, \fBdatapath\fR, and \fBports\fR may be modified by ovn-controller\[char46] +.RE +.PP +.PP +Enabling RBAC for ovn-controller connections to the southbound database requires the following steps: +.RS +.IP 1. .4in +Creating SSL certificates for each chassis with the certificate CN field set to the chassis name (e\[char46]g\[char46] for a chassis with \fBexternal\-ids:system\-id=chassis\-1\fR, via the command \(dq\fBovs\-pki \-u req+sign chassis\-1 switch\fR\(dq)\[char46] +.IP 2. .4in +Configuring each ovn-controller to use SSL when connecting to the southbound database (e\[char46]g\[char46] via \(dq\fBovs\-vsctl set open \[char46] +external\-ids:ovn\-remote=ssl:x\[char46]x\[char46]x\[char46]x:6642\fR\(dq)\[char46] +.IP 3. .4in +Configuring a southbound database SSL remote with \(dqovn-controller\(dq role (e\[char46]g\[char46] via \(dq\fBovn\-sbctl set\-connection role=ovn\-controller +pssl:6642\fR\(dq)\[char46] +.RE +.SS "Encrypt Tunnel Traffic with IPsec" +.PP +.PP +OVN tunnel traffic goes through physical routers and switches\[char46] These physical devices could be untrusted (devices in public network) or might be compromised\[char46] Enabling encryption to the tunnel traffic can prevent the traffic data from being monitored and manipulated\[char46] +.PP +.PP +The tunnel traffic is encrypted with IPsec\[char46] The CMS sets the \fBipsec\fR column in the northbound \fBNB_Global\fR table to enable or disable IPsec encrytion\[char46] If \fBipsec\fR is true, all OVN tunnels will be encrypted\[char46] If \fBipsec\fR is false, no OVN tunnels will be encrypted\[char46] +.PP +.PP +When CMS updates the \fBipsec\fR column in the northbound \fBNB_Global\fR table, \fBovn\-northd\fR copies the value to the \fBipsec\fR column in the southbound \fBSB_Global\fR table\[char46] \fBovn\-controller\fR in each chassis monitors the southbound database and sets the options of the OVS tunnel interface accordingly\[char46] OVS tunnel interface options are monitored by the \fBovs\-monitor\-ipsec\fR daemon which configures IKE daemon to set up IPsec connections\[char46] +.PP +.PP +Chassis authenticates each other by using certificate\[char46] The authentication succeeds if the other end in tunnel presents a certificate signed by a trusted CA and the common name (CN) matches the expected chassis name\[char46] The SSL certificates used in role-based access controls (RBAC) can be used in IPsec\[char46] Or use \fBovs\-pki\fR to create different certificates\[char46] The certificate is required to be x\[char46]509 version 3, and with CN field and subjectAltName field being set to the chassis name\[char46] +.PP +.PP +The CA certificate, chassis certificate and private key are required to be installed in each chassis before enabling IPsec\[char46] Please see \fBovs\-vswitchd\[char46]conf\[char46]db\fR(5) for setting up CA based IPsec authentication\[char46] +.SH "DESIGN DECISIONS" +.SS "Tunnel Encapsulations" +.PP +.PP +In general, OVN annotates logical network packets that it sends from one hypervisor to another with the following three pieces of metadata, which are encoded in an encapsulation-specific fashion: +.RS +.IP \(bu +24-bit logical datapath identifier, from the \fBtunnel_key\fR column in the OVN Southbound \fBDatapath_Binding\fR table\[char46] +.IP \(bu +15-bit logical ingress port identifier\[char46] ID 0 is reserved for internal use within OVN\[char46] IDs 1 through 32767, inclusive, may be assigned to logical ports (see the \fBtunnel_key\fR column in the OVN Southbound \fBPort_Binding\fR table)\[char46] +.IP \(bu +16-bit logical egress port identifier\[char46] IDs 0 through 32767 have the same meaning as for logical ingress ports\[char46] IDs 32768 through 65535, inclusive, may be assigned to logical multicast groups (see the \fBtunnel_key\fR column in the OVN Southbound \fBMulticast_Group\fR table)\[char46] +.RE +.PP +.PP +When VXLAN is enabled on any hypervisor in a cluster, datapath and egress port identifier ranges are reduced to 12-bits\[char46] This is done because only STT and Geneve provide the large space for metadata (over 32 bits per packet)\[char46] To accommodate for VXLAN, 24 bits available are split as follows: +.RS +.IP \(bu +12-bit logical datapath identifier, derived from the \fBtunnel_key\fR column in the OVN Southbound \fBDatapath_Binding\fR table\[char46] +.IP \(bu +12-bit logical egress port identifier\[char46] IDs 0 through 2047 are used for unicast output ports\[char46] IDs 2048 through 4095, inclusive, may be assigned to logical multicast groups (see the \fBtunnel_key\fR column in the OVN Southbound \fBMulticast_Group\fR table)\[char46] For multicast group tunnel keys, a special mapping scheme is used to internally transform from internal OVN 16-bit keys to 12-bit values before sending packets through a VXLAN tunnel, and back from 12-bit tunnel keys to 16-bit values when receiving packets from a VXLAN tunnel\[char46] +.IP \(bu +No logical ingress port identifier\[char46] +.RE +.PP +.PP +The limited space available for metadata when VXLAN tunnels are enabled in a cluster put the following functional limitations onto features available to users: +.RS +.IP \(bu +The maximum number of networks is reduced to 4096\[char46] +.IP \(bu +The maximum number of ports per network is reduced to 2048\[char46] +.IP \(bu +ACLs matching against logical ingress port identifiers are not supported\[char46] +.IP \(bu +OVN interconnection feature is not supported\[char46] +.RE +.PP +.PP +In addition to functional limitations described above, the following should be considered before enabling it in your cluster: +.RS +.IP \(bu +STT and Geneve use randomized UDP or TCP source ports that allows efficient distribution among multiple paths in environments that use ECMP in their underlay\[char46] +.IP \(bu +NICs are available to offload STT and Geneve encapsulation and decapsulation\[char46] +.RE +.PP +.PP +Due to its flexibility, the preferred encapsulation between hypervisors is Geneve\[char46] For Geneve encapsulation, OVN transmits the logical datapath identifier in the Geneve VNI\[char46] OVN transmits the logical ingress and logical egress ports in a TLV with class 0x0102, type 0x80, and a 32-bit value encoded as follows, from MSB to LSB: +.PP +.\" check if in troff mode (TTY) +.if t \{ +.PS +boxht = .2 +textht = 1/6 +fillval = .2 +[ +B0: box "rsv" width .25 +B1: box "ingress port" width .75 +B2: box "egress port" width .75 +"1" at B0.n above +"0" at B0.s below +"15" at B1.n above +"" at B1.s below +"16" at B2.n above +"" at B2.s below +line <-> invis "" above from B0.nw + (0,textht) to B2.ne + (0,textht) +] +.PE +\} +.\" check if in nroff mode: +.if n \{ +.nf +\fL 1 15 16 +.br +\fL+---+------------+-----------+ +.br +\fL|rsv|ingress port|egress port| +.br +\fL+---+------------+-----------+ +.br +\fL 0 +.fi +\} +.PP +.PP +Environments whose NICs lack Geneve offload may prefer STT encapsulation for performance reasons\[char46] For STT encapsulation, OVN encodes all three pieces of logical metadata in the STT 64-bit tunnel ID as follows, from MSB to LSB: +.PP +.\" check if in troff mode (TTY) +.if t \{ +.PS +boxht = .2 +textht = 1/6 +fillval = .2 +[ +B0: box "reserved" width .5 +B1: box "ingress port" width .75 +B2: box "egress port" width .75 +B3: box "datapath" width 1.25 +"9" at B0.n above +"0" at B0.s below +"15" at B1.n above +"" at B1.s below +"16" at B2.n above +"" at B2.s below +"24" at B3.n above +"" at B3.s below +line <-> invis "" above from B0.nw + (0,textht) to B3.ne + (0,textht) +] +.PE +\} +.\" check if in nroff mode: +.if n \{ +.nf +\fL 9 15 16 24 +.br +\fL+--------+------------+-----------+--------+ +.br +\fL|reserved|ingress port|egress port|datapath| +.br +\fL+--------+------------+-----------+--------+ +.br +\fL 0 +.fi +\} +.PP +.PP +For connecting to gateways, in addition to Geneve and STT, OVN supports VXLAN, because only VXLAN support is common on top-of-rack (ToR) switches\[char46] Currently, gateways have a feature set that matches the capabilities as defined by the VTEP schema, so fewer bits of metadata are necessary\[char46] In the future, gateways that do not support encapsulations with large amounts of metadata may continue to have a reduced feature set\[char46] diff --git a/src/static/support/dist-docs-branch-23.06/ovn-architecture.7.html b/src/static/support/dist-docs-branch-23.06/ovn-architecture.7.html new file mode 100644 index 00000000..68a75bd5 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-architecture.7.html @@ -0,0 +1,2173 @@ +
+ovn-architecture(7)               OVN Manual               ovn-architecture(7)
+
+NAME
+       ovn-architecture - Open Virtual Network architecture
+
+DESCRIPTION
+       OVN,  the  Open Virtual Network, is a system to support logical network
+       abstraction in virtual machine and container environments. OVN  compleā€
+       ments  the existing capabilities of OVS to add native support for logiā€
+       cal network abstractions, such as logical L2 and L3 overlays and  secuā€
+       rity  groups.  Services  such as DHCP are also desirable features. Just
+       like OVS, OVNā€™s design goal is to have a production-quality implementaā€
+       tion that can operate at significant scale.
+
+       A physical network comprises physical wires, switches, and  routers.  A
+       virtual  network  extends  a physical network into a hypervisor or conā€
+       tainer platform, bridging VMs or containers into the physical  network.
+       An OVN logical network is a network implemented in software that is inā€
+       sulated  from  physical (and thus virtual) networks by tunnels or other
+       encapsulations. This allows IP and other address spaces used in logical
+       networks to overlap with those used on physical networks without  causā€
+       ing  conflicts.  Logical network topologies can be arranged without reā€
+       gard for the topologies of the physical networks  on  which  they  run.
+       Thus, VMs that are part of a logical network can migrate from one physā€
+       ical  machine  to  another without network disruption. See Logical Netā€ā€
+       works, below, for more information.
+
+       The encapsulation layer prevents VMs and containers connected to a logā€
+       ical network from communicating with nodes on  physical  networks.  For
+       clustering  VMs  and  containers, this can be acceptable or even desirā€
+       able, but in many cases VMs and  containers  do  need  connectivity  to
+       physical  networks.  OVN  provides  multiple forms of gateways for this
+       purpose. See Gateways, below, for more information.
+
+       An OVN deployment consists of several components:
+
+              ā€¢      A Cloud Management System (CMS), which is OVNā€™s  ultimate
+                     client  (via  its users and administrators). OVN integraā€
+                     tion requires installing a CMS-specific  plugin  and  reā€
+                     lated  software  (see below). OVN initially targets Openā€
+                     Stack as CMS.
+
+                     We generally speak of ``theā€™ā€™ CMS, but  one  can  imagine
+                     scenarios  in which multiple CMSes manage different parts
+                     of an OVN deployment.
+
+              ā€¢      An OVN Database physical or virtual node (or, eventually,
+                     cluster) installed in a central location.
+
+              ā€¢      One or more (usually many) hypervisors. Hypervisors  must
+                     run Open vSwitch and implement the interface described in
+                     Documentation/topics/integration.rst  in the Open vSwitch
+                     source tree. Any hypervisor platform  supported  by  Open
+                     vSwitch is acceptable.
+
+              ā€¢      Zero  or  more gateways. A gateway extends a tunnel-based
+                     logical network into a physical network  by  bidirectionā€
+                     ally  forwarding  packets  between tunnels and a physical
+                     Ethernet port. This allows  non-virtualized  machines  to
+                     participate in logical networks. A gateway may be a physā€
+                     ical  host,  a virtual machine, or an ASIC-based hardware
+                     switch that supports the vtep(5) schema.
+
+                     Hypervisors and gateways are  together  called  transport
+                     node or chassis.
+
+       The  diagram  below  shows  how the major components of OVN and related
+       software interact. Starting at the top of the diagram, we have:
+
+              ā€¢      The Cloud Management System, as defined above.
+
+              ā€¢      The OVN/CMS Plugin is the component of the CMS  that  inā€
+                     terfaces  to OVN. In OpenStack, this is a Neutron plugin.
+                     The pluginā€™s main purpose is to translate the  CMSā€™s  noā€
+                     tion  of  logical  network  configuration,  stored in the
+                     CMSā€™s configuration database in  a  CMS-specific  format,
+                     into an intermediate representation understood by OVN.
+
+                     This component is necessarily CMS-specific, so a new pluā€
+                     gin needs to be developed for each CMS that is integrated
+                     with OVN. All of the components below this one in the diā€
+                     agram are CMS-independent.
+
+              ā€¢      The  OVN  Northbound  Database  receives the intermediate
+                     representation of logical  network  configuration  passed
+                     down  by the OVN/CMS Plugin. The database schema is meant
+                     to be ``impedance matchedā€™ā€™ with the concepts used  in  a
+                     CMS,  so  that  it  directly  supports notions of logical
+                     switches, routers, ACLs, and so on. See ovn-nb(5) for deā€
+                     tails.
+
+                     The OVN Northbound Database has  only  two  clients:  the
+                     OVN/CMS Plugin above it and ovn-northd below it.
+
+              ā€¢      ovn-northd(8)  connects  to  the  OVN Northbound Database
+                     above it and the OVN Southbound  Database  below  it.  It
+                     translates  the logical network configuration in terms of
+                     conventional network concepts, taken from the OVN  Northā€
+                     bound  Database,  into  logical datapath flows in the OVN
+                     Southbound Database below it.
+
+              ā€¢      The OVN Southbound Database is the center of the  system.
+                     Its  clients  are  ovn-northd(8)  above  it  and ovn-conā€ā€
+                     troller(8) on every transport node below it.
+
+                     The OVN Southbound Database contains three kinds of data:
+                     Physical Network (PN) tables that specify  how  to  reach
+                     hypervisor  and  other nodes, Logical Network (LN) tables
+                     that describe the logical network in terms  of  ``logical
+                     datapath  flows,ā€™ā€™  and  Binding tables that link logical
+                     network componentsā€™ locations to  the  physical  network.
+                     The  hypervisors populate the PN and Port_Binding tables,
+                     whereas ovn-northd(8) populates the LN tables.
+
+                     OVN Southbound Database performance must scale  with  the
+                     number  of transport nodes. This will likely require some
+                     work on  ovsdb-server(1)  as  we  encounter  bottlenecks.
+                     Clustering for availability may be needed.
+
+       The remaining components are replicated onto each hypervisor:
+
+              ā€¢      ovn-controller(8)  is  OVNā€™s agent on each hypervisor and
+                     software gateway. Northbound,  it  connects  to  the  OVN
+                     Southbound  Database to learn about OVN configuration and
+                     status and to populate the PN table and the Chassis  colā€
+                     umn in Binding table with the hypervisorā€™s status. Southā€
+                     bound, it connects to ovs-vswitchd(8) as an OpenFlow conā€
+                     troller, for control over network traffic, and to the loā€
+                     cal  ovsdb-server(1)  to  allow it to monitor and control
+                     Open vSwitch configuration.
+
+              ā€¢      ovs-vswitchd(8) and ovsdb-server(1) are conventional comā€
+                     ponents of Open vSwitch.
+
+                                         CMS
+                                          |
+                                          |
+                              +-----------|-----------+
+                              |           |           |
+                              |     OVN/CMS Plugin    |
+                              |           |           |
+                              |           |           |
+                              |   OVN Northbound DB   |
+                              |           |           |
+                              |           |           |
+                              |       ovn-northd      |
+                              |           |           |
+                              +-----------|-----------+
+                                          |
+                                          |
+                                +-------------------+
+                                | OVN Southbound DB |
+                                +-------------------+
+                                          |
+                                          |
+                       +------------------+------------------+
+                       |                  |                  |
+         HV 1          |                  |    HV n          |
+       +---------------|---------------+  .  +---------------|---------------+
+       |               |               |  .  |               |               |
+       |        ovn-controller         |  .  |        ovn-controller         |
+       |         |          |          |  .  |         |          |          |
+       |         |          |          |     |         |          |          |
+       |  ovs-vswitchd   ovsdb-server  |     |  ovs-vswitchd   ovsdb-server  |
+       |                               |     |                               |
+       +-------------------------------+     +-------------------------------+
+
+
+   Information Flow in OVN
+       Configuration data in OVN flows from north to south. The  CMS,  through
+       its  OVN/CMS  plugin,  passes  the  logical  network  configuration  to
+       ovn-northd via the northbound database. In  turn,  ovn-northd  compiles
+       the  configuration  into a lower-level form and passes it to all of the
+       chassis via the southbound database.
+
+       Status information in OVN flows from south to north. OVN currently proā€
+       vides only a few forms of status information. First,  ovn-northd  popuā€
+       lates  the  up column in the northbound Logical_Switch_Port table: if a
+       logical portā€™s chassis column in the southbound Port_Binding  table  is
+       nonempty,  it  sets up to true, otherwise to false. This allows the CMS
+       to detect when a VMā€™s networking has come up.
+
+       Second, OVN provides feedback to the CMS on the realization of its conā€
+       figuration, that is, whether the configuration provided by the CMS  has
+       taken  effect.  This  feature  requires the CMS to participate in a seā€
+       quence number protocol, which works the following way:
+
+              1.  When the CMS updates the  configuration  in  the  northbound
+                  database, as part of the same transaction, it increments the
+                  value  of the nb_cfg column in the NB_Global table. (This is
+                  only necessary if the CMS wants to know when the  configuraā€
+                  tion has been realized.)
+
+              2.  When  ovn-northd  updates the southbound database based on a
+                  given snapshot of the northbound database, it copies  nb_cfg
+                  from  northbound  NB_Global  into  the  southbound  database
+                  SB_Global table, as part of the same transaction. (Thus,  an
+                  observer  monitoring  both  databases can determine when the
+                  southbound database is caught up with the northbound.)
+
+              3.  After ovn-northd receives confirmation from  the  southbound
+                  database  server that its changes have committed, it updates
+                  sb_cfg in the northbound NB_Global table to the nb_cfg  verā€
+                  sion  that  was  pushed  down. (Thus, the CMS or another obā€
+                  server can determine when the southbound database is  caught
+                  up without a connection to the southbound database.)
+
+              4.  The  ovn-controller process on each chassis receives the upā€
+                  dated southbound database, with  the  updated  nb_cfg.  This
+                  process  in turn updates the physical flows installed in the
+                  chassisā€™s Open vSwitch instances. When it receives confirmaā€
+                  tion from Open vSwitch that the physical flows have been upā€
+                  dated, it updates nb_cfg in its own Chassis  record  in  the
+                  southbound database.
+
+              5.  ovn-northd  monitors the nb_cfg column in all of the Chassis
+                  records in the southbound database. It keeps  track  of  the
+                  minimum  value  among all the records and copies it into the
+                  hv_cfg column in the northbound NB_Global table. (Thus,  the
+                  CMS or another observer can determine when all of the hyperā€
+                  visors have caught up to the northbound configuration.)
+
+   Chassis Setup
+       Each  chassis  in  an  OVN  deployment  must be configured with an Open
+       vSwitch bridge dedicated for OVNā€™s use, called the integration  bridge.
+       System  startup  scripts  may  create  this  bridge  prior  to starting
+       ovn-controller if desired. If this bridge does not exist when  ovn-conā€
+       troller  starts, it will be created automatically with the default conā€
+       figuration suggested below. The ports on  the  integration  bridge  inā€
+       clude:
+
+              ā€¢      On  any  chassis,  tunnel ports that OVN uses to maintain
+                     logical network connectivity.  ovn-controller  adds,  upā€
+                     dates, and removes these tunnel ports.
+
+              ā€¢      On a hypervisor, any VIFs that are to be attached to logā€
+                     ical  networks.  For instances connected through software
+                     emulated ports such as TUN/TAP or VETH pairs, the  hyperā€
+                     visor  itself  will  normally  create ports and plug them
+                     into the  integration  bridge.  For  instances  connected
+                     through  representor  ports, typically used with hardware
+                     offload, the ovn-controller may on CMS direction  consult
+                     a  VIF plug provider for representor port lookup and plug
+                     them into the integration bridge (please refer  to  Docuā€ā€
+                     mentation/topā€ā€
+                     ics/vif-plug-providers/vif-plug-providers.rst
+                      for more information). In both cases the conventions deā€
+                     scribed  in  Documentation/topics/integration.rst  in the
+                     Open vSwitch source tree is followed  to  ensure  mapping
+                     between  OVN  logical port and VIF. (This is pre-existing
+                     integration work that has already been done  on  hyperviā€
+                     sors that support OVS.)
+
+              ā€¢      On  a gateway, the physical port used for logical network
+                     connectivity. System startup scripts add this port to the
+                     bridge prior to starting ovn-controller. This  can  be  a
+                     patch port to another bridge, instead of a physical port,
+                     in more sophisticated setups.
+
+       Other  ports  should not be attached to the integration bridge. In parā€
+       ticular, physical ports attached to the underlay network (as opposed to
+       gateway ports, which are physical ports attached to  logical  networks)
+       must not be attached to the integration bridge. Underlay physical ports
+       should instead be attached to a separate Open vSwitch bridge (they need
+       not be attached to any bridge at all, in fact).
+
+       The integration bridge should be configured as described below. The efā€
+       fect    of    each    of    these    settings    is    documented    in
+       ovs-vswitchd.conf.db(5):
+
+              fail-mode=secure
+                     Avoids switching packets between  isolated  logical  netā€
+                     works  before  ovn-controller  starts  up. See Controller
+                     Failure Settings in ovs-vsctl(8) for more information.
+
+              other-config:disable-in-band=true
+                     Suppresses in-band  control  flows  for  the  integration
+                     bridge.  It  would  be  unusual for such flows to show up
+                     anyway, because OVN uses a local controller (over a  Unix
+                     domain  socket) instead of a remote controller. Itā€™s posā€
+                     sible, however, for some other bridge in the same  system
+                     to  have  an  in-band remote controller, and in that case
+                     this suppresses the flows that in-band control would  orā€
+                     dinarily  set up. Refer to the documentation for more inā€
+                     formation.
+
+       The customary name for the integration bridge is  br-int,  but  another
+       name may be used.
+
+   Logical Networks
+       Logical  network  concepts  in OVN include logical switches and logical
+       routers, the logical version of Ethernet switches and IP  routers,  reā€
+       spectively.  Like  their physical cousins, logical switches and routers
+       can be connected into sophisticated topologies.  Logical  switches  and
+       routers  are  ordinarily purely logical entities, that is, they are not
+       associated or bound to any physical location, and they are  implemented
+       in a distributed manner at each hypervisor that participates in OVN.
+
+       Logical  switch ports (LSPs) are points of connectivity into and out of
+       logical switches. There are many kinds of  logical  switch  ports.  The
+       most  ordinary  kind represent VIFs, that is, attachment points for VMs
+       or containers. A VIF logical port is associated with the physical locaā€
+       tion of its VM, which might change as the VM migrates. (A  VIF  logical
+       port  can  be  associated  with a VM that is powered down or suspended.
+       Such a logical port has no location and no connectivity.)
+
+       Logical router ports (LRPs) are points of connectivity into and out  of
+       logical  routers.  A  LRP connects a logical router either to a logical
+       switch or to another logical router. Logical routers  only  connect  to
+       VMs,  containers,  and  other network nodes indirectly, through logical
+       switches.
+
+       Logical switches and logical routers have  distinct  kinds  of  logical
+       ports,  so  properly  speaking  one  should  usually talk about logical
+       switch ports or logical router ports. However, an unqualified ``logical
+       portā€™ā€™ usually refers to a logical switch port.
+
+       When a VM sends a packet to a VIF logical switch port, the Open vSwitch
+       flow tables simulate the packetā€™s journey through that  logical  switch
+       and  any  other  logical routers and logical switches that it might enā€
+       counter. This happens without transmitting the packet across any physiā€
+       cal medium: the flow tables implement all of the switching and  routing
+       decisions  and behavior. If the flow tables ultimately decide to output
+       the packet at a logical port attached to another hypervisor (or another
+       kind of transport node), then that is the time at which the  packet  is
+       encapsulated for physical network transmission and sent.
+
+     Logical Switch Port Types
+
+       OVN  supports a number of kinds of logical switch ports. VIF ports that
+       connect to VMs or containers, described above, are  the  most  ordinary
+       kind  of  LSP.  In the OVN northbound database, VIF ports have an empty
+       string for their type. This section describes some  of  the  additional
+       port types.
+
+       A  router  logical  switch  port connects a logical switch to a logical
+       router, designating a particular LRP as its peer.
+
+       A localnet logical switch port bridges a logical switch to  a  physical
+       VLAN. A logical switch may have one or more localnet ports. Such a logā€
+       ical switch is used in two scenarios:
+
+              ā€¢      With  one  or more router logical switch ports, to attach
+                     L3 gateway routers and distributed gateways to a physical
+                     network.
+
+              ā€¢      With one or more VIF logical switch ports, to attach  VMs
+                     or  containers  directly  to  a physical network. In this
+                     case, the logical switch is not really logical, since  it
+                     is  bridged to the physical network rather than insulated
+                     from it, and therefore cannot have independent but  overā€
+                     lapping  IP  address  namespaces, etc. A deployment might
+                     nevertheless choose such a configuration to  take  advanā€
+                     tage  of  the OVN control plane and features such as port
+                     security and ACLs.
+
+       When a logical switch contains multiple localnet ports,  the  following
+       is assumed.
+
+              ā€¢      Each chassis has a bridge mapping for one of the localnet
+                     physical networks only.
+
+              ā€¢      To  facilitate interconnectivity between VIF ports of the
+                     switch that are located on different chassis with differā€
+                     ent physical network connectivity, the fabric  implements
+                     L3  routing  between these adjacent physical network segā€
+                     ments.
+
+       Note: nothing said above implies that a chassis cannot  be  plugged  to
+       multiple  physical  networks  as  long  as  they  belong  to  different
+       switches.
+
+       A localport logical switch port is a special kind of VIF logical switch
+       port. These ports are present in every chassis, not bound to  any  parā€
+       ticular  one.  Traffic to such a port will never be forwarded through a
+       tunnel, and traffic from such a port is expected to be destined only to
+       the same chassis, typically in response to a request it received. Openā€
+       Stack Neutron uses a localport port to serve metadata to VMs.  A  metaā€
+       data  proxy  process is attached to this port on every host and all VMs
+       within the same network will reach it at the same IP/MAC address  withā€
+       out  any traffic being sent over a tunnel. For further details, see the
+       OpenStack documentation for networking-ovn.
+
+       LSP types vtep and l2gateway are used for gateways. See  Gateways,  beā€
+       low, for more information.
+
+     Implementation Details
+
+       These  concepts  are details of how OVN is implemented internally. They
+       might still be of interest to users and administrators.
+
+       Logical datapaths are an implementation detail of logical  networks  in
+       the  OVN southbound database. ovn-northd translates each logical switch
+       or router in the northbound database into a  logical  datapath  in  the
+       southbound database Datapath_Binding table.
+
+       For  the most part, ovn-northd also translates each logical switch port
+       in the OVN northbound database into a record in the southbound database
+       Port_Binding table. The latter table corresponds roughly to the  northā€
+       bound  Logical_Switch_Port table. It has multiple types of logical port
+       bindings, of which many types correspond  directly  to  northbound  LSP
+       types. LSP types handled this way include VIF (empty string), localnet,
+       localport, vtep, and l2gateway.
+
+       The  Port_Binding table has some types of port binding that do not corā€
+       respond directly to logical switch port types. The common is patch port
+       bindings, known as logical patch ports. These port bindings always  ocā€
+       cur  in pairs, and a packet that enters on either side comes out on the
+       other. ovn-northd connects logical switches  and  logical  routers  toā€
+       gether using logical patch ports.
+
+       Port  bindings  with types vtep, l2gateway, l3gateway, and chassisrediā€ā€
+       rect are used for gateways. These are explained in Gateways, below.
+
+   Gateways
+       Gateways provide limited  connectivity  between  logical  networks  and
+       physical ones. They can also provide connectivity between different OVN
+       deployments. This section will focus on the former, and the latter will
+       be described in details in section OVN Deployments Interconnection.
+
+       OVN support multiple kinds of gateways.
+
+     VTEP Gateways
+
+       A  ``VTEP  gatewayā€™ā€™  connects an OVN logical network to a physical (or
+       virtual) switch that implements the OVSDB VTEP schema that  accompanies
+       Open vSwitch. (The ``VTEP gatewayā€™ā€™ term is a misnomer, since a VTEP is
+       just  a  VXLAN Tunnel Endpoint, but it is a well established name.) See
+       Life Cycle of a VTEP gateway, below, for more information.
+
+       The main intended use case for VTEP  gateways  is  to  attach  physical
+       servers  to  an OVN logical network using a physical top-of-rack switch
+       that supports the OVSDB VTEP schema.
+
+     L2 Gateways
+
+       A L2 gateway simply attaches a designated physical L2 segment available
+       on some chassis to a logical network. The physical network  effectively
+       becomes part of the logical network.
+
+       To set up a L2 gateway, the CMS adds an l2gateway LSP to an appropriate
+       logical  switch,  setting  LSP  options to name the chassis on which it
+       should be bound. ovn-northd copies this configuration into a southbound
+       Port_Binding record. On the designated chassis, ovn-controller forwards
+       packets appropriately to and from the physical segment.
+
+       L2 gateway ports have features in common with localnet ports.  However,
+       with  a  localnet  port, the physical network becomes the transport beā€
+       tween hypervisors. With an L2 gateway, packets  are  still  transported
+       between  hypervisors  over  tunnels and the l2gateway port is only used
+       for the packets that are on the physical network. The  application  for
+       L2  gateways is similar to that for VTEP gateways, e.g. to add non-virā€
+       tualized machines to a logical network, but L2 gateways do not  require
+       special support from top-of-rack hardware switches.
+
+     L3 Gateway Routers
+
+       As described above under Logical Networks, ordinary OVN logical routers
+       are  distributed: they are not implemented in a single place but rather
+       in every hypervisor chassis. This is a problem  for  stateful  services
+       such  as  SNAT  and DNAT, which need to be implemented in a centralized
+       manner.
+
+       To allow for this  kind  of  functionality,  OVN  supports  L3  gateway
+       routers, which are OVN logical routers that are implemented in a desigā€
+       nated  chassis.  Gateway routers are typically used between distributed
+       logical routers and physical networks. The distributed  logical  router
+       and the logical switches behind it, to which VMs and containers attach,
+       effectively  reside  on each hypervisor. The distributed router and the
+       gateway router are connected by another logical switch,  sometimes  reā€
+       ferred  to  as  a  ``joinā€™ā€™ logical switch. (OVN logical routers may be
+       connected to one another directly, without an intervening  switch,  but
+       the  OVN  implementation only supports gateway logical routers that are
+       connected to logical switches. Using a join logical switch also reduces
+       the number of IP addresses needed on the distributed  router.)  On  the
+       other  side, the gateway router connects to another logical switch that
+       has a localnet port connecting to the physical network.
+
+       The following diagram shows a typical situation. One  or  more  logical
+       switches LS1, ..., LSn connect to distributed logical router LR1, which
+       in  turn  connects  through LSjoin to gateway logical router GLR, which
+       also connects to logical switch LSlocal, which includes a localnet port
+       to attach to the physical network.
+
+                                       LSlocal
+                                          |
+                                         GLR
+                                          |
+                                       LSjoin
+                                          |
+                                         LR1
+                                          |
+                                     +----+----+
+                                     |    |    |
+                                    LS1  ...  LSn
+
+
+       To configure an L3 gateway router, the CMS sets options:chassis in  the
+       routerā€™s  northbound Logical_Router to the chassisā€™s name. In response,
+       ovn-northd uses a special l3gateway port binding (instead  of  a  patch
+       binding)  in  the  southbound database to connect the logical router to
+       its neighbors. In turn, ovn-controller tunnels  packets  to  this  port
+       binding  to  the  designated  L3 gateway chassis, instead of processing
+       them locally.
+
+       DNAT and SNAT rules may be associated with a gateway router, which proā€
+       vides a central location that can handle one-to-many SNAT (aka IP  masā€
+       querading).  Distributed  gateway  ports, described below, also support
+       NAT.
+
+     Distributed Gateway Ports
+
+       A distributed gateway port is a logical router port that  is  specially
+       configured  to  designate one distinguished chassis, called the gateway
+       chassis, for centralized processing. A distributed gateway port  should
+       connect  to  a logical switch that has an LSP that connects externally,
+       that is, either a localnet LSP or a connection to another  OVN  deployā€
+       ment  (see  OVN Deployments Interconnection). Packets that traverse the
+       distributed gateway port are processed without  involving  the  gateway
+       chassis  when  they  can  be, but when needed they do take an extra hop
+       through it.
+
+       The following diagram illustrates the  use  of  a  distributed  gateway
+       port. A number of logical switches LS1, ..., LSn connect to distributed
+       logical  router  LR1,  which  in  turn connects through the distributed
+       gateway port to logical switch LSlocal that includes a localnet port to
+       attach to the physical network.
+
+                                       LSlocal
+                                          |
+                                         LR1
+                                          |
+                                     +----+----+
+                                     |    |    |
+                                    LS1  ...  LSn
+
+
+       ovn-northd creates two southbound Port_Binding records to  represent  a
+       distributed  gateway  port, instead of the usual one. One of these is a
+       patch port binding named for the LRP, which is used for as much traffic
+       as it can. The other one is a port binding with  type  chassisredirect,
+       named  cr-port.  The  chassisredirect  port binding has one specialized
+       job: when a packet is output to it, the flow table causes it to be tunā€
+       neled to the gateway chassis, at which point it is automatically output
+       to the patch port binding. Thus, the flow table can output to this port
+       binding in cases where a particular task has to happen on  the  gateway
+       chassis.  The  chassisredirect  port binding is not otherwise used (for
+       example, it never receives packets).
+
+       The CMS may configure distributed gateway ports three  different  ways.
+       See   Distributed   Gateway   Ports  in  the  documentation  for  Logiā€ā€
+       cal_Router_Port in ovn-nb(5) for details.
+
+       Distributed gateway ports support high availability. When more than one
+       chassis is specified, OVN only uses one at a time as the gateway  chasā€
+       sis. OVN uses BFD to monitor gateway connectivity, preferring the highā€
+       est-priority gateway that is online.
+
+       A logical router can have multiple distributed gateway ports, each conā€
+       necting  different  external  networks.  Load balancing is not yet supā€
+       ported for logical routers with more than one distributed gateway  port
+       configured.
+
+       Physical VLAN MTU Issues
+
+       Consider the preceding diagram again:
+
+                                       LSlocal
+                                          |
+                                         LR1
+                                          |
+                                     +----+----+
+                                     |    |    |
+                                    LS1  ...  LSn
+
+
+       Suppose that each logical switch LS1, ..., LSn is bridged to a physical
+       VLAN-tagged network attached to a localnet port on LSlocal, over a disā€
+       tributed  gateway  port  on LR1. If a packet originating on LSi is desā€
+       tined to the external network, OVN sends it to the gateway chassis over
+       a tunnel. There, the packet traverses LR1ā€™s  logical  router  pipeline,
+       possibly  undergoes  NAT,  and eventually ends up at LSlocalā€™s localnet
+       port. If all of the physical links in the network have  the  same  MTU,
+       then the packetā€™s transit across a tunnel causes an MTU problem: tunnel
+       overhead  prevents a packet that uses the full physical MTU from crossā€
+       ing the tunnel to the gateway chassis (without fragmentation).
+
+       OVN offers two solutions to this problem, the  reside-on-redirect-chasā€ā€
+       sis  and  redirect-type  options.  Both  solutions require each logical
+       switch LS1, ..., LSn to include a localnet  logical  switch  port  LN1,
+       ...,  LNn  respectively,  that  is  present on each chassis. Both cause
+       packets to be sent over the localnet ports  instead  of  tunnels.  They
+       differ  in which packets-some or all-are sent this way. The most promiā€
+       nent tradeoff between these options is that  reside-on-redirect-chassis
+       is easier to configure and that redirect-type performs better for east-
+       west traffic.
+
+       The first solution is the reside-on-redirect-chassis option for logical
+       router  ports. Setting this option on a LRP from (e.g.) LS1 to LR1 disā€
+       ables forwarding from LS1 to LR1 except  on  the  gateway  chassis.  On
+       chassis  other  than the gateway chassis, this single change means that
+       packets that would otherwise have been forwarded  to  LR1  are  instead
+       forwarded  to  LN1. The instance of LN1 on the gateway chassis then reā€
+       ceives the packet and forwards it to LR1. The packet traverses the  LR1
+       logical router pipeline, possibly undergoes NAT, and eventually ends up
+       at LSlocalā€™s localnet port. The packet never traverses a tunnel, avoidā€
+       ing the MTU issue.
+
+       This option has the further consequence of centralizing ``distributedā€™ā€™
+       logical  router  LR1, since no packets are forwarded from LS1 to LR1 on
+       any chassis other than the gateway chassis. Therefore, east-west  trafā€
+       fic  passes  through  the  gateway  chassis, not just north-south. (The
+       naive ``fixā€™ā€™ of allowing east-west traffic to  flow  directly  between
+       chassis over LN1 does not work because routing sets the Ethernet source
+       address to LR1ā€™s source address. Seeing this single Ethernet source adā€
+       dress  originate  from  all  of  the  chassis will confuse the physical
+       switch.)
+
+       Do not set the reside-on-redirect-chassis option on a distributed gateā€
+       way port. In the diagram above, it would be set on the LRPs  connecting
+       LS1, ..., LSn to LR1.
+
+       The second solution is the redirect-type option for distributed gateway
+       ports.  Setting  this  option  to bridged causes packets that are rediā€
+       rected to the gateway chassis to go over the localnet ports instead  of
+       being  tunneled. This option does not change how OVN treats packets not
+       redirected to the gateway chassis.
+
+       The redirect-type option requires the administrator or the CMS to  conā€
+       figure  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. This makes it more diffiā€
+       cult to configure than reside-on-redirect-chassis.
+
+       Set the redirect-type option on a distributed gateway port.
+
+       Using Distributed Gateway Ports For Scalability
+
+       Although the primary goal of distributed gateway ports  is  to  provide
+       connectivity  to  external  networks,  there  is a special use case for
+       scalability.
+
+       In some deployments, such as the  ones  using  ovn-kubernetes,  logical
+       switches are bound to individual chassises, and are connected by a disā€
+       tributed logical router. In such deployments, the chassis level logical
+       switches  are  centralized on the chassis instead of distributed, which
+       means the ovn-controller on each chassis doesnā€™t need to process  flows
+       and  ports of logical switches on other chassises. However, without any
+       specific hint, ovn-controller  would  still  process  all  the  logical
+       switches  as  if  they are fully distributed. In this case, distributed
+       gateway port can be very useful. The chassis level logical switches can
+       be connected to the distributed router using distributed gateway ports,
+       by setting the gateway chassis (or HA chassis groups with only a single
+       chassis in it) to the chassis that each logical  switch  is  bound  to.
+       ovn-controller  would  then skip processing the logical switches on all
+       the other chassises, largely improving the scalability, especially when
+       there are a big number of chassises.
+
+   Life Cycle of a VIF
+       Tables and their schemas presented in isolation are difficult to underā€
+       stand. Hereā€™s an example.
+
+       A VIF on a hypervisor is a virtual network interface attached either to
+       a VM or a container running directly on that hypervisor (This  is  difā€
+       ferent from the interface of a container running inside a VM).
+
+       The  steps  in  this  example refer often to details of the OVN and OVN
+       Northbound database schemas. Please see ovn-sb(5)  and  ovn-nb(5),  reā€
+       spectively, for the full story on these databases.
+
+              1.  A VIFā€™s life cycle begins when a CMS administrator creates a
+                  new VIF using the CMS user interface or API and adds it to a
+                  switch (one implemented by OVN as a logical switch). The CMS
+                  updates  its  own  configuration.  This includes associating
+                  unique, persistent identifier vif-id  and  Ethernet  address
+                  mac with the VIF.
+
+              2.  The  CMS  plugin  updates the OVN Northbound database to inā€
+                  clude  the  new  VIF,  by  adding  a  row   to   the   Logiā€ā€
+                  cal_Switch_Port  table.  In the new row, name is vif-id, mac
+                  is mac, switch points to  the  OVN  logical  switchā€™s  Logiā€
+                  cal_Switch  record, and other columns are initialized approā€
+                  priately.
+
+              3.  ovn-northd receives the OVN Northbound database  update.  In
+                  turn,  it  makes the corresponding updates to the OVN Southā€
+                  bound database, by adding rows to the OVN  Southbound  dataā€
+                  base  Logical_Flow table to reflect the new port, e.g. add a
+                  flow to recognize that packets destined to  the  new  portā€™s
+                  MAC  address  should be delivered to it, and update the flow
+                  that delivers broadcast and multicast packets to include the
+                  new port. It also creates a record in the Binding table  and
+                  populates  all its columns except the column that identifies
+                  the chassis.
+
+              4.  On  every  hypervisor,  ovn-controller  receives  the  Logiā€ā€
+                  cal_Flow  table updates that ovn-northd made in the previous
+                  step. As long as the VM that owns the VIF  is  powered  off,
+                  ovn-controller  cannot  do  much;  it  cannot,  for example,
+                  arrange to send packets to or receive packets from the  VIF,
+                  because the VIF does not actually exist anywhere.
+
+              5.  Eventually,  a  user  powers on the VM that owns the VIF. On
+                  the hypervisor where the VM is powered on,  the  integration
+                  between  the hypervisor and Open vSwitch (described in Docuā€ā€
+                  mentation/topics/integration.rst in the Open vSwitch  source
+                  tree)  adds the VIF to the OVN integration bridge and stores
+                  vif-id in external_ids:iface-id to indicate that the  interā€
+                  face  is an instantiation of the new VIF. (None of this code
+                  is new in OVN; this is pre-existing  integration  work  that
+                  has already been done on hypervisors that support OVS.)
+
+              6.  On the hypervisor where the VM is powered on, ovn-controller
+                  notices  external_ids:iface-id  in the new Interface. In reā€
+                  sponse, in the OVN Southbound DB, it updates the Binding taā€
+                  bleā€™s chassis column for the row that links the logical port
+                  from external_ids: iface-id to  the  hypervisor.  Afterward,
+                  ovn-controller  updates  the local hypervisorā€™s OpenFlow taā€
+                  bles so that packets to and from the VIF are  properly  hanā€
+                  dled.
+
+              7.  Some CMS systems, including OpenStack, fully start a VM only
+                  when  its  networking  is ready. To support this, ovn-northd
+                  notices the chassis column updated for the  row  in  Binding
+                  table  and  pushes  this upward by updating the up column in
+                  the OVN Northbound databaseā€™s Logical_Switch_Port  table  to
+                  indicate  that  the  VIF is now up. The CMS, if it uses this
+                  feature, can then react by allowing the  VMā€™s  execution  to
+                  proceed.
+
+              8.  On  every  hypervisor  but  the  one  where the VIF resides,
+                  ovn-controller notices the completely populated row  in  the
+                  Binding table. This provides ovn-controller the physical loā€
+                  cation  of  the  logical  port, so each instance updates the
+                  OpenFlow tables of its switch  (based  on  logical  datapath
+                  flows  in  the OVN DB Logical_Flow table) so that packets to
+                  and from the VIF can be properly handled via tunnels.
+
+              9.  Eventually, a user powers off the VM that owns the  VIF.  On
+                  the  hypervisor  where  the  VM  was powered off, the VIF is
+                  deleted from the OVN integration bridge.
+
+              10. On the hypervisor where the VM  was  powered  off,  ovn-conā€ā€
+                  troller  notices  that  the VIF was deleted. In response, it
+                  removes the Chassis column content in the Binding table  for
+                  the logical port.
+
+              11. On  every hypervisor, ovn-controller notices the empty Chasā€ā€
+                  sis column in the Binding tableā€™s row for the logical  port.
+                  This  means that ovn-controller no longer knows the physical
+                  location of the logical port, so each instance  updates  its
+                  OpenFlow table to reflect that.
+
+              12. Eventually,  when  the  VIF  (or its entire VM) is no longer
+                  needed by anyone, an administrator deletes the VIF using the
+                  CMS user interface or API. The CMS updates its own  configuā€
+                  ration.
+
+              13. The CMS plugin removes the VIF from the OVN Northbound dataā€
+                  base, by deleting its row in the Logical_Switch_Port table.
+
+              14. ovn-northd  receives  the  OVN Northbound update and in turn
+                  updates the OVN Southbound database accordingly, by removing
+                  or updating the rows from the OVN Southbound database  Logiā€ā€
+                  cal_Flow  table  and  Binding table that were related to the
+                  now-destroyed VIF.
+
+              15. On  every  hypervisor,  ovn-controller  receives  the  Logiā€ā€
+                  cal_Flow  table updates that ovn-northd made in the previous
+                  step. ovn-controller updates OpenFlow tables to reflect  the
+                  update,  although there may not be much to do, since the VIF
+                  had already become unreachable when it was removed from  the
+                  Binding table in a previous step.
+
+   Life Cycle of a Container Interface Inside a VM
+       OVN  provides  virtual  network  abstractions by converting information
+       written in OVN_NB database to OpenFlow flows in each hypervisor. Secure
+       virtual networking for multi-tenants can only be provided if  OVN  conā€
+       troller  is the only entity that can modify flows in Open vSwitch. When
+       the Open vSwitch integration bridge resides in the hypervisor, it is  a
+       fair assumption to make that tenant workloads running inside VMs cannot
+       make any changes to Open vSwitch flows.
+
+       If  the infrastructure provider trusts the applications inside the conā€
+       tainers not to break out and modify the Open vSwitch flows,  then  conā€
+       tainers  can be run in hypervisors. This is also the case when containā€
+       ers are run inside the VMs and Open  vSwitch  integration  bridge  with
+       flows  added  by  OVN  controller  resides in the same VM. For both the
+       above cases, the workflow is the same as explained with an  example  in
+       the previous section ("Life Cycle of a VIF").
+
+       This  section talks about the life cycle of a container interface (CIF)
+       when containers are created in the VMs and the Open vSwitch integration
+       bridge resides inside the hypervisor. In this case, even if a container
+       application breaks out, other tenants are not affected because the conā€
+       tainers running inside the VMs cannot modify  the  flows  in  the  Open
+       vSwitch integration bridge.
+
+       When  multiple  containers  are created inside a VM, there are multiple
+       CIFs associated with them. The network traffic  associated  with  these
+       CIFs  need  to reach the Open vSwitch integration bridge running in the
+       hypervisor for OVN to support virtual network abstractions. OVN  should
+       also be able to distinguish network traffic coming from different CIFs.
+       There are two ways to distinguish network traffic of CIFs.
+
+       One  way  is  to  provide one VIF for every CIF (1:1 model). This means
+       that there could be a lot of network devices in  the  hypervisor.  This
+       would slow down OVS because of all the additional CPU cycles needed for
+       the management of all the VIFs. It would also mean that the entity creā€
+       ating  the  containers in a VM should also be able to create the correā€
+       sponding VIFs in the hypervisor.
+
+       The second way is to provide a single VIF  for  all  the  CIFs  (1:many
+       model).  OVN could then distinguish network traffic coming from differā€
+       ent CIFs via a tag written in every packet. OVN uses this mechanism and
+       uses VLAN as the tagging mechanism.
+
+              1.  A CIFā€™s life cycle begins when a container is spawned inside
+                  a VM by the either the same CMS that created  the  VM  or  a
+                  tenant  that  owns that VM or even a container Orchestration
+                  System that is different than the CMS that initially created
+                  the VM. Whoever the entity is, it will need to know the vif-
+                  id that is associated with the network interface of  the  VM
+                  through  which  the container interfaceā€™s network traffic is
+                  expected to go through. The entity  that  creates  the  conā€
+                  tainer interface will also need to choose an unused VLAN inā€
+                  side that VM.
+
+              2.  The  container  spawning  entity (either directly or through
+                  the CMS that manages the underlying infrastructure)  updates
+                  the  OVN  Northbound  database  to  include  the new CIF, by
+                  adding a row to the Logical_Switch_Port table.  In  the  new
+                  row,  name is any unique identifier, parent_name is the vif-
+                  id of the VM through which the CIFā€™s network traffic is  exā€
+                  pected  to go through and the tag is the VLAN tag that idenā€
+                  tifies the network traffic of that CIF.
+
+              3.  ovn-northd receives the OVN Northbound database  update.  In
+                  turn,  it  makes the corresponding updates to the OVN Southā€
+                  bound database, by adding rows to the OVN  Southbound  dataā€
+                  baseā€™s  Logical_Flow  table to reflect the new port and also
+                  by creating a new row in the Binding  table  and  populating
+                  all  its columns except the column that identifies the chasā€ā€
+                  sis.
+
+              4.  On  every  hypervisor,  ovn-controller  subscribes  to   the
+                  changes  in  the Binding table. When a new row is created by
+                  ovn-northd that includes a value in  parent_port  column  of
+                  Binding  table,  the  ovn-controller in the hypervisor whose
+                  OVN integration bridge has that same value in vif-id in  exā€ā€
+                  ternal_ids:iface-id  updates the local hypervisorā€™s OpenFlow
+                  tables so that packets to and from the VIF with the particuā€
+                  lar VLAN tag are properly handled. Afterward it updates  the
+                  chassis  column of the Binding to reflect the physical locaā€
+                  tion.
+
+              5.  One can only start the application inside the container  afā€
+                  ter  the  underlying  network  is  ready.  To  support this,
+                  ovn-northd notices the updated chassis column in Binding taā€
+                  ble and updates the up column in the  OVN  Northbound  dataā€
+                  baseā€™s Logical_Switch_Port table to indicate that the CIF is
+                  now up. The entity responsible to start the container appliā€
+                  cation queries this value and starts the application.
+
+              6.  Eventually  the  entity  that  created  and started the conā€
+                  tainer, stops it. The entity, through the CMS (or  directly)
+                  deletes its row in the Logical_Switch_Port table.
+
+              7.  ovn-northd  receives  the  OVN Northbound update and in turn
+                  updates the OVN Southbound database accordingly, by removing
+                  or updating the rows from the OVN Southbound database  Logiā€ā€
+                  cal_Flow  table  that were related to the now-destroyed CIF.
+                  It also deletes the row in the Binding table for that CIF.
+
+              8.  On  every  hypervisor,  ovn-controller  receives  the  Logiā€ā€
+                  cal_Flow  table updates that ovn-northd made in the previous
+                  step. ovn-controller updates OpenFlow tables to reflect  the
+                  update.
+
+   Architectural Physical Life Cycle of a Packet
+       This section describes how a packet travels from one virtual machine or
+       container to another through OVN. This description focuses on the physā€
+       ical treatment of a packet; for a description of the logical life cycle
+       of a packet, please refer to the Logical_Flow table in ovn-sb(5).
+
+       This  section  mentions  several  data and metadata fields, for clarity
+       summarized here:
+
+              tunnel key
+                     When OVN encapsulates a packet in Geneve or another  tunā€
+                     nel,  it attaches extra data to it to allow the receiving
+                     OVN instance to process it correctly. This takes  differā€
+                     ent  forms depending on the particular encapsulation, but
+                     in each case we refer to it here as the  ``tunnel  key.ā€™ā€™
+                     See Tunnel Encapsulations, below, for details.
+
+              logical datapath field
+                     A field that denotes the logical datapath through which a
+                     packet  is being processed. OVN uses the field that Openā€
+                     Flow 1.1+ simply (and confusingly) calls ``metadataā€™ā€™  to
+                     store  the logical datapath. (This field is passed across
+                     tunnels as part of the tunnel key.)
+
+              logical input port field
+                     A field that denotes the  logical  port  from  which  the
+                     packet  entered  the logical datapath. OVN stores this in
+                     Open vSwitch extension register number 14.
+
+                     Geneve and STT tunnels pass this field  as  part  of  the
+                     tunnel  key.  Ramp switch VXLAN tunnels do not explicitly
+                     carry a logical input port, but since they  are  used  to
+                     communicate  with  gateways  that  from OVNā€™s perspective
+                     consist of only a single logical port, so  that  OVN  can
+                     set  the  logical input port field to this one on ingress
+                     to the OVN logical pipeline. As for  regular  VXLAN  tunā€
+                     nels, they donā€™t carry input port field at all. This puts
+                     additional  limitations  on cluster capabilities that are
+                     described in Tunnel Encapsulations section.
+
+              logical output port field
+                     A field that denotes the  logical  port  from  which  the
+                     packet  will leave the logical datapath. This is initialā€
+                     ized to  0  at  the  beginning  of  the  logical  ingress
+                     pipeline.  OVN stores this in Open vSwitch extension regā€
+                     ister number 15.
+
+                     Geneve, STT and regular VXLAN tunnels pass this field  as
+                     part  of the tunnel key. Ramp switch VXLAN tunnels do not
+                     transmit the logical output port field, and since they do
+                     not carry a logical output port field in the tunnel  key,
+                     when  a  packet is received from ramp switch VXLAN tunnel
+                     by an OVN hypervisor, the packet is resubmitted to  table
+                     8  to  determine  the  output  port(s);  when  the packet
+                     reaches table 39, these packets are resubmitted to  table
+                     40  for  local  delivery  by checking a MLF_RCV_FROM_RAMP
+                     flag, which is set when the packet arrives  from  a  ramp
+                     tunnel.
+
+              conntrack zone field for logical ports
+                     A  field  that  denotes  the connection tracking zone for
+                     logical ports. The value only has local significance  and
+                     is not meaningful between chassis. This is initialized to
+                     0  at  the beginning of the logical ingress pipeline. OVN
+                     stores this in Open vSwitch extension register number 13.
+
+              conntrack zone fields for routers
+                     Fields that denote  the  connection  tracking  zones  for
+                     routers.  These  values  only have local significance and
+                     are not meaningful between chassis. OVN stores  the  zone
+                     information  for  north to south traffic (for DNATting or
+                     ECMP symmetric replies) in Open vSwitch extension  regisā€
+                     ter  number  11  and  zone information for south to north
+                     traffic (for SNATing) in Open vSwitch extension  register
+                     number 12.
+
+              logical flow flags
+                     The  logical flags are intended to handle keeping context
+                     between tables in order to decide which rules  in  subseā€
+                     quent  tables  are  matched. These values only have local
+                     significance and are not meaningful between chassis.  OVN
+                     stores the logical flags in Open vSwitch extension regisā€
+                     ter number 10.
+
+              VLAN ID
+                     The  VLAN ID is used as an interface between OVN and conā€
+                     tainers nested inside a VM (see Life Cycle of a container
+                     interface inside a VM, above, for more information).
+
+       Initially, a VM or container on the ingress hypervisor sends  a  packet
+       on a port attached to the OVN integration bridge. Then:
+
+              1.  OpenFlow  table  0 performs physical-to-logical translation.
+                  It matches the packetā€™s ingress port. Its  actions  annotate
+                  the  packet  with  logical  metadata, by setting the logical
+                  datapath field to identify the  logical  datapath  that  the
+                  packet  is  traversing  and  the logical input port field to
+                  identify the ingress port. Then it resubmits to table  8  to
+                  enter the logical ingress pipeline.
+
+                  Packets  that  originate from a container nested within a VM
+                  are treated in a slightly  different  way.  The  originating
+                  container  can  be  distinguished  based on the VIF-specific
+                  VLAN ID, so the physical-to-logical translation flows  addiā€
+                  tionally  match  on  VLAN  ID and the actions strip the VLAN
+                  header. Following this step, OVN treats  packets  from  conā€
+                  tainers just like any other packets.
+
+                  Table  0 also processes packets that arrive from other chasā€
+                  sis. It distinguishes them from  other  packets  by  ingress
+                  port,  which  is a tunnel. As with packets just entering the
+                  OVN pipeline, the actions annotate these packets with  logiā€
+                  cal  datapath  metadata.  For  tunnel types that support it,
+                  they are also annotated with logical ingress port  metadata.
+                  In  addition, the actions set the logical output port field,
+                  which is available because in OVN tunneling occurs after the
+                  logical output port is known. These  pieces  of  information
+                  are  obtained  from  the  tunnel encapsulation metadata (see
+                  Tunnel Encapsulations for encoding details).  Then  the  acā€
+                  tions  resubmit  to  table  38  to  enter the logical egress
+                  pipeline.
+
+              2.  OpenFlow tables 8 through 31  execute  the  logical  ingress
+                  pipeline  from  the Logical_Flow table in the OVN Southbound
+                  database. These tables are expressed entirely  in  terms  of
+                  logical concepts like logical ports and logical datapaths. A
+                  big  part  of ovn-controllerā€™s job is to translate them into
+                  equivalent OpenFlow (in particular it translates  the  table
+                  numbers:  Logical_Flow  tables  0 through 23 become OpenFlow
+                  tables 8 through 31).
+
+                  Each logical flow maps to one or more OpenFlow flows. An acā€
+                  tual packet ordinarily matches only one of  these,  although
+                  in  some  cases  it  can  match more than one of these flows
+                  (which is not a problem because all of them  have  the  same
+                  actions). ovn-controller uses the first 32 bits of the logiā€
+                  cal  flowā€™s  UUID  as  the  cookie  for its OpenFlow flow or
+                  flows. (This is not necessarily unique, since the  first  32
+                  bits of a logical flowā€™s UUID is not necessarily unique.)
+
+                  Some logical flows can map to the Open vSwitch ``conjunctive
+                  matchā€™ā€™ extension (see ovs-fields(7)). Flows with a conjuncā€ā€
+                  tion  action  use  an OpenFlow cookie of 0, because they can
+                  correspond to multiple logical flows. The OpenFlow flow  for
+                  a conjunctive match includes a match on conj_id.
+
+                  Some  logical  flows  may not be represented in the OpenFlow
+                  tables on a given hypervisor, if they could not be  used  on
+                  that  hypervisor. For example, if no VIF in a logical switch
+                  resides on a given hypervisor, and the logical switch is not
+                  otherwise reachable on that hypervisor (e.g. over  a  series
+                  of hops through logical switches and routers starting from a
+                  VIF  on  the  hypervisor),  then the logical flow may not be
+                  represented there.
+
+                  Most OVN actions  have  fairly  obvious  implementations  in
+                  OpenFlow (with OVS extensions), e.g. next; is implemented as
+                  resubmit,  field  =  constant; as set_field. A few are worth
+                  describing in more detail:
+
+                  output:
+                         Implemented by resubmitting the packet to  table  37.
+                         If the pipeline executes more than one output action,
+                         then  each one is separately resubmitted to table 37.
+                         This can be used  to  send  multiple  copies  of  the
+                         packet to multiple ports. (If the packet was not modā€
+                         ified  between  the  output  actions, and some of the
+                         copies are destined to the same hypervisor, then  usā€
+                         ing  a logical multicast output port would save bandā€
+                         width between hypervisors.)
+
+                  get_arp(P, A);
+                  get_nd(P, A);
+                       Implemented by storing arguments into OpenFlow  fields,
+                       then  resubmitting  to  table  66, which ovn-controller
+                       populates with flows generated from the MAC_Binding taā€
+                       ble in the OVN Southbound database. If there is a match
+                       in table 66, then its actions store the  bound  MAC  in
+                       the Ethernet destination address field.
+
+                       (The  OpenFlow  actions  save  and restore the OpenFlow
+                       fields used for the arguments, so that the OVN  actions
+                       do not have to be aware of this temporary use.)
+
+                  put_arp(P, A, E);
+                  put_nd(P, A, E);
+                       Implemented  by  storing  the  arguments  into OpenFlow
+                       fields, then outputting  a  packet  to  ovn-controller,
+                       which updates the MAC_Binding table.
+
+                       (The  OpenFlow  actions  save  and restore the OpenFlow
+                       fields used for the arguments, so that the OVN  actions
+                       do not have to be aware of this temporary use.)
+
+                  R = lookup_arp(P, A, M);
+                  R = lookup_nd(P, A, M);
+                       Implemented  by storing arguments into OpenFlow fields,
+                       then resubmitting to  table  67,  which  ovn-controller
+                       populates with flows generated from the MAC_Binding taā€
+                       ble in the OVN Southbound database. If there is a match
+                       in table 67, then its actions set the logical flow flag
+                       MLF_LOOKUP_MAC.
+
+                       (The  OpenFlow  actions  save  and restore the OpenFlow
+                       fields used for the arguments, so that the OVN  actions
+                       do not have to be aware of this temporary use.)
+
+              3.  OpenFlow tables 37 through 41 implement the output action in
+                  the  logical ingress pipeline. Specifically, table 37 serves
+                  as an entry point to egress pipeline. Table  37  detects  IP
+                  packets  that are too big for a corresponding interface. Taā€
+                  ble 38 produces ICMPv4 Fragmentation Needed (or  ICMPv6  Too
+                  Big) errors and deliver them back to the offending port. taā€
+                  ble  39 handles packets to remote hypervisors, table 40 hanā€
+                  dles packets to the local hypervisor, and  table  41  checks
+                  whether  packets  whose  logical ingress and egress port are
+                  the same should be discarded.
+
+                  Logical patch ports are a special case. Logical patch  ports
+                  do  not  have  a physical location and effectively reside on
+                  every hypervisor. Thus, flow table 40, for output  to  ports
+                  on the local hypervisor, naturally implements output to uniā€
+                  cast  logical  patch  ports  too. However, applying the same
+                  logic to a logical patch port that is part of a logical mulā€
+                  ticast group yields packet duplication, because each  hyperā€
+                  visor  that  contains  a logical port in the multicast group
+                  will also output the packet to the logical patch port. Thus,
+                  multicast groups implement output to logical patch ports  in
+                  table 39.
+
+                  Each  flow  in table 39 matches on a logical output port for
+                  unicast or multicast logical ports that  include  a  logical
+                  port  on  a remote hypervisor. Each flowā€™s actions implement
+                  sending a packet to the port it matches. For unicast logical
+                  output ports on remote hypervisors, the actions set the tunā€
+                  nel key to the correct value, then send the  packet  on  the
+                  tunnel  port to the correct hypervisor. (When the remote hyā€
+                  pervisor receives the packet, table 0 there  will  recognize
+                  it  as a tunneled packet and pass it along to table 40.) For
+                  multicast logical output ports, the actions send one copy of
+                  the packet to each remote hypervisor, in the same way as for
+                  unicast destinations. If a multicast group includes a  logiā€
+                  cal  port or ports on the local hypervisor, then its actions
+                  also resubmit to table 40. Table 39 also includes:
+
+                  ā€¢      A higher-priority rule to match packets received from
+                         ramp switch tunnels, based on flag MLF_RCV_FROM_RAMP,
+                         and resubmit these packets to table 40 for local  deā€
+                         livery.  Packets  received  from  ramp switch tunnels
+                         reach here because of a lack of logical  output  port
+                         field in the tunnel key and thus these packets needed
+                         to  be  submitted  to table 8 to determine the output
+                         port.
+
+                  ā€¢      A higher-priority rule to match packets received from
+                         ports of type localport, based on the  logical  input
+                         port,  and resubmit these packets to table 40 for loā€
+                         cal delivery. Ports of type localport exist on  every
+                         hypervisor  and  by  definition  their traffic should
+                         never go out through a tunnel.
+
+                  ā€¢      A higher-priority rule to match packets that have the
+                         MLF_LOCAL_ONLY logical flow flag set, and whose  desā€
+                         tination  is a multicast address. This flag indicates
+                         that the packet should not be delivered to remote hyā€
+                         pervisors, even if the multicast destination includes
+                         ports on remote hypervisors. This flag is  used  when
+                         ovn-controller  is  the  originator  of the multicast
+                         packet. Since each ovn-controller instance is  origiā€
+                         nating these packets, the packets only need to be deā€
+                         livered to local ports.
+
+                  ā€¢      A  fallback  flow that resubmits to table 40 if there
+                         is no other match.
+
+                  Flows in table 40 resemble those in table 39 but for logical
+                  ports that reside locally rather than remotely. For  unicast
+                  logical  output  ports  on the local hypervisor, the actions
+                  just resubmit to table 41. For multicast output  ports  that
+                  include  one  or more logical ports on the local hypervisor,
+                  for each such logical port P, the actions change the logical
+                  output port to P, then resubmit to table 41.
+
+                  A special case is that when a localnet port  exists  on  the
+                  datapath,  remote  port is connected by switching to the loā€
+                  calnet port. In this case, instead of adding a flow in table
+                  39 to reach the remote port, a flow is added in table 40  to
+                  switch  the logical outport to the localnet port, and resubā€
+                  mit to table 40 as if it were unicasted to a logical port on
+                  the local hypervisor.
+
+                  Table 41 matches and drops packets for which the logical inā€
+                  put and output ports are the same and the MLF_ALLOW_LOOPBACK
+                  flag is not set. It also drops  MLF_LOCAL_ONLY  packets  diā€
+                  rected to a localnet port. It resubmits other packets to taā€
+                  ble 42.
+
+              4.  OpenFlow  tables  42  through  62 execute the logical egress
+                  pipeline from the Logical_Flow table in the  OVN  Southbound
+                  database.  The  egress pipeline can perform a final stage of
+                  validation before packet delivery. Eventually, it  may  exeā€
+                  cute  an  output  action, which ovn-controller implements by
+                  resubmitting to table 64. A packet for  which  the  pipeline
+                  never  executes  output  is effectively dropped (although it
+                  may have been transmitted through a tunnel across a physical
+                  network).
+
+                  The egress pipeline cannot change the logical output port or
+                  cause further tunneling.
+
+              5.  Table 64 bypasses OpenFlow loopback when  MLF_ALLOW_LOOPBACK
+                  is  set. Logical loopback was handled in table 41, but Openā€
+                  Flow by default  also  prevents  loopback  to  the  OpenFlow
+                  ingress port. Thus, when MLF_ALLOW_LOOPBACK is set, OpenFlow
+                  table  64  saves the OpenFlow ingress port, sets it to zero,
+                  resubmits to table 65  for  logical-to-physical  transformaā€
+                  tion,  and  then  restores the OpenFlow ingress port, effecā€
+                  tively disabling OpenFlow loopback  prevents.  When  MLF_ALā€
+                  LOW_LOOPBACK is unset, table 64 flow simply resubmits to taā€
+                  ble 65.
+
+              6.  OpenFlow  table 65 performs logical-to-physical translation,
+                  the opposite of table 0. It  matches  the  packetā€™s  logical
+                  egress  port.  Its actions output the packet to the port atā€
+                  tached to the OVN integration bridge  that  represents  that
+                  logical  port.  If  the  logical  egress port is a container
+                  nested with a VM, then before sending the packet the actions
+                  push on a VLAN header with an appropriate VLAN ID.
+
+   Logical Routers and Logical Patch Ports
+       Typically logical routers and logical patch ports do not have a  physiā€
+       cal  location  and  effectively reside on every hypervisor. This is the
+       case for logical  patch  ports  between  logical  routers  and  logical
+       switches behind those logical routers, to which VMs (and VIFs) attach.
+
+       Consider a packet sent from one virtual machine or container to another
+       VM  or  container  that  resides on a different subnet. The packet will
+       traverse tables 0 to 65 as described in the previous section  Architecā€ā€
+       tural  Physical Life Cycle of a Packet, using the logical datapath repā€
+       resenting the logical switch that the sender is attached to.  At  table
+       39, the packet will use the fallback flow that resubmits locally to taā€
+       ble 40 on the same hypervisor. In this case, all of the processing from
+       table 0 to table 65 occurs on the hypervisor where the sender resides.
+
+       When  the packet reaches table 65, the logical egress port is a logical
+       patch port. ovn-controller implements output to the  logical  patch  is
+       packet  by cloning and resubmitting directly to the first OpenFlow flow
+       table in the ingress pipeline, setting the logical ingress port to  the
+       peer  logical patch port, and using the peer logical patch portā€™s logiā€
+       cal datapath (that represents the logical router).
+
+       The packet re-enters the ingress pipeline in order to traverse tables 8
+       to 65 again, this time using the logical datapath representing the logā€
+       ical router. The processing continues as described in the previous secā€
+       tion Architectural Physical Life Cycle of a  Packet.  When  the  packet
+       reaches  table 65, the logical egress port will once again be a logical
+       patch port. In the same manner as described above, this  logical  patch
+       port  will  cause  the packet to be resubmitted to OpenFlow tables 8 to
+       65, this time using  the  logical  datapath  representing  the  logical
+       switch that the destination VM or container is attached to.
+
+       The packet traverses tables 8 to 65 a third and final time. If the desā€
+       tination  VM or container resides on a remote hypervisor, then table 39
+       will send the packet on a tunnel port from the senderā€™s  hypervisor  to
+       the remote hypervisor. Finally table 65 will output the packet directly
+       to the destination VM or container.
+
+       The  following  sections describe two exceptions, where logical routers
+       and/or logical patch ports are associated with a physical location.
+
+     Gateway Routers
+
+       A gateway router is a logical router that is bound to a physical  locaā€
+       tion.  This  includes  all  of  the  logical patch ports of the logical
+       router, as well as all of the  peer  logical  patch  ports  on  logical
+       switches.  In the OVN Southbound database, the Port_Binding entries for
+       these logical patch ports use the type l3gateway rather than patch,  in
+       order  to  distinguish  that  these  logical patch ports are bound to a
+       chassis.
+
+       When a hypervisor processes a packet on a logical datapath representing
+       a logical switch, and the logical egress port is a l3gateway port  repā€
+       resenting  connectivity  to  a  gateway router, the packet will match a
+       flow in table 39 that sends the packet on a tunnel port to the  chassis
+       where  the  gateway router resides. This processing in table 39 is done
+       in the same manner as for VIFs.
+
+     Distributed Gateway Ports
+
+       This section provides additional details on distributed gateway  ports,
+       outlined earlier.
+
+       The  primary  design  goal  of distributed gateway ports is to allow as
+       much traffic as possible to be handled locally on the hypervisor  where
+       a  VM  or  container resides. Whenever possible, packets from the VM or
+       container to the outside world should be processed completely  on  that
+       VMā€™s  or  containerā€™s hypervisor, eventually traversing a localnet port
+       instance or a tunnel to the physical network or a different OVN deployā€
+       ment. Whenever possible, packets from the outside world to a VM or conā€
+       tainer should be directed through the physical network directly to  the
+       VMā€™s or containerā€™s hypervisor.
+
+       In  order  to allow for the distributed processing of packets described
+       in the paragraph above, distributed gateway ports need  to  be  logical
+       patch  ports  that  effectively reside on every hypervisor, rather than
+       l3gateway ports that are bound to a particular  chassis.  However,  the
+       flows  associated with distributed gateway ports often need to be assoā€
+       ciated with physical locations, for the following reasons:
+
+              ā€¢      The physical network that the localnet port  is  attached
+                     to  typically uses L2 learning. Any Ethernet address used
+                     over the distributed gateway port must be restricted to a
+                     single physical location so that upstream L2 learning  is
+                     not  confused.  Traffic  sent out the distributed gateway
+                     port towards the localnet port with a  specific  Ethernet
+                     address  must  be  sent  out one specific instance of the
+                     distributed gateway port on one specific chassis. Traffic
+                     received from the localnet port (or from  a  VIF  on  the
+                     same logical switch as the localnet port) with a specific
+                     Ethernet address must be directed to the logical switchā€™s
+                     patch port instance on that specific chassis.
+
+                     Due  to the implications of L2 learning, the Ethernet adā€
+                     dress and IP address of the distributed gateway port need
+                     to be restricted to a single physical location. For  this
+                     reason, the user must specify one chassis associated with
+                     the  distributed gateway port. Note that traffic traversā€
+                     ing the distributed gateway port using other Ethernet adā€
+                     dresses and IP addresses (e.g. one-to-one NAT) is not reā€
+                     stricted to this chassis.
+
+                     Replies to ARP and ND requests must be  restricted  to  a
+                     single  physical  location, where the Ethernet address in
+                     the reply resides. This includes ARP and ND  replies  for
+                     the IP address of the distributed gateway port, which are
+                     restricted  to  the chassis that the user associated with
+                     the distributed gateway port.
+
+              ā€¢      In order to support one-to-many SNAT (aka  IP  masqueradā€
+                     ing),  where  multiple logical IP addresses spread across
+                     multiple chassis are mapped to a single external  IP  adā€
+                     dress, it will be necessary to handle some of the logical
+                     router  processing on a specific chassis in a centralized
+                     manner. Since the SNAT external IP address  is  typically
+                     the distributed gateway port IP address, and for simplicā€
+                     ity,  the  same  chassis  associated with the distributed
+                     gateway port is used.
+
+       The details of flow restrictions to specific chassis are  described  in
+       the ovn-northd documentation.
+
+       While  most  of  the physical location dependent aspects of distributed
+       gateway ports can be handled by  restricting  some  flows  to  specific
+       chassis, one additional mechanism is required. When a packet leaves the
+       ingress pipeline and the logical egress port is the distributed gateway
+       port, one of two different sets of actions is required at table 39:
+
+              ā€¢      If  the packet can be handled locally on the senderā€™s hyā€
+                     pervisor (e.g. one-to-one NAT traffic), then  the  packet
+                     should  just  be  resubmitted locally to table 40, in the
+                     normal manner for distributed logical patch ports.
+
+              ā€¢      However, if the packet needs to be handled on the chassis
+                     associated with the distributed gateway port  (e.g.  one-
+                     to-many  SNAT  traffic or non-NAT traffic), then table 39
+                     must send the packet on a tunnel port to that chassis.
+
+       In order to trigger the second set of actions, the chassisredirect type
+       of southbound Port_Binding has been added. Setting the  logical  egress
+       port  to the type chassisredirect logical port is simply a way to indiā€
+       cate that although the packet is destined for the  distributed  gateway
+       port,  it  needs  to be redirected to a different chassis. At table 39,
+       packets with this logical egress port are sent to a  specific  chassis,
+       in the same way that table 39 directs packets whose logical egress port
+       is a VIF or a type l3gateway port to different chassis. Once the packet
+       arrives at that chassis, table 40 resets the logical egress port to the
+       value  representing  the distributed gateway port. For each distributed
+       gateway port, there is one type chassisredirect port,  in  addition  to
+       the distributed logical patch port representing the distributed gateway
+       port.
+
+     High Availability for Distributed Gateway Ports
+
+       OVN  allows you to specify a prioritized list of chassis for a distribā€
+       uted gateway port. This is done by associating multiple Gateway_Chassis
+       rows with a Logical_Router_Port in the OVN_Northbound database.
+
+       When multiple chassis have been specified for a  gateway,  all  chassis
+       that may send packets to that gateway will enable BFD on tunnels to all
+       configured  gateway chassis. The current master chassis for the gateway
+       is the highest priority gateway chassis that is currently viewed as acā€
+       tive based on BFD status.
+
+       For more information on L3 gateway high availability, please  refer  to
+       http://docs.ovn.org/en/latest/topics/high-availability.html.
+
+     Restrictions of Distributed Gateway Ports
+
+       Distributed  gateway  ports are used to connect to an external network,
+       which can be a physical network modeled by a logical switch with a  loā€
+       calnet  port,  and can also be a logical switch that interconnects difā€
+       ferent OVN deployments (see OVN Deployments  Interconnection).  Usually
+       there  can be many logical routers connected to the same external logiā€
+       cal switch, as shown in below diagram.
+
+                                     +--LS-EXT-+
+                                     |    |    |
+                                     |    |    |
+                                    LR1  ...  LRn
+
+
+       In this diagram, there are n logical routers  connected  to  a  logical
+       switch  LS-EXT,  each  with a distributed gateway port, so that traffic
+       sent to external world is redirected to the gateway chassis that is asā€
+       signed to the distributed gateway port of respective logical router.
+
+       In the logical topology, nothing can prevent an user to add a route beā€
+       tween the logical routers via the connected distributed  gateway  ports
+       on  LS-EXT.  However,  the route works only if the LS-EXT is a physical
+       network (modeled by a logical switch with a  localnet  port).  In  that
+       case the packet will be delivered between the gateway chassises through
+       the localnet port via physical network. If the LS-EXT is a regular logā€
+       ical switch (backed by tunneling only, as in the use case of OVN interā€
+       connection),  then  the  packet  will  be dropped on the source gateway
+       chassis. The limitation is due the fact that distributed gateway  ports
+       are tied to physical location, and without physical network connection,
+       we  will end up with either dropping the packet or transferring it over
+       the tunnels which could cause bigger problems such as broadcast packets
+       being redirect repeatedly by different gateway chassises.
+
+       With the limitation in mind, if a user do want the direct  connectivity
+       between the logical routers, it is better to create an internal logical
+       switch  connected  to  the  logical routers with regular logical router
+       ports, which are completely distributed and the packets donā€™t  have  to
+       leave  a  chassis  unless necessary, which is more optimal than routing
+       via the distributed gateway ports.
+
+     ARP request and ND NS packet processing
+
+       Due to the fact that ARP requests and ND NA packets are usually  broadā€
+       cast  packets,  for  performance  reasons, OVN deals with requests that
+       target OVN owned IP addresses (i.e., IP  addresses  configured  on  the
+       router  ports,  VIPs, NAT IPs) in a specific way and only forwards them
+       to the logical router that owns the target IP address. This behavior is
+       different than that of traditional  switches  and  implies  that  other
+       routers/hosts connected to the logical switch will not learn the MAC/IP
+       binding from the request packet.
+
+       All other ARP and ND packets are flooded in the L2 broadcast domain and
+       to all attached logical patch ports.
+
+     VIFs on the logical switch connected by a distributed gateway port
+
+       Typically the logical switch connected by a distributed gateway port is
+       for  external connectivity, usually to a physical network through a loā€
+       calnet port on the logical  switch,  or  to  a  remote  OVN  deployment
+       through  OVN  Interconnection. In these cases there is no VIF ports reā€
+       quired on the logical switch.
+
+       While not very common, it is still possible to create VIF ports on  the
+       logical  switch connected by a distributed gateway port, but there is a
+       limitation that the logical ports need to reside on the gateway chassis
+       where the distributed gateway port resides to get connectivity to other
+       logical switches through the distributed gateway port. There is no limā€
+       itation for the VIFs to connect within the logical  switch,  or  beyond
+       the  logical  switch  through  other regular distributed logical router
+       ports.
+
+       A special case is when using distributed gateway ports for  scalability
+       purpose,  as  mentioned  earlier in this document. The logical switches
+       connected by distributed gateway ports are  not  for  connectivity  but
+       just  for  regular VIFs. However, the above limitation usually does not
+       matter because in this use case all the VIFs on the logical switch  are
+       located on the same chassis with the distributed gateway port that conā€
+       nects the logical switch.
+
+   Multiple localnet logical switches connected to a Logical Router
+       It  is  possible to have multiple logical switches each with a localnet
+       port (representing physical networks) connected to a logical router, in
+       which one localnet logical switch may provide the external connectivity
+       via a distributed  gateway  port  and  rest  of  the  localnet  logical
+       switches  use VLAN tagging in the physical network. It is expected that
+       ovn-bridge-mappings is configured appropriately on the chassis for  all
+       these localnet networks.
+
+     East West routing
+
+       East-West  routing  between these localnet VLAN tagged logical switches
+       work almost the same way as normal logical switches. When the VM  sends
+       such a packet, then:
+
+              1.  It  first  enters  the  ingress  pipeline,  and  then egress
+                  pipeline of the source localnet logical switch datapath.  It
+                  then enters the ingress pipeline of the logical router dataā€
+                  path via the logical router port in the source chassis.
+
+              2.  Routing decision is taken.
+
+              3.  From the router datapath, packet enters the ingress pipeline
+                  and then egress pipeline of the destination localnet logical
+                  switch  datapath  and  goes out of the integration bridge to
+                  the provider bridge ( belonging to the  destination  logical
+                  switch)  via  the localnet port. While sending the packet to
+                  provider bridge, we also replace router port MAC  as  source
+                  MAC with a chassis unique MAC.
+
+                  This  chassis  unique MAC is configured as global ovs config
+                  on each chassis (eg. via "ovs-vsctl set open . external-ids:
+                  ovn-chassis-mac-mappings="phys:aa:bb:cc:dd:ee:$i$i"").   For
+                  more details, see ovn-controller(8).
+
+                  If the above is not configured, then source MAC would be the
+                  router  port  MAC. This could create problem if we have more
+                  than one chassis. This is because, since the router port  is
+                  distributed, the same (MAC,VLAN) tuple will seen by physical
+                  network  from other chassis as well, which could cause these
+                  issues:
+
+                  ā€¢      Continuous MAC moves in top-of-rack switch (ToR).
+
+                  ā€¢      ToR dropping the traffic, which is causing continuous
+                         MAC moves.
+
+                  ā€¢      ToR blocking the ports from which MAC moves are  hapā€
+                         pening.
+
+              4.  The destination chassis receives the packet via the localnet
+                  port and sends it to the integration bridge. Before entering
+                  the  integration bridge the source mac of the packet will be
+                  replaced with router port mac again. The packet  enters  the
+                  ingress pipeline and then egress pipeline of the destination
+                  localnet  logical  switch  and finally gets delivered to the
+                  destination VM port.
+
+     External traffic
+
+       The following happens when a VM sends an external  traffic  (which  reā€
+       quires  NATting) and the chassis hosting the VM doesnā€™t have a distribā€
+       uted gateway port.
+
+              1.  The packet first  enters  the  ingress  pipeline,  and  then
+                  egress  pipeline of the source localnet logical switch dataā€
+                  path. It then enters the ingress  pipeline  of  the  logical
+                  router  datapath  via  the logical router port in the source
+                  chassis.
+
+              2.  Routing decision is taken. Since the gateway router  or  the
+                  distributed  gateway port doesnā€™t reside in the source chasā€
+                  sis, the traffic is redirected to the  gateway  chassis  via
+                  the tunnel port.
+
+              3.  The  gateway chassis receives the packet via the tunnel port
+                  and the packet enters the egress  pipeline  of  the  logical
+                  router datapath. NAT rules are applied here. The packet then
+                  enters  the ingress pipeline and then egress pipeline of the
+                  localnet logical switch  datapath  which  provides  external
+                  connectivity  and  finally goes out via the localnet port of
+                  the logical switch which provides external connectivity.
+
+       Although this works, the VM traffic is tunnelled  when  sent  from  the
+       compute  chassis  to the gateway chassis. In order for it to work propā€
+       erly, the MTU of the localnet logical switches must be lowered  to  acā€
+       count for the tunnel encapsulation.
+
+   Centralized  routing for localnet VLAN tagged logical switches connected to
+       a Logical Router
+       To overcome the tunnel encapsulation problem described in the  previous
+       section,  OVN  supports  the option of enabling centralized routing for
+       localnet VLAN tagged logical switches. CMS can configure the option opā€ā€
+       tions:reside-on-redirect-chassis to true for  each  Logical_Router_Port
+       which  connects  to  the  localnet  VLAN  tagged logical switches. This
+       causes the gateway chassis (hosting the distributed  gateway  port)  to
+       handle  all  the  routing for these networks, making it centralized. It
+       will reply to the ARP requests for the logical router port IPs.
+
+       If the logical router doesnā€™t have a distributed gateway port  connectā€
+       ing  to  the localnet logical switch which provides external connectivā€
+       ity, or if it has more than one distributed gateway  ports,  then  this
+       option is ignored by OVN.
+
+       The  following happens when a VM sends an east-west traffic which needs
+       to be routed:
+
+              1.  The packet first  enters  the  ingress  pipeline,  and  then
+                  egress  pipeline of the source localnet logical switch dataā€
+                  path and is sent out via a localnet port of the  source  loā€
+                  calnet  logical  switch  (instead  of  sending  it to router
+                  pipeline).
+
+              2.  The gateway chassis receives the packet via a localnet  port
+                  of  the  source  localnet logical switch and sends it to the
+                  integration bridge.  The  packet  then  enters  the  ingress
+                  pipeline,  and  then  egress pipeline of the source localnet
+                  logical switch datapath and enters the ingress  pipeline  of
+                  the logical router datapath.
+
+              3.  Routing decision is taken.
+
+              4.  From the router datapath, packet enters the ingress pipeline
+                  and then egress pipeline of the destination localnet logical
+                  switch  datapath. It then goes out of the integration bridge
+                  to the provider bridge ( belonging to the destination  logiā€
+                  cal switch) via a localnet port.
+
+              5.  The  destination  chassis receives the packet via a localnet
+                  port and sends it to the integration bridge. The packet  enā€
+                  ters  the  ingress  pipeline and then egress pipeline of the
+                  destination localnet logical switch and finally delivered to
+                  the destination VM port.
+
+       The following happens when a VM sends an  external  traffic  which  reā€
+       quires NATting:
+
+              1.  The  packet  first  enters  the  ingress  pipeline, and then
+                  egress pipeline of the source localnet logical switch  dataā€
+                  path  and  is sent out via a localnet port of the source loā€
+                  calnet logical switch  (instead  of  sending  it  to  router
+                  pipeline).
+
+              2.  The  gateway chassis receives the packet via a localnet port
+                  of the source localnet logical switch and sends  it  to  the
+                  integration  bridge.  The  packet  then  enters  the ingress
+                  pipeline, and then egress pipeline of  the  source  localnet
+                  logical  switch  datapath and enters the ingress pipeline of
+                  the logical router datapath.
+
+              3.  Routing decision is taken and NAT rules are applied.
+
+              4.  From the router datapath, packet enters the ingress pipeline
+                  and then egress pipeline  of  the  localnet  logical  switch
+                  datapath  which provides external connectivity. It then goes
+                  out of the integration bridge to the  provider  bridge  (beā€
+                  longing  to  the logical switch which provides external conā€
+                  nectivity) via a localnet port.
+
+       The following happens for the reverse external traffic.
+
+              1.  The gateway chassis receives the packet from a localnet port
+                  of the logical switch which provides external  connectivity.
+                  The  packet then enters the ingress pipeline and then egress
+                  pipeline of the localnet logical switch (which provides  exā€
+                  ternal  connectivity).  The  packet  then enters the ingress
+                  pipeline of the logical router datapath.
+
+              2.  The ingress pipeline of the logical router datapath  applies
+                  the  unNATting  rules.  The  packet  then enters the ingress
+                  pipeline and then egress pipeline  of  the  source  localnet
+                  logical  switch.  Since  the source VM doesnā€™t reside in the
+                  gateway chassis, the packet is sent out via a localnet  port
+                  of the source logical switch.
+
+              3.  The  source  chassis receives the packet via a localnet port
+                  and sends it to the integration bridge.  The  packet  enters
+                  the  ingress pipeline and then egress pipeline of the source
+                  localnet logical switch and finally gets  delivered  to  the
+                  source VM port.
+
+       As  an  alternative  to  reside-on-redirect-chassis, OVN supports VLAN-
+       based redirection. Whereas reside-on-redirect-chassis  centralizes  all
+       router functionality, VLAN-based redirection only changes how OVN rediā€
+       rects  packets to the gateway chassis. By setting options:redirect-type
+       to bridged on a distributed gateway port, OVN redirects packets to  the
+       gateway  chassis  using  the localnet port of the routerā€™s peer logical
+       switch, instead of a tunnel.
+
+       If the logical router doesnā€™t have a distributed gateway port  connectā€
+       ing  to  the localnet logical switch which provides external connectivā€
+       ity, or if it has more than one distributed gateway  ports,  then  this
+       option is ignored by OVN.
+
+       Following happens for bridged redirection:
+
+              1.  On  compute  chassis,  packet passes though logical routerā€™s
+                  ingress pipeline.
+
+              2.  If logical outport is gateway chassis attached  router  port
+                  then  packet  is  "redirected" to gateway chassis using peer
+                  logical switchā€™s localnet port.
+
+              3.  This redirected packet has destination mac  as  router  port
+                  mac (the one to which gateway chassis is attached). Its VLAN
+                  id is that of localnet port (peer logical switch of the logā€
+                  ical router port).
+
+              4.  On  the gateway chassis packet will enter the logical router
+                  pipeline again and this  time  it  will  passthrough  egress
+                  pipeline as well.
+
+              5.  Reverse traffic packet flows stays the same.
+
+       Some guidelines and expections with bridged redirection:
+
+              1.  Since router port mac is destination mac, hence it has to be
+                  ensured  that  physical  network  learns it on ONLY from the
+                  gateway chassis. Which means  that  ovn-chassis-mac-mappings
+                  should be configure on all the compute nodes, so that physiā€
+                  cal network never learn router port mac from compute nodes.
+
+              2.  Since  packet  enters  logical router ingress pipeline twice
+                  (once on compute chassis  and  again  on  gateway  chassis),
+                  hence ttl will be decremented twice.
+
+              3.  Default  redirection  type continues to be overlay. User can
+                  switch the redirect-type  between  bridged  and  overlay  by
+                  changing the value of options:redirect-type
+
+   Life Cycle of a VTEP gateway
+       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.
+
+       The steps below refer often to details of the  OVN  and  VTEP  database
+       schemas. Please see ovn-sb(5), ovn-nb(5) and vtep(5), respectively, for
+       the full story on these databases.
+
+              1.  A  VTEP  gatewayā€™s  life cycle begins with the administrator
+                  registering the VTEP gateway as a Physical_Switch table  enā€
+                  try  in the VTEP database. The ovn-controller-vtep connected
+                  to this VTEP database, will recognize the new  VTEP  gateway
+                  and  create  a  new  Chassis  table  entry  for  it  in  the
+                  OVN_Southbound database.
+
+              2.  The administrator can then create a new Logical_Switch table
+                  entry, and bind a particular vlan on a VTEP  gatewayā€™s  port
+                  to  any  VTEP  logical switch. Once a VTEP logical switch is
+                  bound to a VTEP gateway, the ovn-controller-vtep will detect
+                  it and add its name to the vtep_logical_switches  column  of
+                  the  Chassis table in the OVN_Southbound database. Note, the
+                  tunnel_key column of VTEP logical switch is  not  filled  at
+                  creation.  The  ovn-controller-vtep will set the column when
+                  the corresponding vtep logical switch is  bound  to  an  OVN
+                  logical network.
+
+              3.  Now, the administrator can use the CMS to add a VTEP logical
+                  switch  to the OVN logical network. To do that, the CMS must
+                  first create a new Logical_Switch_Port table  entry  in  the
+                  OVN_Northbound database. Then, the type column of this entry
+                  must  be  set  to  "vtep". Next, the vtep-logical-switch and
+                  vtep-physical-switch keys in the options column must also be
+                  specified, since multiple VTEP gateways can  attach  to  the
+                  same VTEP logical switch. Next, the addresses column of this
+                  logical  port must be set to "unknown", it will add a priorā€
+                  ity 0 entry  in  "ls_in_l2_lkup"  stage  of  logical  switch
+                  ingress  pipeline.  So,  traffic  with unrecorded mac by OVN
+                  would go through the Logical_Switch_Port  to  physical  netā€
+                  work.
+
+              4.  The  newly  created logical port in the OVN_Northbound dataā€
+                  base and its  configuration  will  be  passed  down  to  the
+                  OVN_Southbound  database  as a new Port_Binding table entry.
+                  The ovn-controller-vtep will recognize the change  and  bind
+                  the  logical port to the corresponding VTEP gateway chassis.
+                  Configuration of binding the same VTEP logical switch  to  a
+                  different  OVN logical networks is not allowed and a warning
+                  will be generated in the log.
+
+              5.  Beside binding to the VTEP  gateway  chassis,  the  ovn-conā€ā€
+                  troller-vtep  will  update the tunnel_key column of the VTEP
+                  logical switch to the corresponding  Datapath_Binding  table
+                  entryā€™s tunnel_key for the bound OVN logical network.
+
+              6.  Next, the ovn-controller-vtep will keep reacting to the conā€
+                  figuration  change in the Port_Binding in the OVN_Northbound
+                  database, and updating the Ucast_Macs_Remote  table  in  the
+                  VTEP  database.  This  allows the VTEP gateway to understand
+                  where to forward the unicast traffic  coming  from  the  exā€
+                  tended external network.
+
+              7.  Eventually,  the VTEP gatewayā€™s life cycle ends when the adā€
+                  ministrator unregisters the VTEP gateway from the VTEP dataā€
+                  base. The ovn-controller-vtep will recognize the  event  and
+                  remove  all  related configurations (Chassis table entry and
+                  port bindings) in the OVN_Southbound database.
+
+              8.  When the ovn-controller-vtep is terminated, all related conā€
+                  figurations in the  OVN_Southbound  database  and  the  VTEP
+                  database  will  be  cleaned, including Chassis table entries
+                  for all registered VTEP gateways and  their  port  bindings,
+                  and  all  Ucast_Macs_Remote  table  entries  and  the  Logiā€ā€
+                  cal_Switch tunnel keys.
+
+   OVN Deployments Interconnection
+       It is not uncommon for an operator to deploy multiple OVN clusters, for
+       two main reasons. Firstly, an operator may prefer  to  deploy  one  OVN
+       cluster for each availability zone, e.g. in different physical regions,
+       to  avoid  single  point of failure. Secondly, there is always an upper
+       limit for a single OVN control plane to scale.
+
+       Although the control planes of the different  availability  zone  (AZ)s
+       are  independent  from each other, the workloads from different AZs may
+       need to communicate across the zones. The OVN  interconnection  feature
+       provides  a  native  way  to  interconnect  different AZs by L3 routing
+       through transit overlay networks between logical routers  of  different
+       AZs.
+
+       A  global OVN Interconnection Northbound database is introduced for the
+       operator (probably through CMS systems) to  configure  transit  logical
+       switches  that  connect  logical  routers from different AZs. A transit
+       switch is similar to a regular logical switch, but it is used  for  inā€
+       terconnection  purpose only. Typically, each transit switch can be used
+       to connect all logical routers that belong to same  tenant  across  all
+       AZs.
+
+       A  dedicated  daemon process ovn-ic, OVN interconnection controller, in
+       each AZ will consume  this  data  and  populate  corresponding  logical
+       switches to their own northbound databases for each AZ, so that logical
+       routers  can  be connected to the transit switch by creating patch port
+       pairs in their northbound databases. Any router ports connected to  the
+       transit  switches  are  considered interconnection ports, which will be
+       exchanged between AZs.
+
+       Physically, when workloads from different AZs communicate, packets need
+       to go through multiple hops: source chassis, source  gateway,  destinaā€
+       tion  gateway  and  destination  chassis.  All these hops are connected
+       through tunnels so that the packets never  leave  overlay  networks.  A
+       distributed gateway port is required to connect the logical router to a
+       transit  switch,  with a gateway chassis specified, so that the traffic
+       can be forwarded through the gateway chassis.
+
+       A global OVN Interconnection Southbound database is introduced for  exā€
+       changing  control  plane  information between the AZs. The data in this
+       database is populated and consumed by the ovn-ic, of each AZ. The  main
+       information in this database includes:
+
+              ā€¢      Datapath bindings for transit switches, which mainly conā€
+                     tains  the tunnel keys generated for each transit switch.
+                     Separate key ranges are reserved for transit switches  so
+                     that  they  will  never conflict with any tunnel keys loā€
+                     cally assigned for datapaths within each AZ.
+
+              ā€¢      Availability zones, which are registered by  ovn-ic  from
+                     each AZ.
+
+              ā€¢      Gateways.  Each  AZ specifies chassises that are supposed
+                     to work as interconnection gateways, and the ovn-ic  will
+                     populate  this  information to the interconnection southā€
+                     bound DB. The ovn-ic from all the other  AZs  will  learn
+                     the gateways and populate to their own southbound DB as a
+                     chassis.
+
+              ā€¢      Port  bindings  for  logical  switch ports created on the
+                     transit switch. Each AZ maintains their logical router to
+                     transit switch connections independently, but ovn-ic  auā€
+                     tomatically  populates  local  port  bindings  on transit
+                     switches to the global interconnection southbound DB, and
+                     learns remote port bindings from other AZs  back  to  its
+                     own  northbound and southbound DBs, so that logical flows
+                     can be produced and then translated to OVS flows locally,
+                     which finally enables data plane communication.
+
+              ā€¢      Routes that are advertised between different AZs. If  enā€
+                     abled, routes are automatically exchanged by ovn-ic. Both
+                     static  routes  and directly connected subnets are adverā€
+                     tised. Options in options column of the  NB_Global  table
+                     of  OVN_NB  database control the behavior of route adverā€
+                     tisement, such as enable/disable the advertising/learning
+                     routes, whether default  routes  are  advertised/learned,
+                     and blacklisted CIDRs. See ovn-nb(5) for more details.
+
+       The  tunnel keys for transit switch datapaths and related port bindings
+       must be agreed across all AZs. This is ensured by generating and  storā€
+       ing  the  keys  in  the global interconnection southbound database. Any
+       ovn-ic from any AZ can allocate the key, but race conditions are solved
+       by enforcing unique index for the column in the database.
+
+       Once each AZā€™s NB and SB databases are populated  with  interconnection
+       switches  and ports, and agreed upon the tunnel keys, data plane commuā€
+       nication between the AZs are established.
+
+       When VXLAN tunneling is enabled in an OVN cluster, due to  the  limited
+       range available for VNIs, Interconnection feature is not supported.
+
+     A day in the life of a packet crossing AZs
+
+              1.  An IP packet is sent out from a VIF on a hypervisor (HV1) of
+                  AZ1, with destination IP belonging to a VIF in AZ2.
+
+              2.  In  HV1ā€™s  OVS  flow tables, the packet goes through logical
+                  switch and logical router pipelines, and in a logical router
+                  pipeline, the routing stage finds out the next hop  for  the
+                  destination  IP,  which  belongs  to a remote logical router
+                  port in AZ2, and the output port, which is  a  chassis-rediā€
+                  rect  port  located  on  an  interconnection gateway (GW1 in
+                  AZ1), so HV1 sends the packet to GW1 through tunnel.
+
+              3.  On GW1, it continues with the logical router pipe  line  and
+                  switches  to  the transit switchā€™s pipeline through the peer
+                  port of the chassis redirect port. In the  transit  switchā€™s
+                  pipeline  it outputs to the remote logical port which is loā€
+                  cated on a gateway (GW2) in AZ2, so the GW1 sends the packet
+                  to GW2 in tunnel.
+
+              4.  On GW2, it continues with the transit  switch  pipeline  and
+                  switches  to  the  logical  router pipeline through the peer
+                  port, which is a chassis redirect port that  is  located  on
+                  GW2. The logical router pipeline then forwards the packet to
+                  relevant  logical  pipelines according to the destination IP
+                  address, and figures out the MAC and location of the  destiā€
+                  nation VIF port - a hypervisor (HV2). The GW2 then sends the
+                  packet to HV2 in tunnel.
+
+              5.  On HV2, the packet is delivered to the final destination VIF
+                  port  by  the  logical switch egress pipeline, just the same
+                  way as for intra-AZ communications.
+
+   Native OVN services for external logical ports
+       To support OVN native services (like DHCP/IPv6 RA/DNS  lookup)  to  the
+       cloud  resources  which  are  external,  OVN  supports external logical
+       ports.
+
+       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-controller do not
+                     bind these ports and cannot serve the native services.
+
+              ā€¢      When CMS supports provisioning baremetal servers.
+
+       OVN will provide the native services if CMS has done the below configuā€
+       ration in the OVN Northbound Database.
+
+              ā€¢      A row is created in Logical_Switch_Port, configuring  the
+                     addresses column and setting the type to external.
+
+              ā€¢      ha_chassis_group column is configured.
+
+              ā€¢      The  HA chassis which belongs to the HA chassis group has
+                     the ovn-bridge-mappings configured and has proper L2 conā€
+                     nectivity so that it can receive the DHCP and  other  reā€
+                     lated request packets from these external resources.
+
+              ā€¢      The Logical_Switch of this port has a localnet port.
+
+              ā€¢      Native  OVN  services are enabled by configuring the DHCP
+                     and other options like the way it is done for the  normal
+                     logical ports.
+
+       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 different chassis provide the native services. For exā€
+       ample when supporting native DHCPv4 service, DHCPv4 server mac (configā€
+       ured 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.
+
+SECURITY
+   Role-Based Access Controls for the Southbound DB
+       In  order  to provide additional security against the possibility of an
+       OVN chassis becoming compromised in such a way as to allow rogue  softā€
+       ware  to  make arbitrary modifications to the southbound database state
+       and thus disrupt the  OVN  network,  role-based  access  controls  (see
+       ovsdb-server(1) for additional details) are provided for the southbound
+       database.
+
+       The  implementation  of  role-based access controls (RBAC) requires the
+       addition of two tables to an OVSDB schema: the RBAC_Role  table,  which
+       is  indexed  by  role name and maps the the names of the various tables
+       that may be modifiable for a given role to individual rows in a permisā€
+       sions table containing detailed permission information for  that  role,
+       and  the  permission table itself which consists of rows containing the
+       following information:
+
+              Table Name
+                     The name of the associated table. This column exists priā€
+                     marily as an aid for humans reading the contents of  this
+                     table.
+
+              Auth Criteria
+                     A set of strings containing the names of columns (or colā€
+                     umn:key pairs for columns containing string:string maps).
+                     The contents of at least one of the columns or column:key
+                     values in a row to be modified, inserted, or deleted must
+                     be equal to the ID of the client attempting to act on the
+                     row  in order for the authorization check to pass. If the
+                     authorization criteria is empty,  authorization  checking
+                     is  disabled and all clients for the role will be treated
+                     as authorized.
+
+              Insert/Delete
+                     Row insertion/deletion permission; boolean value indicatā€
+                     ing whether insertion and deletion of rows is allowed for
+                     the associated table. If true, insertion and deletion  of
+                     rows is allowed for authorized clients.
+
+              Updatable Columns
+                     A  set of strings containing the names of columns or colā€
+                     umn:key pairs that may be updated or  mutated  by  authoā€
+                     rized  clients. Modifications to columns within a row are
+                     only permitted  when  the  authorization  check  for  the
+                     client passes and all columns to be modified are included
+                     in this set of modifiable columns.
+
+       RBAC  configuration  for  the  OVN southbound database is maintained by
+       ovn-northd. With RBAC enabled, modifications are only permitted for the
+       Chassis, Encap, Port_Binding,  and  MAC_Binding  tables,  and  are  reā€
+       stricted as follows:
+
+              Chassis
+                     Authorization: client ID must match the chassis name.
+
+                     Insert/Delete:  authorized row insertion and deletion are
+                     permitted.
+
+                     Update: The columns  nb_cfg,  external_ids,  encaps,  and
+                     vtep_logical_switches may be modified when authorized.
+
+              Encap  Authorization: client ID must match the chassis name.
+
+                     Insert/Delete: row insertion and row deletion are permitā€
+                     ted.
+
+                     Update:  The  columns  type, options, and ip can be modiā€
+                     fied.
+
+              Port_Binding
+                     Authorization: disabled (all clients are  considered  auā€
+                     thorized.  A  future enhancement may add columns (or keys
+                     to external_ids) in order to control  which  chassis  are
+                     allowed to bind each port.
+
+                     Insert/Delete:  row  insertion/deletion are not permitted
+                     (ovn-northd maintains rows in this table.
+
+                     Update: Only modifications to the chassis column are perā€
+                     mitted.
+
+              MAC_Binding
+                     Authorization: disabled (all clients are considered to be
+                     authorized).
+
+                     Insert/Delete: row insertion/deletion are permitted.
+
+                     Update: The columns logical_port, ip, mac,  and  datapath
+                     may be modified by ovn-controller.
+
+              IGMP_Group
+                     Authorization: disabled (all clients are considered to be
+                     authorized).
+
+                     Insert/Delete: row insertion/deletion are permitted.
+
+                     Update: The columns address, chassis, datapath, and ports
+                     may be modified by ovn-controller.
+
+       Enabling RBAC for ovn-controller connections to the southbound database
+       requires the following steps:
+
+              1.  Creating SSL certificates for each chassis with the certifiā€
+                  cate  CN  field  set to the chassis name (e.g. for a chassis
+                  with  external-ids:system-id=chassis-1,  via   the   command
+                  "ovs-pki -u req+sign chassis-1 switch").
+
+              2.  Configuring  each  ovn-controller to use SSL when connecting
+                  to the southbound database (e.g. via "ovs-vsctl set  open  .
+                  external-ids:ovn-remote=ssl:x.x.x.x:6642").
+
+              3.  Configuring  a southbound database SSL remote with "ovn-conā€
+                  troller"   role   (e.g.   via   "ovn-sbctl    set-connection
+                  role=ovn-controller pssl:6642").
+
+   Encrypt Tunnel Traffic with IPsec
+       OVN  tunnel  traffic  goes through physical routers and switches. These
+       physical devices could be untrusted  (devices  in  public  network)  or
+       might  be  compromised.  Enabling  encryption to the tunnel traffic can
+       prevent the traffic data from being monitored and manipulated.
+
+       The tunnel traffic is encrypted with IPsec. The CMS sets the ipsec colā€
+       umn in the northbound NB_Global table to enable or disable IPsec encryā€
+       tion. If ipsec is true, all OVN tunnels will be encrypted. If ipsec  is
+       false, no OVN tunnels will be encrypted.
+
+       When  CMS  updates  the ipsec column in the northbound NB_Global table,
+       ovn-northd copies the value to  the  ipsec  column  in  the  southbound
+       SB_Global table. ovn-controller in each chassis monitors the southbound
+       database  and sets the options of the OVS tunnel interface accordingly.
+       OVS tunnel interface options are  monitored  by  the  ovs-monitor-ipsec
+       daemon which configures IKE daemon to set up IPsec connections.
+
+       Chassis  authenticates each other by using certificate. The authenticaā€
+       tion succeeds if the other end in tunnel presents a certificate  signed
+       by  a  trusted CA and the common name (CN) matches the expected chassis
+       name. The SSL certificates used in role-based  access  controls  (RBAC)
+       can  be used in IPsec. Or use ovs-pki to create different certificates.
+       The certificate is required to be x.509 version 3, and  with  CN  field
+       and subjectAltName field being set to the chassis name.
+
+       The CA certificate, chassis certificate and private key are required to
+       be  installed  in  each  chassis  before  enabling  IPsec.  Please  see
+       ovs-vswitchd.conf.db(5) for setting up CA based IPsec authentication.
+
+DESIGN DECISIONS
+   Tunnel Encapsulations
+       In general, OVN annotates logical network packets that  it  sends  from
+       one  hypervisor to another with the following three pieces of metadata,
+       which are encoded in an encapsulation-specific fashion:
+
+              ā€¢      24-bit logical datapath identifier, from  the  tunnel_key
+                     column in the OVN Southbound Datapath_Binding table.
+
+              ā€¢      15-bit  logical ingress port identifier. ID 0 is reserved
+                     for internal use within OVN. IDs 1 through 32767,  incluā€
+                     sive,  may  be  assigned  to  logical ports (see the tunā€ā€
+                     nel_key column in the OVN Southbound Port_Binding table).
+
+              ā€¢      16-bit logical egress  port  identifier.  IDs  0  through
+                     32767 have the same meaning as for logical ingress ports.
+                     IDs  32768  through  65535, inclusive, may be assigned to
+                     logical multicast groups (see the  tunnel_key  column  in
+                     the OVN Southbound Multicast_Group table).
+
+       When  VXLAN  is  enabled  on  any hypervisor in a cluster, datapath and
+       egress port identifier ranges are reduced to 12-bits. This is done  beā€
+       cause only STT and Geneve provide the large space for metadata (over 32
+       bits per packet). To accommodate for VXLAN, 24 bits available are split
+       as follows:
+
+              ā€¢      12-bit logical datapath identifier, derived from the tunā€ā€
+                     nel_key column in the OVN Southbound Datapath_Binding taā€
+                     ble.
+
+              ā€¢      12-bit logical egress port identifier. IDs 0 through 2047
+                     are used for unicast output ports. IDs 2048 through 4095,
+                     inclusive,  may  be  assigned to logical multicast groups
+                     (see the tunnel_key column in the OVN  Southbound  Multiā€ā€
+                     cast_Group  table).  For  multicast  group tunnel keys, a
+                     special mapping scheme is used  to  internally  transform
+                     from  internal  OVN  16-bit  keys to 12-bit values before
+                     sending packets through a VXLAN  tunnel,  and  back  from
+                     12-bit  tunnel keys to 16-bit values when receiving packā€
+                     ets from a VXLAN tunnel.
+
+              ā€¢      No logical ingress port identifier.
+
+       The limited space available for metadata when VXLAN tunnels are enabled
+       in a cluster put the following  functional  limitations  onto  features
+       available to users:
+
+              ā€¢      The maximum number of networks is reduced to 4096.
+
+              ā€¢      The  maximum  number  of  ports per network is reduced to
+                     2048.
+
+              ā€¢      ACLs matching against logical  ingress  port  identifiers
+                     are not supported.
+
+              ā€¢      OVN interconnection feature is not supported.
+
+       In  addition  to  functional limitations described above, the following
+       should be considered before enabling it in your cluster:
+
+              ā€¢      STT and Geneve use randomized UDP  or  TCP  source  ports
+                     that  allows  efficient distribution among multiple paths
+                     in environments that use ECMP in their underlay.
+
+              ā€¢      NICs are available to offload STT and  Geneve  encapsulaā€
+                     tion and decapsulation.
+
+       Due to its flexibility, the preferred encapsulation between hypervisors
+       is Geneve. For Geneve encapsulation, OVN transmits the logical datapath
+       identifier  in  the  Geneve  VNI. OVN transmits the logical ingress and
+       logical egress ports in a TLV with  class  0x0102,  type  0x80,  and  a
+       32-bit value encoded as follows, from MSB to LSB:
+
+         1       15          16
+       +---+------------+-----------+
+       |rsv|ingress port|egress port|
+       +---+------------+-----------+
+         0
+
+
+       Environments  whose  NICs lack Geneve offload may prefer STT encapsulaā€
+       tion for performance reasons. For STT encapsulation,  OVN  encodes  all
+       three  pieces  of  logical metadata in the STT 64-bit tunnel ID as folā€
+       lows, from MSB to LSB:
+
+           9          15          16         24
+       +--------+------------+-----------+--------+
+       |reserved|ingress port|egress port|datapath|
+       +--------+------------+-----------+--------+
+           0
+
+
+       For connecting to gateways, in addition to Geneve and STT, OVN supports
+       VXLAN, because only  VXLAN  support  is  common  on  top-of-rack  (ToR)
+       switches. Currently, gateways have a feature set that matches the capaā€
+       bilities  as  defined by the VTEP schema, so fewer bits of metadata are
+       necessary. In the future, gateways that do not  support  encapsulations
+       with  large  amounts of metadata may continue to have a reduced feature
+       set.
+
+OVN 23.06.3                    OVN Architecture            ovn-architecture(7)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-architecture.7.pdf b/src/static/support/dist-docs-branch-23.06/ovn-architecture.7.pdf new file mode 100644 index 00000000..b2ee0570 Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-architecture.7.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-architecture.7.txt b/src/static/support/dist-docs-branch-23.06/ovn-architecture.7.txt new file mode 100644 index 00000000..a7ebf999 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-architecture.7.txt @@ -0,0 +1,2171 @@ +ovn-architecture(7) OVN Manual ovn-architecture(7) + +NAME + ovn-architecture - Open Virtual Network architecture + +DESCRIPTION + OVN, the Open Virtual Network, is a system to support logical network + abstraction in virtual machine and container environments. OVN compleā€ + ments the existing capabilities of OVS to add native support for logiā€ + cal network abstractions, such as logical L2 and L3 overlays and secuā€ + rity groups. Services such as DHCP are also desirable features. Just + like OVS, OVNā€™s design goal is to have a production-quality implementaā€ + tion that can operate at significant scale. + + A physical network comprises physical wires, switches, and routers. A + virtual network extends a physical network into a hypervisor or conā€ + tainer platform, bridging VMs or containers into the physical network. + An OVN logical network is a network implemented in software that is inā€ + sulated from physical (and thus virtual) networks by tunnels or other + encapsulations. This allows IP and other address spaces used in logical + networks to overlap with those used on physical networks without causā€ + ing conflicts. Logical network topologies can be arranged without reā€ + gard for the topologies of the physical networks on which they run. + Thus, VMs that are part of a logical network can migrate from one physā€ + ical machine to another without network disruption. See Logical Netā€ā€ + works, below, for more information. + + The encapsulation layer prevents VMs and containers connected to a logā€ + ical network from communicating with nodes on physical networks. For + clustering VMs and containers, this can be acceptable or even desirā€ + able, but in many cases VMs and containers do need connectivity to + physical networks. OVN provides multiple forms of gateways for this + purpose. See Gateways, below, for more information. + + An OVN deployment consists of several components: + + ā€¢ A Cloud Management System (CMS), which is OVNā€™s ultimate + client (via its users and administrators). OVN integraā€ + tion requires installing a CMS-specific plugin and reā€ + lated software (see below). OVN initially targets Openā€ + Stack as CMS. + + We generally speak of ``theā€™ā€™ CMS, but one can imagine + scenarios in which multiple CMSes manage different parts + of an OVN deployment. + + ā€¢ An OVN Database physical or virtual node (or, eventually, + cluster) installed in a central location. + + ā€¢ One or more (usually many) hypervisors. Hypervisors must + run Open vSwitch and implement the interface described in + Documentation/topics/integration.rst in the Open vSwitch + source tree. Any hypervisor platform supported by Open + vSwitch is acceptable. + + ā€¢ Zero or more gateways. A gateway extends a tunnel-based + logical network into a physical network by bidirectionā€ + ally forwarding packets between tunnels and a physical + Ethernet port. This allows non-virtualized machines to + participate in logical networks. A gateway may be a physā€ + ical host, a virtual machine, or an ASIC-based hardware + switch that supports the vtep(5) schema. + + Hypervisors and gateways are together called transport + node or chassis. + + The diagram below shows how the major components of OVN and related + software interact. Starting at the top of the diagram, we have: + + ā€¢ The Cloud Management System, as defined above. + + ā€¢ The OVN/CMS Plugin is the component of the CMS that inā€ + terfaces to OVN. In OpenStack, this is a Neutron plugin. + The pluginā€™s main purpose is to translate the CMSā€™s noā€ + tion of logical network configuration, stored in the + CMSā€™s configuration database in a CMS-specific format, + into an intermediate representation understood by OVN. + + This component is necessarily CMS-specific, so a new pluā€ + gin needs to be developed for each CMS that is integrated + with OVN. All of the components below this one in the diā€ + agram are CMS-independent. + + ā€¢ The OVN Northbound Database receives the intermediate + representation of logical network configuration passed + down by the OVN/CMS Plugin. The database schema is meant + to be ``impedance matchedā€™ā€™ with the concepts used in a + CMS, so that it directly supports notions of logical + switches, routers, ACLs, and so on. See ovn-nb(5) for deā€ + tails. + + The OVN Northbound Database has only two clients: the + OVN/CMS Plugin above it and ovn-northd below it. + + ā€¢ ovn-northd(8) connects to the OVN Northbound Database + above it and the OVN Southbound Database below it. It + translates the logical network configuration in terms of + conventional network concepts, taken from the OVN Northā€ + bound Database, into logical datapath flows in the OVN + Southbound Database below it. + + ā€¢ The OVN Southbound Database is the center of the system. + Its clients are ovn-northd(8) above it and ovn-conā€ā€ + troller(8) on every transport node below it. + + The OVN Southbound Database contains three kinds of data: + Physical Network (PN) tables that specify how to reach + hypervisor and other nodes, Logical Network (LN) tables + that describe the logical network in terms of ``logical + datapath flows,ā€™ā€™ and Binding tables that link logical + network componentsā€™ locations to the physical network. + The hypervisors populate the PN and Port_Binding tables, + whereas ovn-northd(8) populates the LN tables. + + OVN Southbound Database performance must scale with the + number of transport nodes. This will likely require some + work on ovsdb-server(1) as we encounter bottlenecks. + Clustering for availability may be needed. + + The remaining components are replicated onto each hypervisor: + + ā€¢ ovn-controller(8) is OVNā€™s agent on each hypervisor and + software gateway. Northbound, it connects to the OVN + Southbound Database to learn about OVN configuration and + status and to populate the PN table and the Chassis colā€ + umn in Binding table with the hypervisorā€™s status. Southā€ + bound, it connects to ovs-vswitchd(8) as an OpenFlow conā€ + troller, for control over network traffic, and to the loā€ + cal ovsdb-server(1) to allow it to monitor and control + Open vSwitch configuration. + + ā€¢ ovs-vswitchd(8) and ovsdb-server(1) are conventional comā€ + ponents of Open vSwitch. + + CMS + | + | + +-----------|-----------+ + | | | + | OVN/CMS Plugin | + | | | + | | | + | OVN Northbound DB | + | | | + | | | + | ovn-northd | + | | | + +-----------|-----------+ + | + | + +-------------------+ + | OVN Southbound DB | + +-------------------+ + | + | + +------------------+------------------+ + | | | + HV 1 | | HV n | + +---------------|---------------+ . +---------------|---------------+ + | | | . | | | + | ovn-controller | . | ovn-controller | + | | | | . | | | | + | | | | | | | | + | ovs-vswitchd ovsdb-server | | ovs-vswitchd ovsdb-server | + | | | | + +-------------------------------+ +-------------------------------+ + + + Information Flow in OVN + Configuration data in OVN flows from north to south. The CMS, through + its OVN/CMS plugin, passes the logical network configuration to + ovn-northd via the northbound database. In turn, ovn-northd compiles + the configuration into a lower-level form and passes it to all of the + chassis via the southbound database. + + Status information in OVN flows from south to north. OVN currently proā€ + vides only a few forms of status information. First, ovn-northd popuā€ + lates the up column in the northbound Logical_Switch_Port table: if a + logical portā€™s chassis column in the southbound Port_Binding table is + nonempty, it sets up to true, otherwise to false. This allows the CMS + to detect when a VMā€™s networking has come up. + + Second, OVN provides feedback to the CMS on the realization of its conā€ + figuration, that is, whether the configuration provided by the CMS has + taken effect. This feature requires the CMS to participate in a seā€ + quence number protocol, which works the following way: + + 1. When the CMS updates the configuration in the northbound + database, as part of the same transaction, it increments the + value of the nb_cfg column in the NB_Global table. (This is + only necessary if the CMS wants to know when the configuraā€ + tion has been realized.) + + 2. When ovn-northd updates the southbound database based on a + given snapshot of the northbound database, it copies nb_cfg + from northbound NB_Global into the southbound database + SB_Global table, as part of the same transaction. (Thus, an + observer monitoring both databases can determine when the + southbound database is caught up with the northbound.) + + 3. After ovn-northd receives confirmation from the southbound + database server that its changes have committed, it updates + sb_cfg in the northbound NB_Global table to the nb_cfg verā€ + sion that was pushed down. (Thus, the CMS or another obā€ + server can determine when the southbound database is caught + up without a connection to the southbound database.) + + 4. The ovn-controller process on each chassis receives the upā€ + dated southbound database, with the updated nb_cfg. This + process in turn updates the physical flows installed in the + chassisā€™s Open vSwitch instances. When it receives confirmaā€ + tion from Open vSwitch that the physical flows have been upā€ + dated, it updates nb_cfg in its own Chassis record in the + southbound database. + + 5. ovn-northd monitors the nb_cfg column in all of the Chassis + records in the southbound database. It keeps track of the + minimum value among all the records and copies it into the + hv_cfg column in the northbound NB_Global table. (Thus, the + CMS or another observer can determine when all of the hyperā€ + visors have caught up to the northbound configuration.) + + Chassis Setup + Each chassis in an OVN deployment must be configured with an Open + vSwitch bridge dedicated for OVNā€™s use, called the integration bridge. + System startup scripts may create this bridge prior to starting + ovn-controller if desired. If this bridge does not exist when ovn-conā€ + troller starts, it will be created automatically with the default conā€ + figuration suggested below. The ports on the integration bridge inā€ + clude: + + ā€¢ On any chassis, tunnel ports that OVN uses to maintain + logical network connectivity. ovn-controller adds, upā€ + dates, and removes these tunnel ports. + + ā€¢ On a hypervisor, any VIFs that are to be attached to logā€ + ical networks. For instances connected through software + emulated ports such as TUN/TAP or VETH pairs, the hyperā€ + visor itself will normally create ports and plug them + into the integration bridge. For instances connected + through representor ports, typically used with hardware + offload, the ovn-controller may on CMS direction consult + a VIF plug provider for representor port lookup and plug + them into the integration bridge (please refer to Docuā€ā€ + mentation/topā€ā€ + ics/vif-plug-providers/vif-plug-providers.rst + for more information). In both cases the conventions deā€ + scribed in Documentation/topics/integration.rst in the + Open vSwitch source tree is followed to ensure mapping + between OVN logical port and VIF. (This is pre-existing + integration work that has already been done on hyperviā€ + sors that support OVS.) + + ā€¢ On a gateway, the physical port used for logical network + connectivity. System startup scripts add this port to the + bridge prior to starting ovn-controller. This can be a + patch port to another bridge, instead of a physical port, + in more sophisticated setups. + + Other ports should not be attached to the integration bridge. In parā€ + ticular, physical ports attached to the underlay network (as opposed to + gateway ports, which are physical ports attached to logical networks) + must not be attached to the integration bridge. Underlay physical ports + should instead be attached to a separate Open vSwitch bridge (they need + not be attached to any bridge at all, in fact). + + The integration bridge should be configured as described below. The efā€ + fect of each of these settings is documented in + ovs-vswitchd.conf.db(5): + + fail-mode=secure + Avoids switching packets between isolated logical netā€ + works before ovn-controller starts up. See Controller + Failure Settings in ovs-vsctl(8) for more information. + + other-config:disable-in-band=true + Suppresses in-band control flows for the integration + bridge. It would be unusual for such flows to show up + anyway, because OVN uses a local controller (over a Unix + domain socket) instead of a remote controller. Itā€™s posā€ + sible, however, for some other bridge in the same system + to have an in-band remote controller, and in that case + this suppresses the flows that in-band control would orā€ + dinarily set up. Refer to the documentation for more inā€ + formation. + + The customary name for the integration bridge is br-int, but another + name may be used. + + Logical Networks + Logical network concepts in OVN include logical switches and logical + routers, the logical version of Ethernet switches and IP routers, reā€ + spectively. Like their physical cousins, logical switches and routers + can be connected into sophisticated topologies. Logical switches and + routers are ordinarily purely logical entities, that is, they are not + associated or bound to any physical location, and they are implemented + in a distributed manner at each hypervisor that participates in OVN. + + Logical switch ports (LSPs) are points of connectivity into and out of + logical switches. There are many kinds of logical switch ports. The + most ordinary kind represent VIFs, that is, attachment points for VMs + or containers. A VIF logical port is associated with the physical locaā€ + tion of its VM, which might change as the VM migrates. (A VIF logical + port can be associated with a VM that is powered down or suspended. + Such a logical port has no location and no connectivity.) + + Logical router ports (LRPs) are points of connectivity into and out of + logical routers. A LRP connects a logical router either to a logical + switch or to another logical router. Logical routers only connect to + VMs, containers, and other network nodes indirectly, through logical + switches. + + Logical switches and logical routers have distinct kinds of logical + ports, so properly speaking one should usually talk about logical + switch ports or logical router ports. However, an unqualified ``logical + portā€™ā€™ usually refers to a logical switch port. + + When a VM sends a packet to a VIF logical switch port, the Open vSwitch + flow tables simulate the packetā€™s journey through that logical switch + and any other logical routers and logical switches that it might enā€ + counter. This happens without transmitting the packet across any physiā€ + cal medium: the flow tables implement all of the switching and routing + decisions and behavior. If the flow tables ultimately decide to output + the packet at a logical port attached to another hypervisor (or another + kind of transport node), then that is the time at which the packet is + encapsulated for physical network transmission and sent. + + Logical Switch Port Types + + OVN supports a number of kinds of logical switch ports. VIF ports that + connect to VMs or containers, described above, are the most ordinary + kind of LSP. In the OVN northbound database, VIF ports have an empty + string for their type. This section describes some of the additional + port types. + + A router logical switch port connects a logical switch to a logical + router, designating a particular LRP as its peer. + + A localnet logical switch port bridges a logical switch to a physical + VLAN. A logical switch may have one or more localnet ports. Such a logā€ + ical switch is used in two scenarios: + + ā€¢ With one or more router logical switch ports, to attach + L3 gateway routers and distributed gateways to a physical + network. + + ā€¢ With one or more VIF logical switch ports, to attach VMs + or containers directly to a physical network. In this + case, the logical switch is not really logical, since it + is bridged to the physical network rather than insulated + from it, and therefore cannot have independent but overā€ + lapping IP address namespaces, etc. A deployment might + nevertheless choose such a configuration to take advanā€ + tage of the OVN control plane and features such as port + security and ACLs. + + When a logical switch contains multiple localnet ports, the following + is assumed. + + ā€¢ Each chassis has a bridge mapping for one of the localnet + physical networks only. + + ā€¢ To facilitate interconnectivity between VIF ports of the + switch that are located on different chassis with differā€ + ent physical network connectivity, the fabric implements + L3 routing between these adjacent physical network segā€ + ments. + + Note: nothing said above implies that a chassis cannot be plugged to + multiple physical networks as long as they belong to different + switches. + + A localport logical switch port is a special kind of VIF logical switch + port. These ports are present in every chassis, not bound to any parā€ + ticular one. Traffic to such a port will never be forwarded through a + tunnel, and traffic from such a port is expected to be destined only to + the same chassis, typically in response to a request it received. Openā€ + Stack Neutron uses a localport port to serve metadata to VMs. A metaā€ + data proxy process is attached to this port on every host and all VMs + within the same network will reach it at the same IP/MAC address withā€ + out any traffic being sent over a tunnel. For further details, see the + OpenStack documentation for networking-ovn. + + LSP types vtep and l2gateway are used for gateways. See Gateways, beā€ + low, for more information. + + Implementation Details + + These concepts are details of how OVN is implemented internally. They + might still be of interest to users and administrators. + + Logical datapaths are an implementation detail of logical networks in + the OVN southbound database. ovn-northd translates each logical switch + or router in the northbound database into a logical datapath in the + southbound database Datapath_Binding table. + + For the most part, ovn-northd also translates each logical switch port + in the OVN northbound database into a record in the southbound database + Port_Binding table. The latter table corresponds roughly to the northā€ + bound Logical_Switch_Port table. It has multiple types of logical port + bindings, of which many types correspond directly to northbound LSP + types. LSP types handled this way include VIF (empty string), localnet, + localport, vtep, and l2gateway. + + The Port_Binding table has some types of port binding that do not corā€ + respond directly to logical switch port types. The common is patch port + bindings, known as logical patch ports. These port bindings always ocā€ + cur in pairs, and a packet that enters on either side comes out on the + other. ovn-northd connects logical switches and logical routers toā€ + gether using logical patch ports. + + Port bindings with types vtep, l2gateway, l3gateway, and chassisrediā€ā€ + rect are used for gateways. These are explained in Gateways, below. + + Gateways + Gateways provide limited connectivity between logical networks and + physical ones. They can also provide connectivity between different OVN + deployments. This section will focus on the former, and the latter will + be described in details in section OVN Deployments Interconnection. + + OVN support multiple kinds of gateways. + + VTEP Gateways + + A ``VTEP gatewayā€™ā€™ connects an OVN logical network to a physical (or + virtual) switch that implements the OVSDB VTEP schema that accompanies + Open vSwitch. (The ``VTEP gatewayā€™ā€™ term is a misnomer, since a VTEP is + just a VXLAN Tunnel Endpoint, but it is a well established name.) See + Life Cycle of a VTEP gateway, below, for more information. + + The main intended use case for VTEP gateways is to attach physical + servers to an OVN logical network using a physical top-of-rack switch + that supports the OVSDB VTEP schema. + + L2 Gateways + + A L2 gateway simply attaches a designated physical L2 segment available + on some chassis to a logical network. The physical network effectively + becomes part of the logical network. + + To set up a L2 gateway, the CMS adds an l2gateway LSP to an appropriate + logical switch, setting LSP options to name the chassis on which it + should be bound. ovn-northd copies this configuration into a southbound + Port_Binding record. On the designated chassis, ovn-controller forwards + packets appropriately to and from the physical segment. + + L2 gateway ports have features in common with localnet ports. However, + with a localnet port, the physical network becomes the transport beā€ + tween hypervisors. With an L2 gateway, packets are still transported + between hypervisors over tunnels and the l2gateway port is only used + for the packets that are on the physical network. The application for + L2 gateways is similar to that for VTEP gateways, e.g. to add non-virā€ + tualized machines to a logical network, but L2 gateways do not require + special support from top-of-rack hardware switches. + + L3 Gateway Routers + + As described above under Logical Networks, ordinary OVN logical routers + are distributed: they are not implemented in a single place but rather + in every hypervisor chassis. This is a problem for stateful services + such as SNAT and DNAT, which need to be implemented in a centralized + manner. + + To allow for this kind of functionality, OVN supports L3 gateway + routers, which are OVN logical routers that are implemented in a desigā€ + nated chassis. Gateway routers are typically used between distributed + logical routers and physical networks. The distributed logical router + and the logical switches behind it, to which VMs and containers attach, + effectively reside on each hypervisor. The distributed router and the + gateway router are connected by another logical switch, sometimes reā€ + ferred to as a ``joinā€™ā€™ logical switch. (OVN logical routers may be + connected to one another directly, without an intervening switch, but + the OVN implementation only supports gateway logical routers that are + connected to logical switches. Using a join logical switch also reduces + the number of IP addresses needed on the distributed router.) On the + other side, the gateway router connects to another logical switch that + has a localnet port connecting to the physical network. + + The following diagram shows a typical situation. One or more logical + switches LS1, ..., LSn connect to distributed logical router LR1, which + in turn connects through LSjoin to gateway logical router GLR, which + also connects to logical switch LSlocal, which includes a localnet port + to attach to the physical network. + + LSlocal + | + GLR + | + LSjoin + | + LR1 + | + +----+----+ + | | | + LS1 ... LSn + + + To configure an L3 gateway router, the CMS sets options:chassis in the + routerā€™s northbound Logical_Router to the chassisā€™s name. In response, + ovn-northd uses a special l3gateway port binding (instead of a patch + binding) in the southbound database to connect the logical router to + its neighbors. In turn, ovn-controller tunnels packets to this port + binding to the designated L3 gateway chassis, instead of processing + them locally. + + DNAT and SNAT rules may be associated with a gateway router, which proā€ + vides a central location that can handle one-to-many SNAT (aka IP masā€ + querading). Distributed gateway ports, described below, also support + NAT. + + Distributed Gateway Ports + + A distributed gateway port is a logical router port that is specially + configured to designate one distinguished chassis, called the gateway + chassis, for centralized processing. A distributed gateway port should + connect to a logical switch that has an LSP that connects externally, + that is, either a localnet LSP or a connection to another OVN deployā€ + ment (see OVN Deployments Interconnection). Packets that traverse the + distributed gateway port are processed without involving the gateway + chassis when they can be, but when needed they do take an extra hop + through it. + + The following diagram illustrates the use of a distributed gateway + port. A number of logical switches LS1, ..., LSn connect to distributed + logical router LR1, which in turn connects through the distributed + gateway port to logical switch LSlocal that includes a localnet port to + attach to the physical network. + + LSlocal + | + LR1 + | + +----+----+ + | | | + LS1 ... LSn + + + ovn-northd creates two southbound Port_Binding records to represent a + distributed gateway port, instead of the usual one. One of these is a + patch port binding named for the LRP, which is used for as much traffic + as it can. The other one is a port binding with type chassisredirect, + named cr-port. The chassisredirect port binding has one specialized + job: when a packet is output to it, the flow table causes it to be tunā€ + neled to the gateway chassis, at which point it is automatically output + to the patch port binding. Thus, the flow table can output to this port + binding in cases where a particular task has to happen on the gateway + chassis. The chassisredirect port binding is not otherwise used (for + example, it never receives packets). + + The CMS may configure distributed gateway ports three different ways. + See Distributed Gateway Ports in the documentation for Logiā€ā€ + cal_Router_Port in ovn-nb(5) for details. + + Distributed gateway ports support high availability. When more than one + chassis is specified, OVN only uses one at a time as the gateway chasā€ + sis. OVN uses BFD to monitor gateway connectivity, preferring the highā€ + est-priority gateway that is online. + + A logical router can have multiple distributed gateway ports, each conā€ + necting different external networks. Load balancing is not yet supā€ + ported for logical routers with more than one distributed gateway port + configured. + + Physical VLAN MTU Issues + + Consider the preceding diagram again: + + LSlocal + | + LR1 + | + +----+----+ + | | | + LS1 ... LSn + + + Suppose that each logical switch LS1, ..., LSn is bridged to a physical + VLAN-tagged network attached to a localnet port on LSlocal, over a disā€ + tributed gateway port on LR1. If a packet originating on LSi is desā€ + tined to the external network, OVN sends it to the gateway chassis over + a tunnel. There, the packet traverses LR1ā€™s logical router pipeline, + possibly undergoes NAT, and eventually ends up at LSlocalā€™s localnet + port. If all of the physical links in the network have the same MTU, + then the packetā€™s transit across a tunnel causes an MTU problem: tunnel + overhead prevents a packet that uses the full physical MTU from crossā€ + ing the tunnel to the gateway chassis (without fragmentation). + + OVN offers two solutions to this problem, the reside-on-redirect-chasā€ā€ + sis and redirect-type options. Both solutions require each logical + switch LS1, ..., LSn to include a localnet logical switch port LN1, + ..., LNn respectively, that is present on each chassis. Both cause + packets to be sent over the localnet ports instead of tunnels. They + differ in which packets-some or all-are sent this way. The most promiā€ + nent tradeoff between these options is that reside-on-redirect-chassis + is easier to configure and that redirect-type performs better for east- + west traffic. + + The first solution is the reside-on-redirect-chassis option for logical + router ports. Setting this option on a LRP from (e.g.) LS1 to LR1 disā€ + ables forwarding from LS1 to LR1 except on the gateway chassis. On + chassis other than the gateway chassis, this single change means that + packets that would otherwise have been forwarded to LR1 are instead + forwarded to LN1. The instance of LN1 on the gateway chassis then reā€ + ceives the packet and forwards it to LR1. The packet traverses the LR1 + logical router pipeline, possibly undergoes NAT, and eventually ends up + at LSlocalā€™s localnet port. The packet never traverses a tunnel, avoidā€ + ing the MTU issue. + + This option has the further consequence of centralizing ``distributedā€™ā€™ + logical router LR1, since no packets are forwarded from LS1 to LR1 on + any chassis other than the gateway chassis. Therefore, east-west trafā€ + fic passes through the gateway chassis, not just north-south. (The + naive ``fixā€™ā€™ of allowing east-west traffic to flow directly between + chassis over LN1 does not work because routing sets the Ethernet source + address to LR1ā€™s source address. Seeing this single Ethernet source adā€ + dress originate from all of the chassis will confuse the physical + switch.) + + Do not set the reside-on-redirect-chassis option on a distributed gateā€ + way port. In the diagram above, it would be set on the LRPs connecting + LS1, ..., LSn to LR1. + + The second solution is the redirect-type option for distributed gateway + ports. Setting this option to bridged causes packets that are rediā€ + rected to the gateway chassis to go over the localnet ports instead of + being tunneled. This option does not change how OVN treats packets not + redirected to the gateway chassis. + + The redirect-type option requires the administrator or the CMS to conā€ + figure 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. This makes it more diffiā€ + cult to configure than reside-on-redirect-chassis. + + Set the redirect-type option on a distributed gateway port. + + Using Distributed Gateway Ports For Scalability + + Although the primary goal of distributed gateway ports is to provide + connectivity to external networks, there is a special use case for + scalability. + + In some deployments, such as the ones using ovn-kubernetes, logical + switches are bound to individual chassises, and are connected by a disā€ + tributed logical router. In such deployments, the chassis level logical + switches are centralized on the chassis instead of distributed, which + means the ovn-controller on each chassis doesnā€™t need to process flows + and ports of logical switches on other chassises. However, without any + specific hint, ovn-controller would still process all the logical + switches as if they are fully distributed. In this case, distributed + gateway port can be very useful. The chassis level logical switches can + be connected to the distributed router using distributed gateway ports, + by setting the gateway chassis (or HA chassis groups with only a single + chassis in it) to the chassis that each logical switch is bound to. + ovn-controller would then skip processing the logical switches on all + the other chassises, largely improving the scalability, especially when + there are a big number of chassises. + + Life Cycle of a VIF + Tables and their schemas presented in isolation are difficult to underā€ + stand. Hereā€™s an example. + + A VIF on a hypervisor is a virtual network interface attached either to + a VM or a container running directly on that hypervisor (This is difā€ + ferent from the interface of a container running inside a VM). + + The steps in this example refer often to details of the OVN and OVN + Northbound database schemas. Please see ovn-sb(5) and ovn-nb(5), reā€ + spectively, for the full story on these databases. + + 1. A VIFā€™s life cycle begins when a CMS administrator creates a + new VIF using the CMS user interface or API and adds it to a + switch (one implemented by OVN as a logical switch). The CMS + updates its own configuration. This includes associating + unique, persistent identifier vif-id and Ethernet address + mac with the VIF. + + 2. The CMS plugin updates the OVN Northbound database to inā€ + clude the new VIF, by adding a row to the Logiā€ā€ + cal_Switch_Port table. In the new row, name is vif-id, mac + is mac, switch points to the OVN logical switchā€™s Logiā€ + cal_Switch record, and other columns are initialized approā€ + priately. + + 3. ovn-northd receives the OVN Northbound database update. In + turn, it makes the corresponding updates to the OVN Southā€ + bound database, by adding rows to the OVN Southbound dataā€ + base Logical_Flow table to reflect the new port, e.g. add a + flow to recognize that packets destined to the new portā€™s + MAC address should be delivered to it, and update the flow + that delivers broadcast and multicast packets to include the + new port. It also creates a record in the Binding table and + populates all its columns except the column that identifies + the chassis. + + 4. On every hypervisor, ovn-controller receives the Logiā€ā€ + cal_Flow table updates that ovn-northd made in the previous + step. As long as the VM that owns the VIF is powered off, + ovn-controller cannot do much; it cannot, for example, + arrange to send packets to or receive packets from the VIF, + because the VIF does not actually exist anywhere. + + 5. Eventually, a user powers on the VM that owns the VIF. On + the hypervisor where the VM is powered on, the integration + between the hypervisor and Open vSwitch (described in Docuā€ā€ + mentation/topics/integration.rst in the Open vSwitch source + tree) adds the VIF to the OVN integration bridge and stores + vif-id in external_ids:iface-id to indicate that the interā€ + face is an instantiation of the new VIF. (None of this code + is new in OVN; this is pre-existing integration work that + has already been done on hypervisors that support OVS.) + + 6. On the hypervisor where the VM is powered on, ovn-controller + notices external_ids:iface-id in the new Interface. In reā€ + sponse, in the OVN Southbound DB, it updates the Binding taā€ + bleā€™s chassis column for the row that links the logical port + from external_ids: iface-id to the hypervisor. Afterward, + ovn-controller updates the local hypervisorā€™s OpenFlow taā€ + bles so that packets to and from the VIF are properly hanā€ + dled. + + 7. Some CMS systems, including OpenStack, fully start a VM only + when its networking is ready. To support this, ovn-northd + notices the chassis column updated for the row in Binding + table and pushes this upward by updating the up column in + the OVN Northbound databaseā€™s Logical_Switch_Port table to + indicate that the VIF is now up. The CMS, if it uses this + feature, can then react by allowing the VMā€™s execution to + proceed. + + 8. On every hypervisor but the one where the VIF resides, + ovn-controller notices the completely populated row in the + Binding table. This provides ovn-controller the physical loā€ + cation of the logical port, so each instance updates the + OpenFlow tables of its switch (based on logical datapath + flows in the OVN DB Logical_Flow table) so that packets to + and from the VIF can be properly handled via tunnels. + + 9. Eventually, a user powers off the VM that owns the VIF. On + the hypervisor where the VM was powered off, the VIF is + deleted from the OVN integration bridge. + + 10. On the hypervisor where the VM was powered off, ovn-conā€ā€ + troller notices that the VIF was deleted. In response, it + removes the Chassis column content in the Binding table for + the logical port. + + 11. On every hypervisor, ovn-controller notices the empty Chasā€ā€ + sis column in the Binding tableā€™s row for the logical port. + This means that ovn-controller no longer knows the physical + location of the logical port, so each instance updates its + OpenFlow table to reflect that. + + 12. Eventually, when the VIF (or its entire VM) is no longer + needed by anyone, an administrator deletes the VIF using the + CMS user interface or API. The CMS updates its own configuā€ + ration. + + 13. The CMS plugin removes the VIF from the OVN Northbound dataā€ + base, by deleting its row in the Logical_Switch_Port table. + + 14. ovn-northd receives the OVN Northbound update and in turn + updates the OVN Southbound database accordingly, by removing + or updating the rows from the OVN Southbound database Logiā€ā€ + cal_Flow table and Binding table that were related to the + now-destroyed VIF. + + 15. On every hypervisor, ovn-controller receives the Logiā€ā€ + cal_Flow table updates that ovn-northd made in the previous + step. ovn-controller updates OpenFlow tables to reflect the + update, although there may not be much to do, since the VIF + had already become unreachable when it was removed from the + Binding table in a previous step. + + Life Cycle of a Container Interface Inside a VM + OVN provides virtual network abstractions by converting information + written in OVN_NB database to OpenFlow flows in each hypervisor. Secure + virtual networking for multi-tenants can only be provided if OVN conā€ + troller is the only entity that can modify flows in Open vSwitch. When + the Open vSwitch integration bridge resides in the hypervisor, it is a + fair assumption to make that tenant workloads running inside VMs cannot + make any changes to Open vSwitch flows. + + If the infrastructure provider trusts the applications inside the conā€ + tainers not to break out and modify the Open vSwitch flows, then conā€ + tainers can be run in hypervisors. This is also the case when containā€ + ers are run inside the VMs and Open vSwitch integration bridge with + flows added by OVN controller resides in the same VM. For both the + above cases, the workflow is the same as explained with an example in + the previous section ("Life Cycle of a VIF"). + + This section talks about the life cycle of a container interface (CIF) + when containers are created in the VMs and the Open vSwitch integration + bridge resides inside the hypervisor. In this case, even if a container + application breaks out, other tenants are not affected because the conā€ + tainers running inside the VMs cannot modify the flows in the Open + vSwitch integration bridge. + + When multiple containers are created inside a VM, there are multiple + CIFs associated with them. The network traffic associated with these + CIFs need to reach the Open vSwitch integration bridge running in the + hypervisor for OVN to support virtual network abstractions. OVN should + also be able to distinguish network traffic coming from different CIFs. + There are two ways to distinguish network traffic of CIFs. + + One way is to provide one VIF for every CIF (1:1 model). This means + that there could be a lot of network devices in the hypervisor. This + would slow down OVS because of all the additional CPU cycles needed for + the management of all the VIFs. It would also mean that the entity creā€ + ating the containers in a VM should also be able to create the correā€ + sponding VIFs in the hypervisor. + + The second way is to provide a single VIF for all the CIFs (1:many + model). OVN could then distinguish network traffic coming from differā€ + ent CIFs via a tag written in every packet. OVN uses this mechanism and + uses VLAN as the tagging mechanism. + + 1. A CIFā€™s life cycle begins when a container is spawned inside + a VM by the either the same CMS that created the VM or a + tenant that owns that VM or even a container Orchestration + System that is different than the CMS that initially created + the VM. Whoever the entity is, it will need to know the vif- + id that is associated with the network interface of the VM + through which the container interfaceā€™s network traffic is + expected to go through. The entity that creates the conā€ + tainer interface will also need to choose an unused VLAN inā€ + side that VM. + + 2. The container spawning entity (either directly or through + the CMS that manages the underlying infrastructure) updates + the OVN Northbound database to include the new CIF, by + adding a row to the Logical_Switch_Port table. In the new + row, name is any unique identifier, parent_name is the vif- + id of the VM through which the CIFā€™s network traffic is exā€ + pected to go through and the tag is the VLAN tag that idenā€ + tifies the network traffic of that CIF. + + 3. ovn-northd receives the OVN Northbound database update. In + turn, it makes the corresponding updates to the OVN Southā€ + bound database, by adding rows to the OVN Southbound dataā€ + baseā€™s Logical_Flow table to reflect the new port and also + by creating a new row in the Binding table and populating + all its columns except the column that identifies the chasā€ā€ + sis. + + 4. On every hypervisor, ovn-controller subscribes to the + changes in the Binding table. When a new row is created by + ovn-northd that includes a value in parent_port column of + Binding table, the ovn-controller in the hypervisor whose + OVN integration bridge has that same value in vif-id in exā€ā€ + ternal_ids:iface-id updates the local hypervisorā€™s OpenFlow + tables so that packets to and from the VIF with the particuā€ + lar VLAN tag are properly handled. Afterward it updates the + chassis column of the Binding to reflect the physical locaā€ + tion. + + 5. One can only start the application inside the container afā€ + ter the underlying network is ready. To support this, + ovn-northd notices the updated chassis column in Binding taā€ + ble and updates the up column in the OVN Northbound dataā€ + baseā€™s Logical_Switch_Port table to indicate that the CIF is + now up. The entity responsible to start the container appliā€ + cation queries this value and starts the application. + + 6. Eventually the entity that created and started the conā€ + tainer, stops it. The entity, through the CMS (or directly) + deletes its row in the Logical_Switch_Port table. + + 7. ovn-northd receives the OVN Northbound update and in turn + updates the OVN Southbound database accordingly, by removing + or updating the rows from the OVN Southbound database Logiā€ā€ + cal_Flow table that were related to the now-destroyed CIF. + It also deletes the row in the Binding table for that CIF. + + 8. On every hypervisor, ovn-controller receives the Logiā€ā€ + cal_Flow table updates that ovn-northd made in the previous + step. ovn-controller updates OpenFlow tables to reflect the + update. + + Architectural Physical Life Cycle of a Packet + This section describes how a packet travels from one virtual machine or + container to another through OVN. This description focuses on the physā€ + ical treatment of a packet; for a description of the logical life cycle + of a packet, please refer to the Logical_Flow table in ovn-sb(5). + + This section mentions several data and metadata fields, for clarity + summarized here: + + tunnel key + When OVN encapsulates a packet in Geneve or another tunā€ + nel, it attaches extra data to it to allow the receiving + OVN instance to process it correctly. This takes differā€ + ent forms depending on the particular encapsulation, but + in each case we refer to it here as the ``tunnel key.ā€™ā€™ + See Tunnel Encapsulations, below, for details. + + logical datapath field + A field that denotes the logical datapath through which a + packet is being processed. OVN uses the field that Openā€ + Flow 1.1+ simply (and confusingly) calls ``metadataā€™ā€™ to + store the logical datapath. (This field is passed across + tunnels as part of the tunnel key.) + + logical input port field + A field that denotes the logical port from which the + packet entered the logical datapath. OVN stores this in + Open vSwitch extension register number 14. + + Geneve and STT tunnels pass this field as part of the + tunnel key. Ramp switch VXLAN tunnels do not explicitly + carry a logical input port, but since they are used to + communicate with gateways that from OVNā€™s perspective + consist of only a single logical port, so that OVN can + set the logical input port field to this one on ingress + to the OVN logical pipeline. As for regular VXLAN tunā€ + nels, they donā€™t carry input port field at all. This puts + additional limitations on cluster capabilities that are + described in Tunnel Encapsulations section. + + logical output port field + A field that denotes the logical port from which the + packet will leave the logical datapath. This is initialā€ + ized to 0 at the beginning of the logical ingress + pipeline. OVN stores this in Open vSwitch extension regā€ + ister number 15. + + Geneve, STT and regular VXLAN tunnels pass this field as + part of the tunnel key. Ramp switch VXLAN tunnels do not + transmit the logical output port field, and since they do + not carry a logical output port field in the tunnel key, + when a packet is received from ramp switch VXLAN tunnel + by an OVN hypervisor, the packet is resubmitted to table + 8 to determine the output port(s); when the packet + reaches table 39, these packets are resubmitted to table + 40 for local delivery by checking a MLF_RCV_FROM_RAMP + flag, which is set when the packet arrives from a ramp + tunnel. + + conntrack zone field for logical ports + A field that denotes the connection tracking zone for + logical ports. The value only has local significance and + is not meaningful between chassis. This is initialized to + 0 at the beginning of the logical ingress pipeline. OVN + stores this in Open vSwitch extension register number 13. + + conntrack zone fields for routers + Fields that denote the connection tracking zones for + routers. These values only have local significance and + are not meaningful between chassis. OVN stores the zone + information for north to south traffic (for DNATting or + ECMP symmetric replies) in Open vSwitch extension regisā€ + ter number 11 and zone information for south to north + traffic (for SNATing) in Open vSwitch extension register + number 12. + + logical flow flags + The logical flags are intended to handle keeping context + between tables in order to decide which rules in subseā€ + quent tables are matched. These values only have local + significance and are not meaningful between chassis. OVN + stores the logical flags in Open vSwitch extension regisā€ + ter number 10. + + VLAN ID + The VLAN ID is used as an interface between OVN and conā€ + tainers nested inside a VM (see Life Cycle of a container + interface inside a VM, above, for more information). + + Initially, a VM or container on the ingress hypervisor sends a packet + on a port attached to the OVN integration bridge. Then: + + 1. OpenFlow table 0 performs physical-to-logical translation. + It matches the packetā€™s ingress port. Its actions annotate + the packet with logical metadata, by setting the logical + datapath field to identify the logical datapath that the + packet is traversing and the logical input port field to + identify the ingress port. Then it resubmits to table 8 to + enter the logical ingress pipeline. + + Packets that originate from a container nested within a VM + are treated in a slightly different way. The originating + container can be distinguished based on the VIF-specific + VLAN ID, so the physical-to-logical translation flows addiā€ + tionally match on VLAN ID and the actions strip the VLAN + header. Following this step, OVN treats packets from conā€ + tainers just like any other packets. + + Table 0 also processes packets that arrive from other chasā€ + sis. It distinguishes them from other packets by ingress + port, which is a tunnel. As with packets just entering the + OVN pipeline, the actions annotate these packets with logiā€ + cal datapath metadata. For tunnel types that support it, + they are also annotated with logical ingress port metadata. + In addition, the actions set the logical output port field, + which is available because in OVN tunneling occurs after the + logical output port is known. These pieces of information + are obtained from the tunnel encapsulation metadata (see + Tunnel Encapsulations for encoding details). Then the acā€ + tions resubmit to table 38 to enter the logical egress + pipeline. + + 2. OpenFlow tables 8 through 31 execute the logical ingress + pipeline from the Logical_Flow table in the OVN Southbound + database. These tables are expressed entirely in terms of + logical concepts like logical ports and logical datapaths. A + big part of ovn-controllerā€™s job is to translate them into + equivalent OpenFlow (in particular it translates the table + numbers: Logical_Flow tables 0 through 23 become OpenFlow + tables 8 through 31). + + Each logical flow maps to one or more OpenFlow flows. An acā€ + tual packet ordinarily matches only one of these, although + in some cases it can match more than one of these flows + (which is not a problem because all of them have the same + actions). ovn-controller uses the first 32 bits of the logiā€ + cal flowā€™s UUID as the cookie for its OpenFlow flow or + flows. (This is not necessarily unique, since the first 32 + bits of a logical flowā€™s UUID is not necessarily unique.) + + Some logical flows can map to the Open vSwitch ``conjunctive + matchā€™ā€™ extension (see ovs-fields(7)). Flows with a conjuncā€ā€ + tion action use an OpenFlow cookie of 0, because they can + correspond to multiple logical flows. The OpenFlow flow for + a conjunctive match includes a match on conj_id. + + Some logical flows may not be represented in the OpenFlow + tables on a given hypervisor, if they could not be used on + that hypervisor. For example, if no VIF in a logical switch + resides on a given hypervisor, and the logical switch is not + otherwise reachable on that hypervisor (e.g. over a series + of hops through logical switches and routers starting from a + VIF on the hypervisor), then the logical flow may not be + represented there. + + Most OVN actions have fairly obvious implementations in + OpenFlow (with OVS extensions), e.g. next; is implemented as + resubmit, field = constant; as set_field. A few are worth + describing in more detail: + + output: + Implemented by resubmitting the packet to table 37. + If the pipeline executes more than one output action, + then each one is separately resubmitted to table 37. + This can be used to send multiple copies of the + packet to multiple ports. (If the packet was not modā€ + ified between the output actions, and some of the + copies are destined to the same hypervisor, then usā€ + ing a logical multicast output port would save bandā€ + width between hypervisors.) + + get_arp(P, A); + get_nd(P, A); + Implemented by storing arguments into OpenFlow fields, + then resubmitting to table 66, which ovn-controller + populates with flows generated from the MAC_Binding taā€ + ble in the OVN Southbound database. If there is a match + in table 66, then its actions store the bound MAC in + the Ethernet destination address field. + + (The OpenFlow actions save and restore the OpenFlow + fields used for the arguments, so that the OVN actions + do not have to be aware of this temporary use.) + + put_arp(P, A, E); + put_nd(P, A, E); + Implemented by storing the arguments into OpenFlow + fields, then outputting a packet to ovn-controller, + which updates the MAC_Binding table. + + (The OpenFlow actions save and restore the OpenFlow + fields used for the arguments, so that the OVN actions + do not have to be aware of this temporary use.) + + R = lookup_arp(P, A, M); + R = lookup_nd(P, A, M); + Implemented by storing arguments into OpenFlow fields, + then resubmitting to table 67, which ovn-controller + populates with flows generated from the MAC_Binding taā€ + ble in the OVN Southbound database. If there is a match + in table 67, then its actions set the logical flow flag + MLF_LOOKUP_MAC. + + (The OpenFlow actions save and restore the OpenFlow + fields used for the arguments, so that the OVN actions + do not have to be aware of this temporary use.) + + 3. OpenFlow tables 37 through 41 implement the output action in + the logical ingress pipeline. Specifically, table 37 serves + as an entry point to egress pipeline. Table 37 detects IP + packets that are too big for a corresponding interface. Taā€ + ble 38 produces ICMPv4 Fragmentation Needed (or ICMPv6 Too + Big) errors and deliver them back to the offending port. taā€ + ble 39 handles packets to remote hypervisors, table 40 hanā€ + dles packets to the local hypervisor, and table 41 checks + whether packets whose logical ingress and egress port are + the same should be discarded. + + Logical patch ports are a special case. Logical patch ports + do not have a physical location and effectively reside on + every hypervisor. Thus, flow table 40, for output to ports + on the local hypervisor, naturally implements output to uniā€ + cast logical patch ports too. However, applying the same + logic to a logical patch port that is part of a logical mulā€ + ticast group yields packet duplication, because each hyperā€ + visor that contains a logical port in the multicast group + will also output the packet to the logical patch port. Thus, + multicast groups implement output to logical patch ports in + table 39. + + Each flow in table 39 matches on a logical output port for + unicast or multicast logical ports that include a logical + port on a remote hypervisor. Each flowā€™s actions implement + sending a packet to the port it matches. For unicast logical + output ports on remote hypervisors, the actions set the tunā€ + nel key to the correct value, then send the packet on the + tunnel port to the correct hypervisor. (When the remote hyā€ + pervisor receives the packet, table 0 there will recognize + it as a tunneled packet and pass it along to table 40.) For + multicast logical output ports, the actions send one copy of + the packet to each remote hypervisor, in the same way as for + unicast destinations. If a multicast group includes a logiā€ + cal port or ports on the local hypervisor, then its actions + also resubmit to table 40. Table 39 also includes: + + ā€¢ A higher-priority rule to match packets received from + ramp switch tunnels, based on flag MLF_RCV_FROM_RAMP, + and resubmit these packets to table 40 for local deā€ + livery. Packets received from ramp switch tunnels + reach here because of a lack of logical output port + field in the tunnel key and thus these packets needed + to be submitted to table 8 to determine the output + port. + + ā€¢ A higher-priority rule to match packets received from + ports of type localport, based on the logical input + port, and resubmit these packets to table 40 for loā€ + cal delivery. Ports of type localport exist on every + hypervisor and by definition their traffic should + never go out through a tunnel. + + ā€¢ A higher-priority rule to match packets that have the + MLF_LOCAL_ONLY logical flow flag set, and whose desā€ + tination is a multicast address. This flag indicates + that the packet should not be delivered to remote hyā€ + pervisors, even if the multicast destination includes + ports on remote hypervisors. This flag is used when + ovn-controller is the originator of the multicast + packet. Since each ovn-controller instance is origiā€ + nating these packets, the packets only need to be deā€ + livered to local ports. + + ā€¢ A fallback flow that resubmits to table 40 if there + is no other match. + + Flows in table 40 resemble those in table 39 but for logical + ports that reside locally rather than remotely. For unicast + logical output ports on the local hypervisor, the actions + just resubmit to table 41. For multicast output ports that + include one or more logical ports on the local hypervisor, + for each such logical port P, the actions change the logical + output port to P, then resubmit to table 41. + + A special case is that when a localnet port exists on the + datapath, remote port is connected by switching to the loā€ + calnet port. In this case, instead of adding a flow in table + 39 to reach the remote port, a flow is added in table 40 to + switch the logical outport to the localnet port, and resubā€ + mit to table 40 as if it were unicasted to a logical port on + the local hypervisor. + + Table 41 matches and drops packets for which the logical inā€ + put and output ports are the same and the MLF_ALLOW_LOOPBACK + flag is not set. It also drops MLF_LOCAL_ONLY packets diā€ + rected to a localnet port. It resubmits other packets to taā€ + ble 42. + + 4. OpenFlow tables 42 through 62 execute the logical egress + pipeline from the Logical_Flow table in the OVN Southbound + database. The egress pipeline can perform a final stage of + validation before packet delivery. Eventually, it may exeā€ + cute an output action, which ovn-controller implements by + resubmitting to table 64. A packet for which the pipeline + never executes output is effectively dropped (although it + may have been transmitted through a tunnel across a physical + network). + + The egress pipeline cannot change the logical output port or + cause further tunneling. + + 5. Table 64 bypasses OpenFlow loopback when MLF_ALLOW_LOOPBACK + is set. Logical loopback was handled in table 41, but Openā€ + Flow by default also prevents loopback to the OpenFlow + ingress port. Thus, when MLF_ALLOW_LOOPBACK is set, OpenFlow + table 64 saves the OpenFlow ingress port, sets it to zero, + resubmits to table 65 for logical-to-physical transformaā€ + tion, and then restores the OpenFlow ingress port, effecā€ + tively disabling OpenFlow loopback prevents. When MLF_ALā€ + LOW_LOOPBACK is unset, table 64 flow simply resubmits to taā€ + ble 65. + + 6. OpenFlow table 65 performs logical-to-physical translation, + the opposite of table 0. It matches the packetā€™s logical + egress port. Its actions output the packet to the port atā€ + tached to the OVN integration bridge that represents that + logical port. If the logical egress port is a container + nested with a VM, then before sending the packet the actions + push on a VLAN header with an appropriate VLAN ID. + + Logical Routers and Logical Patch Ports + Typically logical routers and logical patch ports do not have a physiā€ + cal location and effectively reside on every hypervisor. This is the + case for logical patch ports between logical routers and logical + switches behind those logical routers, to which VMs (and VIFs) attach. + + Consider a packet sent from one virtual machine or container to another + VM or container that resides on a different subnet. The packet will + traverse tables 0 to 65 as described in the previous section Architecā€ā€ + tural Physical Life Cycle of a Packet, using the logical datapath repā€ + resenting the logical switch that the sender is attached to. At table + 39, the packet will use the fallback flow that resubmits locally to taā€ + ble 40 on the same hypervisor. In this case, all of the processing from + table 0 to table 65 occurs on the hypervisor where the sender resides. + + When the packet reaches table 65, the logical egress port is a logical + patch port. ovn-controller implements output to the logical patch is + packet by cloning and resubmitting directly to the first OpenFlow flow + table in the ingress pipeline, setting the logical ingress port to the + peer logical patch port, and using the peer logical patch portā€™s logiā€ + cal datapath (that represents the logical router). + + The packet re-enters the ingress pipeline in order to traverse tables 8 + to 65 again, this time using the logical datapath representing the logā€ + ical router. The processing continues as described in the previous secā€ + tion Architectural Physical Life Cycle of a Packet. When the packet + reaches table 65, the logical egress port will once again be a logical + patch port. In the same manner as described above, this logical patch + port will cause the packet to be resubmitted to OpenFlow tables 8 to + 65, this time using the logical datapath representing the logical + switch that the destination VM or container is attached to. + + The packet traverses tables 8 to 65 a third and final time. If the desā€ + tination VM or container resides on a remote hypervisor, then table 39 + will send the packet on a tunnel port from the senderā€™s hypervisor to + the remote hypervisor. Finally table 65 will output the packet directly + to the destination VM or container. + + The following sections describe two exceptions, where logical routers + and/or logical patch ports are associated with a physical location. + + Gateway Routers + + A gateway router is a logical router that is bound to a physical locaā€ + tion. This includes all of the logical patch ports of the logical + router, as well as all of the peer logical patch ports on logical + switches. In the OVN Southbound database, the Port_Binding entries for + these logical patch ports use the type l3gateway rather than patch, in + order to distinguish that these logical patch ports are bound to a + chassis. + + When a hypervisor processes a packet on a logical datapath representing + a logical switch, and the logical egress port is a l3gateway port repā€ + resenting connectivity to a gateway router, the packet will match a + flow in table 39 that sends the packet on a tunnel port to the chassis + where the gateway router resides. This processing in table 39 is done + in the same manner as for VIFs. + + Distributed Gateway Ports + + This section provides additional details on distributed gateway ports, + outlined earlier. + + The primary design goal of distributed gateway ports is to allow as + much traffic as possible to be handled locally on the hypervisor where + a VM or container resides. Whenever possible, packets from the VM or + container to the outside world should be processed completely on that + VMā€™s or containerā€™s hypervisor, eventually traversing a localnet port + instance or a tunnel to the physical network or a different OVN deployā€ + ment. Whenever possible, packets from the outside world to a VM or conā€ + tainer should be directed through the physical network directly to the + VMā€™s or containerā€™s hypervisor. + + In order to allow for the distributed processing of packets described + in the paragraph above, distributed gateway ports need to be logical + patch ports that effectively reside on every hypervisor, rather than + l3gateway ports that are bound to a particular chassis. However, the + flows associated with distributed gateway ports often need to be assoā€ + ciated with physical locations, for the following reasons: + + ā€¢ The physical network that the localnet port is attached + to typically uses L2 learning. Any Ethernet address used + over the distributed gateway port must be restricted to a + single physical location so that upstream L2 learning is + not confused. Traffic sent out the distributed gateway + port towards the localnet port with a specific Ethernet + address must be sent out one specific instance of the + distributed gateway port on one specific chassis. Traffic + received from the localnet port (or from a VIF on the + same logical switch as the localnet port) with a specific + Ethernet address must be directed to the logical switchā€™s + patch port instance on that specific chassis. + + Due to the implications of L2 learning, the Ethernet adā€ + dress and IP address of the distributed gateway port need + to be restricted to a single physical location. For this + reason, the user must specify one chassis associated with + the distributed gateway port. Note that traffic traversā€ + ing the distributed gateway port using other Ethernet adā€ + dresses and IP addresses (e.g. one-to-one NAT) is not reā€ + stricted to this chassis. + + Replies to ARP and ND requests must be restricted to a + single physical location, where the Ethernet address in + the reply resides. This includes ARP and ND replies for + the IP address of the distributed gateway port, which are + restricted to the chassis that the user associated with + the distributed gateway port. + + ā€¢ In order to support one-to-many SNAT (aka IP masqueradā€ + ing), where multiple logical IP addresses spread across + multiple chassis are mapped to a single external IP adā€ + dress, it will be necessary to handle some of the logical + router processing on a specific chassis in a centralized + manner. Since the SNAT external IP address is typically + the distributed gateway port IP address, and for simplicā€ + ity, the same chassis associated with the distributed + gateway port is used. + + The details of flow restrictions to specific chassis are described in + the ovn-northd documentation. + + While most of the physical location dependent aspects of distributed + gateway ports can be handled by restricting some flows to specific + chassis, one additional mechanism is required. When a packet leaves the + ingress pipeline and the logical egress port is the distributed gateway + port, one of two different sets of actions is required at table 39: + + ā€¢ If the packet can be handled locally on the senderā€™s hyā€ + pervisor (e.g. one-to-one NAT traffic), then the packet + should just be resubmitted locally to table 40, in the + normal manner for distributed logical patch ports. + + ā€¢ However, if the packet needs to be handled on the chassis + associated with the distributed gateway port (e.g. one- + to-many SNAT traffic or non-NAT traffic), then table 39 + must send the packet on a tunnel port to that chassis. + + In order to trigger the second set of actions, the chassisredirect type + of southbound Port_Binding has been added. Setting the logical egress + port to the type chassisredirect logical port is simply a way to indiā€ + cate that although the packet is destined for the distributed gateway + port, it needs to be redirected to a different chassis. At table 39, + packets with this logical egress port are sent to a specific chassis, + in the same way that table 39 directs packets whose logical egress port + is a VIF or a type l3gateway port to different chassis. Once the packet + arrives at that chassis, table 40 resets the logical egress port to the + value representing the distributed gateway port. For each distributed + gateway port, there is one type chassisredirect port, in addition to + the distributed logical patch port representing the distributed gateway + port. + + High Availability for Distributed Gateway Ports + + OVN allows you to specify a prioritized list of chassis for a distribā€ + uted gateway port. This is done by associating multiple Gateway_Chassis + rows with a Logical_Router_Port in the OVN_Northbound database. + + When multiple chassis have been specified for a gateway, all chassis + that may send packets to that gateway will enable BFD on tunnels to all + configured gateway chassis. The current master chassis for the gateway + is the highest priority gateway chassis that is currently viewed as acā€ + tive based on BFD status. + + For more information on L3 gateway high availability, please refer to + http://docs.ovn.org/en/latest/topics/high-availability.html. + + Restrictions of Distributed Gateway Ports + + Distributed gateway ports are used to connect to an external network, + which can be a physical network modeled by a logical switch with a loā€ + calnet port, and can also be a logical switch that interconnects difā€ + ferent OVN deployments (see OVN Deployments Interconnection). Usually + there can be many logical routers connected to the same external logiā€ + cal switch, as shown in below diagram. + + +--LS-EXT-+ + | | | + | | | + LR1 ... LRn + + + In this diagram, there are n logical routers connected to a logical + switch LS-EXT, each with a distributed gateway port, so that traffic + sent to external world is redirected to the gateway chassis that is asā€ + signed to the distributed gateway port of respective logical router. + + In the logical topology, nothing can prevent an user to add a route beā€ + tween the logical routers via the connected distributed gateway ports + on LS-EXT. However, the route works only if the LS-EXT is a physical + network (modeled by a logical switch with a localnet port). In that + case the packet will be delivered between the gateway chassises through + the localnet port via physical network. If the LS-EXT is a regular logā€ + ical switch (backed by tunneling only, as in the use case of OVN interā€ + connection), then the packet will be dropped on the source gateway + chassis. The limitation is due the fact that distributed gateway ports + are tied to physical location, and without physical network connection, + we will end up with either dropping the packet or transferring it over + the tunnels which could cause bigger problems such as broadcast packets + being redirect repeatedly by different gateway chassises. + + With the limitation in mind, if a user do want the direct connectivity + between the logical routers, it is better to create an internal logical + switch connected to the logical routers with regular logical router + ports, which are completely distributed and the packets donā€™t have to + leave a chassis unless necessary, which is more optimal than routing + via the distributed gateway ports. + + ARP request and ND NS packet processing + + Due to the fact that ARP requests and ND NA packets are usually broadā€ + cast packets, for performance reasons, OVN deals with requests that + target OVN owned IP addresses (i.e., IP addresses configured on the + router ports, VIPs, NAT IPs) in a specific way and only forwards them + to the logical router that owns the target IP address. This behavior is + different than that of traditional switches and implies that other + routers/hosts connected to the logical switch will not learn the MAC/IP + binding from the request packet. + + All other ARP and ND packets are flooded in the L2 broadcast domain and + to all attached logical patch ports. + + VIFs on the logical switch connected by a distributed gateway port + + Typically the logical switch connected by a distributed gateway port is + for external connectivity, usually to a physical network through a loā€ + calnet port on the logical switch, or to a remote OVN deployment + through OVN Interconnection. In these cases there is no VIF ports reā€ + quired on the logical switch. + + While not very common, it is still possible to create VIF ports on the + logical switch connected by a distributed gateway port, but there is a + limitation that the logical ports need to reside on the gateway chassis + where the distributed gateway port resides to get connectivity to other + logical switches through the distributed gateway port. There is no limā€ + itation for the VIFs to connect within the logical switch, or beyond + the logical switch through other regular distributed logical router + ports. + + A special case is when using distributed gateway ports for scalability + purpose, as mentioned earlier in this document. The logical switches + connected by distributed gateway ports are not for connectivity but + just for regular VIFs. However, the above limitation usually does not + matter because in this use case all the VIFs on the logical switch are + located on the same chassis with the distributed gateway port that conā€ + nects the logical switch. + + Multiple localnet logical switches connected to a Logical Router + It is possible to have multiple logical switches each with a localnet + port (representing physical networks) connected to a logical router, in + which one localnet logical switch may provide the external connectivity + via a distributed gateway port and rest of the localnet logical + switches use VLAN tagging in the physical network. It is expected that + ovn-bridge-mappings is configured appropriately on the chassis for all + these localnet networks. + + East West routing + + East-West routing between these localnet VLAN tagged logical switches + work almost the same way as normal logical switches. When the VM sends + such a packet, then: + + 1. It first enters the ingress pipeline, and then egress + pipeline of the source localnet logical switch datapath. It + then enters the ingress pipeline of the logical router dataā€ + path via the logical router port in the source chassis. + + 2. Routing decision is taken. + + 3. From the router datapath, packet enters the ingress pipeline + and then egress pipeline of the destination localnet logical + switch datapath and goes out of the integration bridge to + the provider bridge ( belonging to the destination logical + switch) via the localnet port. While sending the packet to + provider bridge, we also replace router port MAC as source + MAC with a chassis unique MAC. + + This chassis unique MAC is configured as global ovs config + on each chassis (eg. via "ovs-vsctl set open . external-ids: + ovn-chassis-mac-mappings="phys:aa:bb:cc:dd:ee:$i$i""). For + more details, see ovn-controller(8). + + If the above is not configured, then source MAC would be the + router port MAC. This could create problem if we have more + than one chassis. This is because, since the router port is + distributed, the same (MAC,VLAN) tuple will seen by physical + network from other chassis as well, which could cause these + issues: + + ā€¢ Continuous MAC moves in top-of-rack switch (ToR). + + ā€¢ ToR dropping the traffic, which is causing continuous + MAC moves. + + ā€¢ ToR blocking the ports from which MAC moves are hapā€ + pening. + + 4. The destination chassis receives the packet via the localnet + port and sends it to the integration bridge. Before entering + the integration bridge the source mac of the packet will be + replaced with router port mac again. The packet enters the + ingress pipeline and then egress pipeline of the destination + localnet logical switch and finally gets delivered to the + destination VM port. + + External traffic + + The following happens when a VM sends an external traffic (which reā€ + quires NATting) and the chassis hosting the VM doesnā€™t have a distribā€ + uted gateway port. + + 1. The packet first enters the ingress pipeline, and then + egress pipeline of the source localnet logical switch dataā€ + path. It then enters the ingress pipeline of the logical + router datapath via the logical router port in the source + chassis. + + 2. Routing decision is taken. Since the gateway router or the + distributed gateway port doesnā€™t reside in the source chasā€ + sis, the traffic is redirected to the gateway chassis via + the tunnel port. + + 3. The gateway chassis receives the packet via the tunnel port + and the packet enters the egress pipeline of the logical + router datapath. NAT rules are applied here. The packet then + enters the ingress pipeline and then egress pipeline of the + localnet logical switch datapath which provides external + connectivity and finally goes out via the localnet port of + the logical switch which provides external connectivity. + + Although this works, the VM traffic is tunnelled when sent from the + compute chassis to the gateway chassis. In order for it to work propā€ + erly, the MTU of the localnet logical switches must be lowered to acā€ + count for the tunnel encapsulation. + + Centralized routing for localnet VLAN tagged logical switches connected to + a Logical Router + To overcome the tunnel encapsulation problem described in the previous + section, OVN supports the option of enabling centralized routing for + localnet VLAN tagged logical switches. CMS can configure the option opā€ā€ + tions:reside-on-redirect-chassis to true for each Logical_Router_Port + which connects to the localnet VLAN tagged logical switches. This + causes the gateway chassis (hosting the distributed gateway port) to + handle all the routing for these networks, making it centralized. It + will reply to the ARP requests for the logical router port IPs. + + If the logical router doesnā€™t have a distributed gateway port connectā€ + ing to the localnet logical switch which provides external connectivā€ + ity, or if it has more than one distributed gateway ports, then this + option is ignored by OVN. + + The following happens when a VM sends an east-west traffic which needs + to be routed: + + 1. The packet first enters the ingress pipeline, and then + egress pipeline of the source localnet logical switch dataā€ + path and is sent out via a localnet port of the source loā€ + calnet logical switch (instead of sending it to router + pipeline). + + 2. The gateway chassis receives the packet via a localnet port + of the source localnet logical switch and sends it to the + integration bridge. The packet then enters the ingress + pipeline, and then egress pipeline of the source localnet + logical switch datapath and enters the ingress pipeline of + the logical router datapath. + + 3. Routing decision is taken. + + 4. From the router datapath, packet enters the ingress pipeline + and then egress pipeline of the destination localnet logical + switch datapath. It then goes out of the integration bridge + to the provider bridge ( belonging to the destination logiā€ + cal switch) via a localnet port. + + 5. The destination chassis receives the packet via a localnet + port and sends it to the integration bridge. The packet enā€ + ters the ingress pipeline and then egress pipeline of the + destination localnet logical switch and finally delivered to + the destination VM port. + + The following happens when a VM sends an external traffic which reā€ + quires NATting: + + 1. The packet first enters the ingress pipeline, and then + egress pipeline of the source localnet logical switch dataā€ + path and is sent out via a localnet port of the source loā€ + calnet logical switch (instead of sending it to router + pipeline). + + 2. The gateway chassis receives the packet via a localnet port + of the source localnet logical switch and sends it to the + integration bridge. The packet then enters the ingress + pipeline, and then egress pipeline of the source localnet + logical switch datapath and enters the ingress pipeline of + the logical router datapath. + + 3. Routing decision is taken and NAT rules are applied. + + 4. From the router datapath, packet enters the ingress pipeline + and then egress pipeline of the localnet logical switch + datapath which provides external connectivity. It then goes + out of the integration bridge to the provider bridge (beā€ + longing to the logical switch which provides external conā€ + nectivity) via a localnet port. + + The following happens for the reverse external traffic. + + 1. The gateway chassis receives the packet from a localnet port + of the logical switch which provides external connectivity. + The packet then enters the ingress pipeline and then egress + pipeline of the localnet logical switch (which provides exā€ + ternal connectivity). The packet then enters the ingress + pipeline of the logical router datapath. + + 2. The ingress pipeline of the logical router datapath applies + the unNATting rules. The packet then enters the ingress + pipeline and then egress pipeline of the source localnet + logical switch. Since the source VM doesnā€™t reside in the + gateway chassis, the packet is sent out via a localnet port + of the source logical switch. + + 3. The source chassis receives the packet via a localnet port + and sends it to the integration bridge. The packet enters + the ingress pipeline and then egress pipeline of the source + localnet logical switch and finally gets delivered to the + source VM port. + + As an alternative to reside-on-redirect-chassis, OVN supports VLAN- + based redirection. Whereas reside-on-redirect-chassis centralizes all + router functionality, VLAN-based redirection only changes how OVN rediā€ + rects packets to the gateway chassis. By setting options:redirect-type + to bridged on a distributed gateway port, OVN redirects packets to the + gateway chassis using the localnet port of the routerā€™s peer logical + switch, instead of a tunnel. + + If the logical router doesnā€™t have a distributed gateway port connectā€ + ing to the localnet logical switch which provides external connectivā€ + ity, or if it has more than one distributed gateway ports, then this + option is ignored by OVN. + + Following happens for bridged redirection: + + 1. On compute chassis, packet passes though logical routerā€™s + ingress pipeline. + + 2. If logical outport is gateway chassis attached router port + then packet is "redirected" to gateway chassis using peer + logical switchā€™s localnet port. + + 3. This redirected packet has destination mac as router port + mac (the one to which gateway chassis is attached). Its VLAN + id is that of localnet port (peer logical switch of the logā€ + ical router port). + + 4. On the gateway chassis packet will enter the logical router + pipeline again and this time it will passthrough egress + pipeline as well. + + 5. Reverse traffic packet flows stays the same. + + Some guidelines and expections with bridged redirection: + + 1. Since router port mac is destination mac, hence it has to be + ensured that physical network learns it on ONLY from the + gateway chassis. Which means that ovn-chassis-mac-mappings + should be configure on all the compute nodes, so that physiā€ + cal network never learn router port mac from compute nodes. + + 2. Since packet enters logical router ingress pipeline twice + (once on compute chassis and again on gateway chassis), + hence ttl will be decremented twice. + + 3. Default redirection type continues to be overlay. User can + switch the redirect-type between bridged and overlay by + changing the value of options:redirect-type + + Life Cycle of a VTEP gateway + 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. + + The steps below refer often to details of the OVN and VTEP database + schemas. Please see ovn-sb(5), ovn-nb(5) and vtep(5), respectively, for + the full story on these databases. + + 1. A VTEP gatewayā€™s life cycle begins with the administrator + registering the VTEP gateway as a Physical_Switch table enā€ + try in the VTEP database. The ovn-controller-vtep connected + to this VTEP database, will recognize the new VTEP gateway + and create a new Chassis table entry for it in the + OVN_Southbound database. + + 2. The administrator can then create a new Logical_Switch table + entry, and bind a particular vlan on a VTEP gatewayā€™s port + to any VTEP logical switch. Once a VTEP logical switch is + bound to a VTEP gateway, the ovn-controller-vtep will detect + it and add its name to the vtep_logical_switches column of + the Chassis table in the OVN_Southbound database. Note, the + tunnel_key column of VTEP logical switch is not filled at + creation. The ovn-controller-vtep will set the column when + the corresponding vtep logical switch is bound to an OVN + logical network. + + 3. Now, the administrator can use the CMS to add a VTEP logical + switch to the OVN logical network. To do that, the CMS must + first create a new Logical_Switch_Port table entry in the + OVN_Northbound database. Then, the type column of this entry + must be set to "vtep". Next, the vtep-logical-switch and + vtep-physical-switch keys in the options column must also be + specified, since multiple VTEP gateways can attach to the + same VTEP logical switch. Next, the addresses column of this + logical port must be set to "unknown", it will add a priorā€ + ity 0 entry in "ls_in_l2_lkup" stage of logical switch + ingress pipeline. So, traffic with unrecorded mac by OVN + would go through the Logical_Switch_Port to physical netā€ + work. + + 4. The newly created logical port in the OVN_Northbound dataā€ + base and its configuration will be passed down to the + OVN_Southbound database as a new Port_Binding table entry. + The ovn-controller-vtep will recognize the change and bind + the logical port to the corresponding VTEP gateway chassis. + Configuration of binding the same VTEP logical switch to a + different OVN logical networks is not allowed and a warning + will be generated in the log. + + 5. Beside binding to the VTEP gateway chassis, the ovn-conā€ā€ + troller-vtep will update the tunnel_key column of the VTEP + logical switch to the corresponding Datapath_Binding table + entryā€™s tunnel_key for the bound OVN logical network. + + 6. Next, the ovn-controller-vtep will keep reacting to the conā€ + figuration change in the Port_Binding in the OVN_Northbound + database, and updating the Ucast_Macs_Remote table in the + VTEP database. This allows the VTEP gateway to understand + where to forward the unicast traffic coming from the exā€ + tended external network. + + 7. Eventually, the VTEP gatewayā€™s life cycle ends when the adā€ + ministrator unregisters the VTEP gateway from the VTEP dataā€ + base. The ovn-controller-vtep will recognize the event and + remove all related configurations (Chassis table entry and + port bindings) in the OVN_Southbound database. + + 8. When the ovn-controller-vtep is terminated, all related conā€ + figurations in the OVN_Southbound database and the VTEP + database will be cleaned, including Chassis table entries + for all registered VTEP gateways and their port bindings, + and all Ucast_Macs_Remote table entries and the Logiā€ā€ + cal_Switch tunnel keys. + + OVN Deployments Interconnection + It is not uncommon for an operator to deploy multiple OVN clusters, for + two main reasons. Firstly, an operator may prefer to deploy one OVN + cluster for each availability zone, e.g. in different physical regions, + to avoid single point of failure. Secondly, there is always an upper + limit for a single OVN control plane to scale. + + Although the control planes of the different availability zone (AZ)s + are independent from each other, the workloads from different AZs may + need to communicate across the zones. The OVN interconnection feature + provides a native way to interconnect different AZs by L3 routing + through transit overlay networks between logical routers of different + AZs. + + A global OVN Interconnection Northbound database is introduced for the + operator (probably through CMS systems) to configure transit logical + switches that connect logical routers from different AZs. A transit + switch is similar to a regular logical switch, but it is used for inā€ + terconnection purpose only. Typically, each transit switch can be used + to connect all logical routers that belong to same tenant across all + AZs. + + A dedicated daemon process ovn-ic, OVN interconnection controller, in + each AZ will consume this data and populate corresponding logical + switches to their own northbound databases for each AZ, so that logical + routers can be connected to the transit switch by creating patch port + pairs in their northbound databases. Any router ports connected to the + transit switches are considered interconnection ports, which will be + exchanged between AZs. + + Physically, when workloads from different AZs communicate, packets need + to go through multiple hops: source chassis, source gateway, destinaā€ + tion gateway and destination chassis. All these hops are connected + through tunnels so that the packets never leave overlay networks. A + distributed gateway port is required to connect the logical router to a + transit switch, with a gateway chassis specified, so that the traffic + can be forwarded through the gateway chassis. + + A global OVN Interconnection Southbound database is introduced for exā€ + changing control plane information between the AZs. The data in this + database is populated and consumed by the ovn-ic, of each AZ. The main + information in this database includes: + + ā€¢ Datapath bindings for transit switches, which mainly conā€ + tains the tunnel keys generated for each transit switch. + Separate key ranges are reserved for transit switches so + that they will never conflict with any tunnel keys loā€ + cally assigned for datapaths within each AZ. + + ā€¢ Availability zones, which are registered by ovn-ic from + each AZ. + + ā€¢ Gateways. Each AZ specifies chassises that are supposed + to work as interconnection gateways, and the ovn-ic will + populate this information to the interconnection southā€ + bound DB. The ovn-ic from all the other AZs will learn + the gateways and populate to their own southbound DB as a + chassis. + + ā€¢ Port bindings for logical switch ports created on the + transit switch. Each AZ maintains their logical router to + transit switch connections independently, but ovn-ic auā€ + tomatically populates local port bindings on transit + switches to the global interconnection southbound DB, and + learns remote port bindings from other AZs back to its + own northbound and southbound DBs, so that logical flows + can be produced and then translated to OVS flows locally, + which finally enables data plane communication. + + ā€¢ Routes that are advertised between different AZs. If enā€ + abled, routes are automatically exchanged by ovn-ic. Both + static routes and directly connected subnets are adverā€ + tised. Options in options column of the NB_Global table + of OVN_NB database control the behavior of route adverā€ + tisement, such as enable/disable the advertising/learning + routes, whether default routes are advertised/learned, + and blacklisted CIDRs. See ovn-nb(5) for more details. + + The tunnel keys for transit switch datapaths and related port bindings + must be agreed across all AZs. This is ensured by generating and storā€ + ing the keys in the global interconnection southbound database. Any + ovn-ic from any AZ can allocate the key, but race conditions are solved + by enforcing unique index for the column in the database. + + Once each AZā€™s NB and SB databases are populated with interconnection + switches and ports, and agreed upon the tunnel keys, data plane commuā€ + nication between the AZs are established. + + When VXLAN tunneling is enabled in an OVN cluster, due to the limited + range available for VNIs, Interconnection feature is not supported. + + A day in the life of a packet crossing AZs + + 1. An IP packet is sent out from a VIF on a hypervisor (HV1) of + AZ1, with destination IP belonging to a VIF in AZ2. + + 2. In HV1ā€™s OVS flow tables, the packet goes through logical + switch and logical router pipelines, and in a logical router + pipeline, the routing stage finds out the next hop for the + destination IP, which belongs to a remote logical router + port in AZ2, and the output port, which is a chassis-rediā€ + rect port located on an interconnection gateway (GW1 in + AZ1), so HV1 sends the packet to GW1 through tunnel. + + 3. On GW1, it continues with the logical router pipe line and + switches to the transit switchā€™s pipeline through the peer + port of the chassis redirect port. In the transit switchā€™s + pipeline it outputs to the remote logical port which is loā€ + cated on a gateway (GW2) in AZ2, so the GW1 sends the packet + to GW2 in tunnel. + + 4. On GW2, it continues with the transit switch pipeline and + switches to the logical router pipeline through the peer + port, which is a chassis redirect port that is located on + GW2. The logical router pipeline then forwards the packet to + relevant logical pipelines according to the destination IP + address, and figures out the MAC and location of the destiā€ + nation VIF port - a hypervisor (HV2). The GW2 then sends the + packet to HV2 in tunnel. + + 5. On HV2, the packet is delivered to the final destination VIF + port by the logical switch egress pipeline, just the same + way as for intra-AZ communications. + + Native OVN services for external logical ports + To support OVN native services (like DHCP/IPv6 RA/DNS lookup) to the + cloud resources which are external, OVN supports external logical + ports. + + 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-controller do not + bind these ports and cannot serve the native services. + + ā€¢ When CMS supports provisioning baremetal servers. + + OVN will provide the native services if CMS has done the below configuā€ + ration in the OVN Northbound Database. + + ā€¢ A row is created in Logical_Switch_Port, configuring the + addresses column and setting the type to external. + + ā€¢ ha_chassis_group column is configured. + + ā€¢ The HA chassis which belongs to the HA chassis group has + the ovn-bridge-mappings configured and has proper L2 conā€ + nectivity so that it can receive the DHCP and other reā€ + lated request packets from these external resources. + + ā€¢ The Logical_Switch of this port has a localnet port. + + ā€¢ Native OVN services are enabled by configuring the DHCP + and other options like the way it is done for the normal + logical ports. + + 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 different chassis provide the native services. For exā€ + ample when supporting native DHCPv4 service, DHCPv4 server mac (configā€ + ured 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. + +SECURITY + Role-Based Access Controls for the Southbound DB + In order to provide additional security against the possibility of an + OVN chassis becoming compromised in such a way as to allow rogue softā€ + ware to make arbitrary modifications to the southbound database state + and thus disrupt the OVN network, role-based access controls (see + ovsdb-server(1) for additional details) are provided for the southbound + database. + + The implementation of role-based access controls (RBAC) requires the + addition of two tables to an OVSDB schema: the RBAC_Role table, which + is indexed by role name and maps the the names of the various tables + that may be modifiable for a given role to individual rows in a permisā€ + sions table containing detailed permission information for that role, + and the permission table itself which consists of rows containing the + following information: + + Table Name + The name of the associated table. This column exists priā€ + marily as an aid for humans reading the contents of this + table. + + Auth Criteria + A set of strings containing the names of columns (or colā€ + umn:key pairs for columns containing string:string maps). + The contents of at least one of the columns or column:key + values in a row to be modified, inserted, or deleted must + be equal to the ID of the client attempting to act on the + row in order for the authorization check to pass. If the + authorization criteria is empty, authorization checking + is disabled and all clients for the role will be treated + as authorized. + + Insert/Delete + Row insertion/deletion permission; boolean value indicatā€ + ing whether insertion and deletion of rows is allowed for + the associated table. If true, insertion and deletion of + rows is allowed for authorized clients. + + Updatable Columns + A set of strings containing the names of columns or colā€ + umn:key pairs that may be updated or mutated by authoā€ + rized clients. Modifications to columns within a row are + only permitted when the authorization check for the + client passes and all columns to be modified are included + in this set of modifiable columns. + + RBAC configuration for the OVN southbound database is maintained by + ovn-northd. With RBAC enabled, modifications are only permitted for the + Chassis, Encap, Port_Binding, and MAC_Binding tables, and are reā€ + stricted as follows: + + Chassis + Authorization: client ID must match the chassis name. + + Insert/Delete: authorized row insertion and deletion are + permitted. + + Update: The columns nb_cfg, external_ids, encaps, and + vtep_logical_switches may be modified when authorized. + + Encap Authorization: client ID must match the chassis name. + + Insert/Delete: row insertion and row deletion are permitā€ + ted. + + Update: The columns type, options, and ip can be modiā€ + fied. + + Port_Binding + Authorization: disabled (all clients are considered auā€ + thorized. A future enhancement may add columns (or keys + to external_ids) in order to control which chassis are + allowed to bind each port. + + Insert/Delete: row insertion/deletion are not permitted + (ovn-northd maintains rows in this table. + + Update: Only modifications to the chassis column are perā€ + mitted. + + MAC_Binding + Authorization: disabled (all clients are considered to be + authorized). + + Insert/Delete: row insertion/deletion are permitted. + + Update: The columns logical_port, ip, mac, and datapath + may be modified by ovn-controller. + + IGMP_Group + Authorization: disabled (all clients are considered to be + authorized). + + Insert/Delete: row insertion/deletion are permitted. + + Update: The columns address, chassis, datapath, and ports + may be modified by ovn-controller. + + Enabling RBAC for ovn-controller connections to the southbound database + requires the following steps: + + 1. Creating SSL certificates for each chassis with the certifiā€ + cate CN field set to the chassis name (e.g. for a chassis + with external-ids:system-id=chassis-1, via the command + "ovs-pki -u req+sign chassis-1 switch"). + + 2. Configuring each ovn-controller to use SSL when connecting + to the southbound database (e.g. via "ovs-vsctl set open . + external-ids:ovn-remote=ssl:x.x.x.x:6642"). + + 3. Configuring a southbound database SSL remote with "ovn-conā€ + troller" role (e.g. via "ovn-sbctl set-connection + role=ovn-controller pssl:6642"). + + Encrypt Tunnel Traffic with IPsec + OVN tunnel traffic goes through physical routers and switches. These + physical devices could be untrusted (devices in public network) or + might be compromised. Enabling encryption to the tunnel traffic can + prevent the traffic data from being monitored and manipulated. + + The tunnel traffic is encrypted with IPsec. The CMS sets the ipsec colā€ + umn in the northbound NB_Global table to enable or disable IPsec encryā€ + tion. If ipsec is true, all OVN tunnels will be encrypted. If ipsec is + false, no OVN tunnels will be encrypted. + + When CMS updates the ipsec column in the northbound NB_Global table, + ovn-northd copies the value to the ipsec column in the southbound + SB_Global table. ovn-controller in each chassis monitors the southbound + database and sets the options of the OVS tunnel interface accordingly. + OVS tunnel interface options are monitored by the ovs-monitor-ipsec + daemon which configures IKE daemon to set up IPsec connections. + + Chassis authenticates each other by using certificate. The authenticaā€ + tion succeeds if the other end in tunnel presents a certificate signed + by a trusted CA and the common name (CN) matches the expected chassis + name. The SSL certificates used in role-based access controls (RBAC) + can be used in IPsec. Or use ovs-pki to create different certificates. + The certificate is required to be x.509 version 3, and with CN field + and subjectAltName field being set to the chassis name. + + The CA certificate, chassis certificate and private key are required to + be installed in each chassis before enabling IPsec. Please see + ovs-vswitchd.conf.db(5) for setting up CA based IPsec authentication. + +DESIGN DECISIONS + Tunnel Encapsulations + In general, OVN annotates logical network packets that it sends from + one hypervisor to another with the following three pieces of metadata, + which are encoded in an encapsulation-specific fashion: + + ā€¢ 24-bit logical datapath identifier, from the tunnel_key + column in the OVN Southbound Datapath_Binding table. + + ā€¢ 15-bit logical ingress port identifier. ID 0 is reserved + for internal use within OVN. IDs 1 through 32767, incluā€ + sive, may be assigned to logical ports (see the tunā€ā€ + nel_key column in the OVN Southbound Port_Binding table). + + ā€¢ 16-bit logical egress port identifier. IDs 0 through + 32767 have the same meaning as for logical ingress ports. + IDs 32768 through 65535, inclusive, may be assigned to + logical multicast groups (see the tunnel_key column in + the OVN Southbound Multicast_Group table). + + When VXLAN is enabled on any hypervisor in a cluster, datapath and + egress port identifier ranges are reduced to 12-bits. This is done beā€ + cause only STT and Geneve provide the large space for metadata (over 32 + bits per packet). To accommodate for VXLAN, 24 bits available are split + as follows: + + ā€¢ 12-bit logical datapath identifier, derived from the tunā€ā€ + nel_key column in the OVN Southbound Datapath_Binding taā€ + ble. + + ā€¢ 12-bit logical egress port identifier. IDs 0 through 2047 + are used for unicast output ports. IDs 2048 through 4095, + inclusive, may be assigned to logical multicast groups + (see the tunnel_key column in the OVN Southbound Multiā€ā€ + cast_Group table). For multicast group tunnel keys, a + special mapping scheme is used to internally transform + from internal OVN 16-bit keys to 12-bit values before + sending packets through a VXLAN tunnel, and back from + 12-bit tunnel keys to 16-bit values when receiving packā€ + ets from a VXLAN tunnel. + + ā€¢ No logical ingress port identifier. + + The limited space available for metadata when VXLAN tunnels are enabled + in a cluster put the following functional limitations onto features + available to users: + + ā€¢ The maximum number of networks is reduced to 4096. + + ā€¢ The maximum number of ports per network is reduced to + 2048. + + ā€¢ ACLs matching against logical ingress port identifiers + are not supported. + + ā€¢ OVN interconnection feature is not supported. + + In addition to functional limitations described above, the following + should be considered before enabling it in your cluster: + + ā€¢ STT and Geneve use randomized UDP or TCP source ports + that allows efficient distribution among multiple paths + in environments that use ECMP in their underlay. + + ā€¢ NICs are available to offload STT and Geneve encapsulaā€ + tion and decapsulation. + + Due to its flexibility, the preferred encapsulation between hypervisors + is Geneve. For Geneve encapsulation, OVN transmits the logical datapath + identifier in the Geneve VNI. OVN transmits the logical ingress and + logical egress ports in a TLV with class 0x0102, type 0x80, and a + 32-bit value encoded as follows, from MSB to LSB: + + 1 15 16 + +---+------------+-----------+ + |rsv|ingress port|egress port| + +---+------------+-----------+ + 0 + + + Environments whose NICs lack Geneve offload may prefer STT encapsulaā€ + tion for performance reasons. For STT encapsulation, OVN encodes all + three pieces of logical metadata in the STT 64-bit tunnel ID as folā€ + lows, from MSB to LSB: + + 9 15 16 24 + +--------+------------+-----------+--------+ + |reserved|ingress port|egress port|datapath| + +--------+------------+-----------+--------+ + 0 + + + For connecting to gateways, in addition to Geneve and STT, OVN supports + VXLAN, because only VXLAN support is common on top-of-rack (ToR) + switches. Currently, gateways have a feature set that matches the capaā€ + bilities as defined by the VTEP schema, so fewer bits of metadata are + necessary. In the future, gateways that do not support encapsulations + with large amounts of metadata may continue to have a reduced feature + set. + +OVN 23.06.3 OVN Architecture ovn-architecture(7) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-controller-vtep.8 b/src/static/support/dist-docs-branch-23.06/ovn-controller-vtep.8 new file mode 100644 index 00000000..23825e29 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-controller-vtep.8 @@ -0,0 +1,110 @@ +'\" p +.\" -*- nroff -*- +.TH "ovn-controller-vtep" 8 "ovn-controller-vtep" "OVN 23\[char46]06\[char46]3" "OVN Manual" +.fp 5 L CR \\" Make fixed-width font available as \\fL. +.de TQ +. br +. ns +. TP "\\$1" +.. +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +.de SU +. PP +. I "\\$1" +.. +.PP +.SH "NAME" +.PP +.PP +ovn-controller-vtep \- Open Virtual Network local controller for vtep enabled physical switches\[char46] +.SH "SYNOPSIS" +.PP +\fBovn\-controller\-vtep\fR [\fIoptions\fR] [\fI\-\-vtep-db=vtep-database\fR] [\fI\-\-ovnsb-db=ovnsb-database\fR] +.SH "DESCRIPTION" +.PP +.PP +\fBovn\-controller\-vtep\fR is the local controller daemon in OVN, the Open Virtual Network, for VTEP enabled physical switches\[char46] It connects up to the OVN Southbound database (see \fBovn\-sb\fR(5)) over the OVSDB protocol, and down to the VTEP database (see \fBvtep\fR(5)) over the OVSDB protocol\[char46] +.SS "PKI Options" +.PP +.PP +PKI configuration is required in order to use SSL for the connections to the VTEP and Southbound databases\[char46] +.RS +.TP +\fB\-p\fR \fIprivkey\[char46]pem\fR +.TQ .5in +\fB\-\-private\-key=\fR\fIprivkey\[char46]pem\fR +Specifies a PEM file containing the private key used as identity for outgoing SSL connections\[char46] +.TP +\fB\-c\fR \fIcert\[char46]pem\fR +.TQ .5in +\fB\-\-certificate=\fR\fIcert\[char46]pem\fR +Specifies a PEM file containing a certificate that certifies the private key specified on \fB\-p\fR or \fB\-\-private\-key\fR to be trustworthy\[char46] The certificate must be signed by the certificate authority (CA) that the peer in SSL connections will use to verify it\[char46] +.TP +\fB\-C\fR \fIcacert\[char46]pem\fR +.TQ .5in +\fB\-\-ca\-cert=\fR\fIcacert\[char46]pem\fR +Specifies a PEM file containing the CA certificate for verifying certificates presented to this program by SSL peers\[char46] (This may be the same certificate that SSL peers use to verify the certificate specified on \fB\-c\fR or \fB\-\-certificate\fR, or it may be a different one, depending on the PKI design in use\[char46]) +.TP +\fB\-C none\fR +.TQ .5in +\fB\-\-ca\-cert=none\fR +Disables verification of certificates presented by SSL peers\[char46] This introduces a security risk, because it means that certificates cannot be verified to be those of known trusted hosts\[char46] +.RE +.RS +.TP +\fB\-\-bootstrap\-ca\-cert=\fR\fIcacert\[char46]pem\fR +When \fIcacert\[char46]pem\fR exists, this option has the same effect as \fB\-C\fR or \fB\-\-ca\-cert\fR\[char46] If it does not exist, then the executable will attempt to obtain the CA certificate from the SSL peer on its first SSL connection and save it to the named PEM file\[char46] 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\[char46] +.IP +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\[char46] +.IP +This option is only useful if the SSL peer sends its CA certificate as part of the SSL certificate chain\[char46] The SSL protocol does not require the server to send the CA certificate\[char46] +.IP +This option is mutually exclusive with \fB\-C\fR and \fB\-\-ca\-cert\fR\[char46] +.RE +.RS +.TP +\fB\-\-peer\-ca\-cert=\fR\fIpeer-cacert\[char46]pem\fR +Specifies a PEM file that contains one or more additional certificates to send to SSL peers\[char46] \fIpeer-cacert\[char46]pem\fR should be the CA certificate used to sign the program\(cqs own certificate, that is, the certificate specified on \fB\-c\fR or \fB\-\-certificate\fR\[char46] If the program\(cqs certificate is self-signed, then \fB\-\-certificate\fR and \fB\-\-peer\-ca\-cert\fR should specify the same file\[char46] +.IP +This option is not useful in normal operation, because the SSL peer must already have the CA certificate for the peer to have any confidence in the program\(cqs identity\[char46] However, this offers a way for a new installation to bootstrap the CA certificate on its first SSL connection\[char46] +.RE +.SH "CONFIGURATION" +.PP +.PP +\fBovn\-controller\-vtep\fR retrieves its configuration information from both the ovnsb and the vtep database\[char46] If the database locations are not given from command line, the default is the \fBdb\[char46]sock\fR in local OVSDB\(cqs \(cqrun\(cq directory\[char46] The database location must take one of the following forms: +.RS +.IP \(bu +\fBssl:\fIhost\fB:\fIport\fB\fR +.IP +The specified SSL \fIport\fR on the give \fIhost\fR, which can either be a DNS name (if built with unbound library) or an IP address (IPv4 or IPv6)\[char46] If \fIhost\fR is an IPv6 address, then wrap \fIhost\fR with square brackets, e\[char46]g\[char46]: \fBssl:[::1]:6640\fR\[char46] The \fB\-\-private\-key\fR, \fB\-\-certificate\fR and either of \fB\-\-ca\-cert\fR or \fB\-\-bootstrap\-ca\-cert\fR options are mandatory when this form is used\[char46] +.IP \(bu +\fBtcp:\fIhost\fB:\fIport\fB\fR +.IP +Connect to the given TCP \fIport\fR on \fIhost\fR, where \fIhost\fR can be a DNS name (if built with unbound library) or IP address (IPv4 or IPv6)\[char46] If \fIhost\fR is an IPv6 address, then wrap \fIhost\fR with square brackets, e\[char46]g\[char46]: \fBtcp:[::1]:6640\fR\[char46] +.IP \(bu +\fBunix:\fIfile\fB\fR +.IP +On POSIX, connect to the Unix domain server socket named \fIfile\fR\[char46] +.IP +On Windows, connect to a localhost TCP port whose value is written in \fIfile\fR\[char46] +.RE +.PP +.PP +\fBovn\-controller\-vtep\fR assumes it gets configuration information from the following keys in the \fBGlobal\fR table of the connected \fBhardware_vtep\fR database: +.PP +.PP +.RS +.TP +\fBother_config:ovn\-match\-northd\-version\fR +The boolean flag indicates if \fBovn\-controller\-vtep\fR needs to check \fBovn\-northd\fR version\[char46] If this flag is set to true and the \fBovn\-northd\(cqs\fR version (reported in the Southbound database) doesn\(cqt match with the \fBovn\-controller\-vtep\(cqs\fR internal version, then it will stop processing the southbound and connected \fBhardware_vtep\fR database changes\[char46] The default value is considered false if this option is not defined\[char46] +.TP +\fBother_config:ovn\-remote\-probe\-interval\fR +The inactivity probe interval of the connection to the OVN Southbound database, 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] +.RE diff --git a/src/static/support/dist-docs-branch-23.06/ovn-controller-vtep.8.html b/src/static/support/dist-docs-branch-23.06/ovn-controller-vtep.8.html new file mode 100644 index 00000000..f93667ce --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-controller-vtep.8.html @@ -0,0 +1,142 @@ +
+ovn-controller-vtep(8)            OVN Manual            ovn-controller-vtep(8)
+
+NAME
+       ovn-controller-vtep  -  Open  Virtual Network local controller for vtep
+       enabled physical switches.
+
+SYNOPSIS
+       ovn-controller-vtep   [options]   [--vtep-db=vtep-database]   [--ovnsb-
+       db=ovnsb-database]
+
+DESCRIPTION
+       ovn-controller-vtep  is  the  local  controller daemon in OVN, the Open
+       Virtual Network, for VTEP enabled physical switches. It connects up  to
+       the  OVN  Southbound  database (see ovn-sb(5)) over the OVSDB protocol,
+       and down to the VTEP database (see vtep(5)) over the OVSDB protocol.
+
+   PKI Options
+       PKI configuration is required in order to use SSL for  the  connections
+       to the VTEP and Southbound databases.
+
+              -p privkey.pem
+              --private-key=privkey.pem
+                   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ā€
+                   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
+                   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
+                   verify the certificate specified on -c or --certificate, or
+                   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
+                   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ā€
+                     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.
+
+                     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
+                     certificate as part of the SSL certificate chain. The SSL
+                     protocol does not require the server to send the CA  cerā€
+                     tificate.
+
+                     This option is mutually exclusive with -C and --ca-cert.
+
+              --peer-ca-cert=peer-cacert.pem
+                     Specifies a PEM file that contains one or more additional
+                     certificates to send to SSL peers. peer-cacert.pem should
+                     be the CA certificate used to sign the programā€™s own cerā€
+                     tificate,  that  is,  the  certificate specified on -c or
+                     --certificate. If  the  programā€™s  certificate  is  self-
+                     signed,  then  --certificate  and  --peer-ca-cert  should
+                     specify the same file.
+
+                     This option is not useful in  normal  operation,  because
+                     the SSL peer must already have the CA certificate for the
+                     peer  to  have  any confidence in the programā€™s identity.
+                     However, this offers a way  for  a  new  installation  to
+                     bootstrap the CA certificate on its first SSL connection.
+
+CONFIGURATION
+       ovn-controller-vtep  retrieves  its configuration information from both
+       the ovnsb and the vtep database. If  the  database  locations  are  not
+       given  from  command  line, the default is the db.sock in local OVSDBā€™s
+       ā€™runā€™ directory. The database location must take one of  the  following
+       forms:
+
+              ā€¢      ssl:host:port
+
+                     The specified SSL port on the give 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,  then
+                     wrap host with square brackets, e.g.: ssl:[::1]:6640. The
+                     --private-key,  --certificate  and either of --ca-cert or
+                     --bootstrap-ca-cert options are mandatory when this  form
+                     is used.
+
+              ā€¢      tcp:host:port
+
+                     Connect  to the given TCP port on host, where host can be
+                     a DNS name (if built with unbound library) or IP  address
+                     (IPv4  or  IPv6).  If  host is an IPv6 address, then wrap
+                     host with square brackets, e.g.: tcp:[::1]:6640.
+
+              ā€¢      unix:file
+
+                     On POSIX, connect to the Unix domain server socket  named
+                     file.
+
+                     On  Windows,  connect to a localhost TCP port whose value
+                     is written in file.
+
+       ovn-controller-vtep assumes it gets configuration information from  the
+       following keys in the Global table of the connected hardware_vtep dataā€
+       base:
+
+              other_config:ovn-match-northd-version
+                     The  boolean  flag indicates if ovn-controller-vtep needs
+                     to check ovn-northd version. If this flag is set to  true
+                     and  the ovn-northdā€™ā€™s version (reported in the Southbound
+                     database) doesnā€™t match  with  the  ovn-controller-vtepā€™ā€™s
+                     internal version, then it will stop processing the southā€
+                     bound  and  connected hardware_vtep database changes. The
+                     default value is considered false if this option  is  not
+                     defined.
+
+              other_config:ovn-remote-probe-interval
+                     The  inactivity  probe  interval of the connection to the
+                     OVN Southbound database, in milliseconds. If the value is
+                     zero, it disables the connection keepalive feature.
+
+                     If the value is nonzero, then it  will  be  forced  to  a
+                     value of at least 1000 ms.
+
+OVN 23.06.3                   ovn-controller-vtep       ovn-controller-vtep(8)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-controller-vtep.8.pdf b/src/static/support/dist-docs-branch-23.06/ovn-controller-vtep.8.pdf new file mode 100644 index 00000000..f8c42016 Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-controller-vtep.8.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-controller-vtep.8.txt b/src/static/support/dist-docs-branch-23.06/ovn-controller-vtep.8.txt new file mode 100644 index 00000000..163d80bb --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-controller-vtep.8.txt @@ -0,0 +1,140 @@ +ovn-controller-vtep(8) OVN Manual ovn-controller-vtep(8) + +NAME + ovn-controller-vtep - Open Virtual Network local controller for vtep + enabled physical switches. + +SYNOPSIS + ovn-controller-vtep [options] [--vtep-db=vtep-database] [--ovnsb- + db=ovnsb-database] + +DESCRIPTION + ovn-controller-vtep is the local controller daemon in OVN, the Open + Virtual Network, for VTEP enabled physical switches. It connects up to + the OVN Southbound database (see ovn-sb(5)) over the OVSDB protocol, + and down to the VTEP database (see vtep(5)) over the OVSDB protocol. + + PKI Options + PKI configuration is required in order to use SSL for the connections + to the VTEP and Southbound databases. + + -p privkey.pem + --private-key=privkey.pem + 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ā€ + 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 + 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 + verify the certificate specified on -c or --certificate, or + 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 + 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ā€ + 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. + + 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 + certificate as part of the SSL certificate chain. The SSL + protocol does not require the server to send the CA cerā€ + tificate. + + This option is mutually exclusive with -C and --ca-cert. + + --peer-ca-cert=peer-cacert.pem + Specifies a PEM file that contains one or more additional + certificates to send to SSL peers. peer-cacert.pem should + be the CA certificate used to sign the programā€™s own cerā€ + tificate, that is, the certificate specified on -c or + --certificate. If the programā€™s certificate is self- + signed, then --certificate and --peer-ca-cert should + specify the same file. + + This option is not useful in normal operation, because + the SSL peer must already have the CA certificate for the + peer to have any confidence in the programā€™s identity. + However, this offers a way for a new installation to + bootstrap the CA certificate on its first SSL connection. + +CONFIGURATION + ovn-controller-vtep retrieves its configuration information from both + the ovnsb and the vtep database. If the database locations are not + given from command line, the default is the db.sock in local OVSDBā€™s + ā€™runā€™ directory. The database location must take one of the following + forms: + + ā€¢ ssl:host:port + + The specified SSL port on the give 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, then + wrap host with square brackets, e.g.: ssl:[::1]:6640. The + --private-key, --certificate and either of --ca-cert or + --bootstrap-ca-cert options are mandatory when this form + is used. + + ā€¢ tcp:host:port + + Connect to the given TCP port on host, where host can be + a DNS name (if built with unbound library) or IP address + (IPv4 or IPv6). If host is an IPv6 address, then wrap + host with square brackets, e.g.: tcp:[::1]:6640. + + ā€¢ unix:file + + On POSIX, connect to the Unix domain server socket named + file. + + On Windows, connect to a localhost TCP port whose value + is written in file. + + ovn-controller-vtep assumes it gets configuration information from the + following keys in the Global table of the connected hardware_vtep dataā€ + base: + + other_config:ovn-match-northd-version + The boolean flag indicates if ovn-controller-vtep needs + to check ovn-northd version. If this flag is set to true + and the ovn-northdā€ā€™s version (reported in the Southbound + database) doesnā€™t match with the ovn-controller-vtepā€ā€™s + internal version, then it will stop processing the southā€ + bound and connected hardware_vtep database changes. The + default value is considered false if this option is not + defined. + + other_config:ovn-remote-probe-interval + The inactivity probe interval of the connection to the + OVN Southbound database, in milliseconds. If the value is + zero, it disables the connection keepalive feature. + + If the value is nonzero, then it will be forced to a + value of at least 1000 ms. + +OVN 23.06.3 ovn-controller-vtep ovn-controller-vtep(8) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-controller.8 b/src/static/support/dist-docs-branch-23.06/ovn-controller.8 new file mode 100644 index 00000000..261a5258 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-controller.8 @@ -0,0 +1,439 @@ +'\" p +.\" -*- nroff -*- +.TH "ovn-controller" 8 "ovn-controller" "OVN 23\[char46]06\[char46]3" "OVN Manual" +.fp 5 L CR \\" Make fixed-width font available as \\fL. +.de TQ +. br +. ns +. TP "\\$1" +.. +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +.de SU +. PP +. I "\\$1" +.. +.PP +.SH "NAME" +.PP +.PP +ovn-controller \- Open Virtual Network local controller +.SH "SYNOPSIS" +.PP +\fBovn\-controller\fR [\fIoptions\fR] [\fIovs-database\fR] +.SH "DESCRIPTION" +.PP +.PP +\fBovn\-controller\fR is the local controller daemon for OVN, the Open Virtual Network\[char46] It connects up to the OVN Southbound database (see \fBovn\-sb\fR(5)) over the OVSDB protocol, and down to the Open vSwitch database (see \fBovs\-vswitchd\[char46]conf\[char46]db\fR(5)) over the OVSDB protocol and to \fBovs\-vswitchd\fR(8) via OpenFlow\[char46] Each hypervisor and software gateway in an OVN deployment runs its own independent copy of \fBovn\-controller\fR; thus, \fBovn\-controller\fR\(cqs downward connections are machine-local and do not run over a physical network\[char46] +.SH "ACL LOGGING" +.PP +.PP +ACL log messages are logged through \fBovn\-controller\fR\(cqs logging mechanism\[char46] ACL log entries have the module \fBacl_log\fR at log level \fBinfo\fR\[char46] Configuring logging is described below in the \fBLogging Options\fR section\[char46] +.SH "OPTIONS" +.SS "Daemon Options" +.TP +\fB\-\-pidfile\fR[\fB=\fR\fIpidfile\fR] +Causes a file (by default, \fB\fIprogram\fB\[char46]pid\fR) to be created indicating the PID of the running process\[char46] If the \fIpidfile\fR argument is not specified, or if it does not begin with \fB/\fR, then it is created in \fB\fR\[char46] +.IP +If \fB\-\-pidfile\fR is not specified, no pidfile is created\[char46] +.TP +\fB\-\-overwrite\-pidfile\fR +By default, when \fB\-\-pidfile\fR is specified and the specified pidfile already exists and is locked by a running process, the daemon refuses to start\[char46] Specify \fB\-\-overwrite\-pidfile\fR to cause it to instead overwrite the pidfile\[char46] +.IP +When \fB\-\-pidfile\fR is not specified, this option has no effect\[char46] +.TP +\fB\-\-detach\fR +Runs this program as a background process\[char46] 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 \fB\-\-no\-chdir\fR is specified)\[char46] After the child completes its initialization, the parent exits\[char46] +.TP +\fB\-\-monitor\fR +Creates an additional process to monitor this program\[char46] If it dies due to a signal that indicates a programming error (\fBSIGABRT\fR, \fBSIGALRM\fR, \fBSIGBUS\fR, \fBSIGFPE\fR, \fBSIGILL\fR, \fBSIGPIPE\fR, \fBSIGSEGV\fR, \fBSIGXCPU\fR, or \fBSIGXFSZ\fR) then the monitor process starts a new copy of it\[char46] If the daemon dies or exits for another reason, the monitor process exits\[char46] +.IP +This option is normally used with \fB\-\-detach\fR, but it also functions without it\[char46] +.TP +\fB\-\-no\-chdir\fR +By default, when \fB\-\-detach\fR is specified, the daemon changes its current working directory to the root directory after it detaches\[char46] Otherwise, invoking the daemon from a carelessly chosen directory would prevent the administrator from unmounting the file system that holds that directory\[char46] +.IP +Specifying \fB\-\-no\-chdir\fR suppresses this behavior, preventing the daemon from changing its current working directory\[char46] 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\[char46] +.IP +This option has no effect when \fB\-\-detach\fR is not specified\[char46] +.TP +\fB\-\-no\-self\-confinement\fR +By default this daemon will try to self-confine itself to work with files under well-known directories determined at build time\[char46] 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\[char46] Note that in contrast to other access control implementations that are typically enforced from kernel-space (e\[char46]g\[char46] 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 additional layer of security\[char46] +.TP +\fB\-\-user=\fR\fIuser\fR\fB:\fR\fIgroup\fR +Causes this program to run as a different user specified in \fIuser\fR\fB:\fR\fIgroup\fR, thus dropping most of the root privileges\[char46] Short forms \fIuser\fR and \fB:\fR\fIgroup\fR are also allowed, with current user or group assumed, respectively\[char46] Only daemons started by the root user accepts this argument\[char46] +.IP +On Linux, daemons will be granted \fBCAP_IPC_LOCK\fR and \fBCAP_NET_BIND_SERVICES\fR before dropping root privileges\[char46] Daemons that interact with a datapath, such as \fBovs\-vswitchd\fR, will be granted three additional capabilities, namely \fBCAP_NET_ADMIN\fR, \fBCAP_NET_BROADCAST\fR and \fBCAP_NET_RAW\fR\[char46] The capability change will apply even if the new user is root\[char46] +.IP +On Windows, this option is not currently supported\[char46] For security reasons, specifying this option will cause the daemon process not to start\[char46] +.SS "Logging Options" +.TP +\fB\-v\fR[\fIspec\fR] +.TQ .5in +\fB\-\-verbose=\fR[\fIspec\fR] +Sets logging levels\[char46] Without any \fIspec\fR, sets the log level for every module and destination to \fBdbg\fR\[char46] Otherwise, \fIspec\fR is a list of words separated by spaces or commas or colons, up to one from each category below: +.RS +.IP \(bu +A valid module name, as displayed by the \fBvlog/list\fR command on \fBovs\-appctl\fR(8), limits the log level change to the specified module\[char46] +.IP \(bu +\fBsyslog\fR, \fBconsole\fR, or \fBfile\fR, to limit the log level change to only to the system log, to the console, or to a file, respectively\[char46] (If \fB\-\-detach\fR is specified, the daemon closes its standard file descriptors, so logging to the console will have no effect\[char46]) +.IP +On Windows platform, \fBsyslog\fR is accepted as a word and is only useful along with the \fB\-\-syslog\-target\fR option (the word has no effect otherwise)\[char46] +.IP \(bu +\fBoff\fR, \fBemer\fR, \fBerr\fR, \fBwarn\fR, \fBinfo\fR, or \fBdbg\fR, to control the log level\[char46] Messages of the given severity or higher will be logged, and messages of lower severity will be filtered out\[char46] \fBoff\fR filters out all messages\[char46] See \fBovs\-appctl\fR(8) for a definition of each log level\[char46] +.RE +.IP +Case is not significant within \fIspec\fR\[char46] +.IP +Regardless of the log levels set for \fBfile\fR, logging to a file will not take place unless \fB\-\-log\-file\fR is also specified (see below)\[char46] +.IP +For compatibility with older versions of OVS, \fBany\fR is accepted as a word but has no effect\[char46] +.TP +\fB\-v\fR +.TQ .5in +\fB\-\-verbose\fR +Sets the maximum logging verbosity level, equivalent to \fB\-\-verbose=dbg\fR\[char46] +.TP +\fB\-vPATTERN:\fR\fIdestination\fR\fB:\fR\fIpattern\fR +.TQ .5in +\fB\-\-verbose=PATTERN:\fR\fIdestination\fR\fB:\fR\fIpattern\fR +Sets the log pattern for \fIdestination\fR to \fIpattern\fR\[char46] Refer to \fBovs\-appctl\fR(8) for a description of the valid syntax for \fIpattern\fR\[char46] +.TP +\fB\-vFACILITY:\fR\fIfacility\fR +.TQ .5in +\fB\-\-verbose=FACILITY:\fR\fIfacility\fR +Sets the RFC5424 facility of the log message\[char46] \fIfacility\fR can be one of \fBkern\fR, \fBuser\fR, \fBmail\fR, \fBdaemon\fR, \fBauth\fR, \fBsyslog\fR, \fBlpr\fR, \fBnews\fR, \fBuucp\fR, \fBclock\fR, \fBftp\fR, \fBntp\fR, \fBaudit\fR, \fBalert\fR, \fBclock2\fR, \fBlocal0\fR, \fBlocal1\fR, \fBlocal2\fR, \fBlocal3\fR, \fBlocal4\fR, \fBlocal5\fR, \fBlocal6\fR or \fBlocal7\fR\[char46] If this option is not specified, \fBdaemon\fR is used as the default for the local system syslog and \fBlocal0\fR is used while sending a message to the target provided via the \fB\-\-syslog\-target\fR option\[char46] +.TP +\fB\-\-log\-file\fR[\fB=\fR\fIfile\fR] +Enables logging to a file\[char46] If \fIfile\fR is specified, then it is used as the exact name for the log file\[char46] The default log file name used if \fIfile\fR is omitted is \fB/usr/local/var/log/ovn/\fIprogram\fB\[char46]log\fR\[char46] +.TP +\fB\-\-syslog\-target=\fR\fIhost\fR\fB:\fR\fIport\fR +Send syslog messages to UDP \fIport\fR on \fIhost\fR, in addition to the system syslog\[char46] The \fIhost\fR must be a numerical IP address, not a hostname\[char46] +.TP +\fB\-\-syslog\-method=\fR\fImethod\fR +Specify \fImethod\fR as how syslog messages should be sent to syslog daemon\[char46] The following forms are supported: +.RS +.IP \(bu +\fBlibc\fR, to use the libc \fBsyslog()\fR function\[char46] Downside of using this options is that libc adds fixed prefix to every message before it is actually sent to the syslog daemon over \fB/dev/log\fR UNIX domain socket\[char46] +.IP \(bu +\fBunix:\fIfile\fB\fR, to use a UNIX domain socket directly\[char46] It is possible to specify arbitrary message format with this option\[char46] However, \fBrsyslogd 8\[char46]9\fR and older versions use hard coded parser function anyway that limits UNIX domain socket use\[char46] If you want to use arbitrary message format with older \fBrsyslogd\fR versions, then use UDP socket to localhost IP address instead\[char46] +.IP \(bu +\fBudp:\fIip\fB:\fIport\fB\fR, to use a UDP socket\[char46] With this method it is possible to use arbitrary message format also with older \fBrsyslogd\fR\[char46] When sending syslog messages over UDP socket extra precaution needs to be taken into account, for example, 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\[char46] +.IP \(bu +\fBnull\fR, to discard all messages logged to syslog\[char46] +.RE +.IP +The default is taken from the \fBOVS_SYSLOG_METHOD\fR environment variable; if it is unset, the default is \fBlibc\fR\[char46] +.SS "PKI Options" +.PP +.PP +PKI configuration is required in order to use SSL for the connections to the Northbound and Southbound databases\[char46] +.RS +.TP +\fB\-p\fR \fIprivkey\[char46]pem\fR +.TQ .5in +\fB\-\-private\-key=\fR\fIprivkey\[char46]pem\fR +Specifies a PEM file containing the private key used as identity for outgoing SSL connections\[char46] +.TP +\fB\-c\fR \fIcert\[char46]pem\fR +.TQ .5in +\fB\-\-certificate=\fR\fIcert\[char46]pem\fR +Specifies a PEM file containing a certificate that certifies the private key specified on \fB\-p\fR or \fB\-\-private\-key\fR to be trustworthy\[char46] The certificate must be signed by the certificate authority (CA) that the peer in SSL connections will use to verify it\[char46] +.TP +\fB\-C\fR \fIcacert\[char46]pem\fR +.TQ .5in +\fB\-\-ca\-cert=\fR\fIcacert\[char46]pem\fR +Specifies a PEM file containing the CA certificate for verifying certificates presented to this program by SSL peers\[char46] (This may be the same certificate that SSL peers use to verify the certificate specified on \fB\-c\fR or \fB\-\-certificate\fR, or it may be a different one, depending on the PKI design in use\[char46]) +.TP +\fB\-C none\fR +.TQ .5in +\fB\-\-ca\-cert=none\fR +Disables verification of certificates presented by SSL peers\[char46] This introduces a security risk, because it means that certificates cannot be verified to be those of known trusted hosts\[char46] +.RE +.RS +.TP +\fB\-\-bootstrap\-ca\-cert=\fR\fIcacert\[char46]pem\fR +When \fIcacert\[char46]pem\fR exists, this option has the same effect as \fB\-C\fR or \fB\-\-ca\-cert\fR\[char46] If it does not exist, then the executable will attempt to obtain the CA certificate from the SSL peer on its first SSL connection and save it to the named PEM file\[char46] 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\[char46] +.IP +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\[char46] +.IP +This option is only useful if the SSL peer sends its CA certificate as part of the SSL certificate chain\[char46] The SSL protocol does not require the server to send the CA certificate\[char46] +.IP +This option is mutually exclusive with \fB\-C\fR and \fB\-\-ca\-cert\fR\[char46] +.RE +.RS +.TP +\fB\-\-peer\-ca\-cert=\fR\fIpeer-cacert\[char46]pem\fR +Specifies a PEM file that contains one or more additional certificates to send to SSL peers\[char46] \fIpeer-cacert\[char46]pem\fR should be the CA certificate used to sign the program\(cqs own certificate, that is, the certificate specified on \fB\-c\fR or \fB\-\-certificate\fR\[char46] If the program\(cqs certificate is self-signed, then \fB\-\-certificate\fR and \fB\-\-peer\-ca\-cert\fR should specify the same file\[char46] +.IP +This option is not useful in normal operation, because the SSL peer must already have the CA certificate for the peer to have any confidence in the program\(cqs identity\[char46] However, this offers a way for a new installation to bootstrap the CA certificate on its first SSL connection\[char46] +.RE +.SS "Other Options" +.TP +\fB\-h\fR +.TQ .5in +\fB\-\-help\fR +Prints a brief help message to the console\[char46] +.TP +\fB\-V\fR +.TQ .5in +\fB\-\-version\fR +Prints version information to the console\[char46] +.SH "CONFIGURATION" +.PP +.PP +\fBovn\-controller\fR retrieves most of its configuration information from the local Open vSwitch\(cqs ovsdb-server instance\[char46] The default location is \fBdb\[char46]sock\fR in the local Open vSwitch\(cqs \(dqrun\(dq directory\[char46] It may be overridden by specifying the \fIovs-database\fR argument as an OVSDB active or passive connection method, as described in \fBovsdb\fR(7)\[char46] +.PP +.PP +\fBovn\-controller\fR assumes it gets configuration information from the following keys in the \fBOpen_vSwitch\fR table of the local OVS instance: +.RS +.TP +\fBexternal_ids:system\-id\fR +The chassis name to use in the Chassis table\[char46] Changing the \fBsystem\-id\fR while \fBovn\-controller\fR is running is not directly supported\[char46] Users have two options: either first gracefully stop \fBovn\-controller\fR or manually delete the stale \fBChassis\fR and \fBChassis_Private\fR records after changing the \fBsystem\-id\fR\[char46] Note that the chassis name can also be provided via the \fBsystem\-id\-override\fR file in the local OVN \(dqetc\(dq directory or via the \fB\-n\fR command-line option\[char46] The following precedence is used: first, the command-line option is read; if not present, the \fBsystem\-id\-override\fR file is read; if not present, then the name configured in the database is used\[char46] +.TP +\fBexternal_ids:hostname\fR +The hostname to use in the Chassis table\[char46] +.TP +\fBexternal_ids:ovn\-bridge\fR +The integration bridge to which logical ports are attached\[char46] The default is \fBbr\-int\fR\[char46] If this bridge does not exist when ovn-controller starts, it will be created automatically with the default configuration suggested in \fBovn\-architecture\fR(7)\[char46] When more than one controllers are running on the same host, \fBexternal_ids:ovn\-bridge\-CHASSIS_NAME\fR should be set for each of them, pointing to a unique bridge\[char46] This is required to avoid controllers stepping on each others\(cq feet\[char46] +.TP +\fBexternal_ids:ovn\-bridge\-datapath\-type\fR +This configuration is optional\[char46] If set, then the datapath type of the integration bridge will be set to the configured value\[char46] If this option is not set, then \fBovn\-controller\fR will not modify the existing \fBdatapath\-type\fR of the integration bridge\[char46] +.TP +\fBexternal_ids:ovn\-remote\fR +The OVN database that this system should connect to for its configuration, in one of the same forms documented above for the \fIovs-database\fR\[char46] +.TP +\fBexternal_ids:ovn\-monitor\-all\fR +A boolean value that tells if \fBovn\-controller\fR should monitor all records of tables in \fIovs-database\fR\[char46] If set to \fBfalse\fR, it will conditionally monitor the records that is needed in the current chassis\[char46] +.IP +It is more efficient to set it to \fBtrue\fR in use cases where the chassis would anyway need to monitor most of the records in \fIOVN Southbound\fR database, which would save the overhead of conditions processing, especially for server side\[char46] Typically, set it to \fBtrue\fR for environments that all workloads need to be reachable from each other\[char46] +.IP +Default value is \fIfalse\fR\[char46] +.TP +\fBexternal_ids:ovn\-remote\-probe\-interval\fR +The inactivity probe interval of the connection to the OVN database, 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] +.TP +\fBexternal_ids:ovn\-openflow\-probe\-interval\fR +The inactivity probe interval of the OpenFlow connection to the OpenvSwitch integration bridge, in seconds\[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 5s\[char46] +.TP +\fBexternal_ids:ovn\-encap\-type\fR +The encapsulation type that a chassis should use to connect to this node\[char46] Multiple encapsulation types may be specified with a comma-separated list\[char46] Each listed encapsulation type will be paired with \fBovn\-encap\-ip\fR\[char46] +.IP +Supported tunnel types for connecting hypervisors and gateways are \fBgeneve\fR, \fBvxlan\fR, and \fBstt\fR\[char46] +.IP +Due to the limited amount of metadata in \fBvxlan\fR, the capabilities and performance of connected gateways and hypervisors will be reduced versus other tunnel formats\[char46] +.TP +\fBexternal_ids:ovn\-encap\-ip\fR +The IP address that a chassis should use to connect to this node using encapsulation types specified by \fBexternal_ids:ovn\-encap\-type\fR\[char46] +.TP +\fBexternal_ids:ovn\-encap\-df_default\fR +indicates the DF flag handling of the encapulation\[char46] Set to \fBtrue\fR to set the DF flag for new data paths or \fBfalse\fR to clear the DF flag\[char46] +.TP +\fBexternal_ids:ovn\-bridge\-mappings\fR +A list of key-value pairs that map a physical network name to a local ovs bridge that provides connectivity to that network\[char46] An example value mapping two physical network names to two ovs bridges would be: \fBphysnet1:br\-eth0,physnet2:br\-eth1\fR\[char46] +.TP +\fBexternal_ids:ovn\-encap\-csum\fR +\fBovn\-encap\-csum\fR indicates that encapsulation checksums can be transmitted and received with reasonable performance\[char46] It is a hint to senders transmitting data to this chassis that they should use checksums to protect OVN metadata\[char46] Set to \fBtrue\fR to enable or \fBfalse\fR to disable\[char46] Depending on the capabilities of the network interface card, enabling encapsulation checksum may incur performance loss\[char46] In such cases, encapsulation checksums can be disabled\[char46] +.TP +\fBexternal_ids:ovn\-encap\-tos\fR +\fBovn\-encap\-tos\fR indicates the value to be applied to OVN tunnel interface\(cqs option:tos as specified in the Open_vSwitch database Interface table\[char46] Please refer to Open VSwitch Manual for details\[char46] +.TP +\fBexternal_ids:ovn\-cms\-options\fR +A list of options that will be consumed by the CMS Plugin and which specific to this particular chassis\[char46] An example would be: \fBcms_option1,cms_option2:foo\fR\[char46] +.TP +\fBexternal_ids:ovn\-transport\-zones\fR +The transport zone(s) that this chassis belongs to\[char46] Transport zones is a way to group different chassis so that tunnels are only formed between members of the same group(s)\[char46] Multiple transport zones may be specified with a comma-separated list\[char46] For example: tz1,tz2,tz3\[char46] +.IP +If not set, the Chassis will be considered part of a default transport zone\[char46] +.TP +\fBexternal_ids:ovn\-chassis\-mac\-mappings\fR +A list of key-value pairs that map a chassis specific mac to a physical network name\[char46] An example value mapping two chassis macs to two physical network names would be: \fBphysnet1:aa:bb:cc:dd:ee:ff,physnet2:a1:b2:c3:d4:e5:f6\fR\[char46] These are the macs that ovn-controller will replace a router port mac with, if packet is going from a distributed router port on vlan type logical switch\[char46] +.TP +\fBexternal_ids:ovn\-is\-interconn\fR +The boolean flag indicates if the chassis is used as an interconnection gateway\[char46] +.TP +\fBexternal_ids:ovn\-match\-northd\-version\fR +The boolean flag indicates if \fBovn\-controller\fR needs to check \fBovn\-northd\fR version\[char46] If this flag is set to true and the \fBovn\-northd\(cqs\fR version (reported in the Southbound database) doesn\(cqt match with the \fBovn\-controller\(cqs\fR internal version, then it will stop processing the southbound and local Open vSwitch database changes\[char46] The default value is considered false if this option is not defined\[char46] +.TP +\fBexternal_ids:ovn\-ofctrl\-wait\-before\-clear\fR +The time, in milliseconds, to wait before clearing flows in OVS after OpenFlow connection/reconnection during \fBovn\-controller\fR initialization\[char46] The purpose of this wait is to give time for \fBovn\-controller\fR to compute the new flows before clearing existing ones, to avoid data plane down time during \fBovn\-controller\fR restart/upgrade at large scale environments where recomputing the flows takes more than a few seconds or even longer\[char46] It is difficult for \fBovn\-controller\fR to determine when the new flows computing is completed, because of the dynamics in the cloud environments, which is why this configuration is provided for users to adjust based on the scale of the environment\[char46] By default, it is 0, which means clearing existing flows without waiting\[char46] Not setting the value, or setting it too small, may result in data plane down time during upgrade/restart, while setting it too big may result in unnecessary extra control plane latency of applying new changes of CMS during upgrade/restart\[char46] In most cases, a slightly bigger value is not harmful, because the extra control plane latency happens only once during the OpenFlow connection\[char46] To get a reasonable range of the value setting, it is recommended to run the below commands on a node in the target environment and then set this configuration to twice the value of \fBMaximum\fR shown in the output of the second command\[char46] +.RS +.IP \(bu +\fBovn\-appctl \-t ovn\-controller inc\-engine/recompute\fR +.IP \(bu +\fBovn\-appctl \-t ovn\-controller stopwatch/show flow\-generation\fR +.RE +.TP +\fBexternal_ids:ovn\-enable\-lflow\-cache\fR +The boolean flag indicates if \fBovn\-controller\fR should enable/disable the logical flow in-memory cache it uses when processing Southbound database logical flow changes\[char46] By default caching is enabled\[char46] +.TP +\fBexternal_ids:ovn\-limit\-lflow\-cache\fR +When used, this configuration value determines the maximum number of logical flow cache entries \fBovn\-controller\fR may create when the logical flow cache is enabled\[char46] By default the size of the cache is unlimited\[char46] +.TP +\fBexternal_ids:ovn\-memlimit\-lflow\-cache\-kb\fR +When used, this configuration value determines the maximum size of the logical flow cache (in KB) \fBovn\-controller\fR may create when the logical flow cache is enabled\[char46] By default the size of the cache is unlimited\[char46] +.TP +\fBexternal_ids:ovn\-trim\-limit\-lflow\-cache\fR +When used, this configuration value sets the minimum number of entries in the logical flow cache starting with which automatic memory trimming is performed\[char46] By default this is set to 10000 entries\[char46] +.TP +\fBexternal_ids:ovn\-trim\-wmark\-perc\-lflow\-cache\fR +When used, this configuration value sets the percentage from the high watermark number of entries in the logical flow cache under which automatic memory trimming is performed\[char46] E\[char46]g\[char46], if the trim watermark percentage is set to 50%, automatic memory trimming happens only when the number of entries in the logical flow cache gets reduced to less than half of the last measured high watermark\[char46] By default this is set to 50\[char46] +.TP +\fBexternal_ids:ovn\-trim\-timeout\-ms\fR +When used, this configuration value specifies the time, in milliseconds, since the last logical flow cache operation after which \fBovn\-controller\fR performs memory trimming regardless of how many entries there are in the cache\[char46] By default this is set to 30000 (30 seconds)\[char46] +.TP +\fBexternal_ids:ovn\-set\-local\-ip\fR +The boolean flag indicates if \fBovn\-controller\fR when create tunnel ports should set \fBlocal_ip\fR parameter\[char46] Can be heplful to pin source outer IP for the tunnel when multiple interfaces are used on the host for overlay traffic\[char46] This is also useful when running multiple \fBovn\-controller\fR instances on the same chassis, in which case this setting will guarantee that their tunnel ports have unique configuration and can exist in parallel\[char46] +.TP +\fBexternal_ids:garp\-max\-timeout\-sec\fR +When used, this configuration value specifies the maximum timeout (in seconds) between two consecutive GARP packets sent by \fBovn\-controller\fR\[char46] \fBovn\-controller\fR by default sends just 4 GARP packets with an exponential backoff timeout\[char46] Setting \fBexternal_ids:garp\-max\-timeout\-sec\fR allows to cap for the exponential backoff used by \fBovn\-controller\fR to send GARPs packets\[char46] +.RE +.PP +.PP +Most of configuration options listed above can also be set for a particular chassis name (see \fBexternal_ids:system\-id \fR for more information)\[char46] This can be achieved by setting \fBexternal_ids:option\-[chassis]\fR instead of \fBexternal_ids:option\fR\[char46] For example, set \fBexternal_ids:ovn\-encap\-ip\-otherhv\fR to use a particular IP address for the controller instance named \fBotherhv\fR\[char46] Name specific configuration options always override any global options set in the database\[char46] +.PP +.PP +Chassis-specific configuration options in the database plus the ability to configure the chassis name to use via the \fBsystem\-id\-override\fR file or command line allows to run multiple \fBovn\-controller\fR instances with unique chassis names on the same host using the same \fBvswitchd\fR instance\[char46] This may be useful when running a hybrid setup with more than one CMS managing ports on the host, or to use different datapath types on the same host\[char46] Make sure you also set \fBexternal_ids:ovn\-set\-local\-ip\fR when using such configuration\[char46] Also note that this ability is highly experimental and has known limitations (for example, stateful ACLs are not supported)\[char46] Use at your own risk\[char46] +.PP +.PP +\fBovn\-controller\fR reads the following values from the \fBOpen_vSwitch\fR database of the local OVS instance: +.RS +.TP +\fBdatapath\-type\fR from \fBBridge\fR table +This value is read from local OVS integration bridge row of \fBBridge\fR table and populated in \fBother_config:datapath-type\fR of the \fBChassis\fR table in the OVN_Southbound database\[char46] +.TP +\fBiface\-types\fR from \fBOpen_vSwitch\fR table +This value is populated in \fBexternal_ids:iface-types\fR of the \fBChassis\fR table in the OVN_Southbound database\[char46] +.TP +\fBprivate_key\fR, \fBcertificate\fR, \fBca_cert\fR, and \fBbootstrap_ca_cert\fR from \fBSSL\fR table +These values provide the SSL configuration used for connecting to the OVN southbound database server when an SSL connection type is configured via \fBexternal_ids:ovn\-remote\fR\[char46] Note that this SSL configuration can also be provided via command-line options, the configuration in the database takes precedence if both are present\[char46] +.RE +.SH "OPEN VSWITCH DATABASE USAGE" +.PP +.PP +\fBovn\-controller\fR uses a number of \fBexternal_ids\fR keys in the Open vSwitch database to keep track of ports and interfaces\[char46] For proper operation, users should not change or clear these keys: +.RS +.TP +\fBexternal_ids:ovn\-chassis\-id\fR in the \fBPort\fR table +The presence of this key identifies a tunnel port within the integration bridge as one created by \fBovn\-controller\fR to reach a remote chassis\[char46] Its value is the chassis ID of the remote chassis\[char46] +.TP +\fBexternal_ids:ct\-zone\-*\fR in the \fBBridge\fR table +Logical ports and gateway routers are assigned a connection tracking zone by \fBovn\-controller\fR for stateful services\[char46] To keep state across restarts of \fBovn\-controller\fR, these keys are stored in the integration bridge\(cqs Bridge table\[char46] The name contains a prefix of \fBct\-zone\-\fR followed by the name of the logical port or gateway router\(cqs zone key\[char46] The value for this key identifies the zone used for this port\[char46] +.TP +\fBexternal_ids:ovn\-localnet\-port\fR in the \fBPort\fR table +The presence of this key identifies a patch port as one created by \fBovn\-controller\fR to connect the integration bridge and another bridge to implement a \fBlocalnet\fR logical port\[char46] Its value is the name of the logical port with \fBtype\fR set to \fBlocalnet\fR that the port implements\[char46] See \fBexternal_ids:ovn\-bridge\-mappings\fR, above, for more information\[char46] +.IP +Each \fBlocalnet\fR logical port is implemented as a pair of patch ports, one in the integration bridge, one in a different bridge, with the same \fBexternal_ids:ovn\-localnet\-port\fR value\[char46] +.TP +\fBexternal_ids:ovn\-l2gateway\-port\fR in the \fBPort\fR table +The presence of this key identifies a patch port as one created by \fBovn\-controller\fR to connect the integration bridge and another bridge to implement a \fBl2gateway\fR logical port\[char46] Its value is the name of the logical port with \fBtype\fR set to \fBl2gateway\fR that the port implements\[char46] See \fBexternal_ids:ovn\-bridge\-mappings\fR, above, for more information\[char46] +.IP +Each \fBl2gateway\fR logical port is implemented as a pair of patch ports, one in the integration bridge, one in a different bridge, with the same \fBexternal_ids:ovn\-l2gateway\-port\fR value\[char46] +.TP +\fBexternal\-ids:ovn\-l3gateway\-port\fR in the \fBPort\fR table +This key identifies a patch port as one created by \fBovn\-controller\fR to implement a \fBl3gateway\fR logical port\[char46] Its value is the name of the logical port with type set to \fBl3gateway\fR\[char46] This patch port is similar to the OVN logical patch port, except that \fBl3gateway\fR port can only be bound to a particular chassis\[char46] +.TP +\fBexternal\-ids:ovn\-logical\-patch\-port\fR in the \fBPort\fR table +This key identifies a patch port as one created by \fBovn\-controller\fR to implement an OVN logical patch port within the integration bridge\[char46] Its value is the name of the OVN logical patch port that it implements\[char46] +.TP +\fBexternal\-ids:ovn\-startup\-ts\fR in the \fBBridge\fR table +This key represents the timestamp (in milliseconds) at which \fBovn\-controller\fR process was started\[char46] +.TP +\fBexternal\-ids:ovn\-nb\-cfg\fR in the \fBBridge\fR table +This key represents the last known \fBOVN_Southbound\[char46]SB_Global\[char46]nb_cfg\fR value for which all flows have been successfully installed in OVS\[char46] +.TP +\fBexternal\-ids:ovn\-nb\-cfg\-ts\fR in the \fBBridge\fR table +This key represents the timestamp (in milliseconds) of the last known \fBOVN_Southbound\[char46]SB_Global\[char46]nb_cfg\fR value for which all flows have been successfully installed in OVS\[char46] +.TP +\fBexternal_ids:ovn\-installed\fR and \fBexternal_ids:ovn\-installed\-ts\fR in the \fBInterface\fR table +This key is set after all openflow operations corresponding to the OVS interface have been processed by ovs-vswitchd\[char46] At the same time a timestamp, in milliseconds since the epoch, is stored in \fBexternal_ids:ovn\-installed\-ts\fR\[char46] +.RE +.SH "OVN SOUTHBOUND DATABASE USAGE" +.PP +.PP +\fBovn\-controller\fR reads from much of the \fBOVN_Southbound\fR database to guide its operation\[char46] \fBovn\-controller\fR also writes to the following tables: +.RS +.TP +\fBChassis\fR +Upon startup, \fBovn\-controller\fR creates a row in this table to represent its own chassis\[char46] Upon graceful termination, e\[char46]g\[char46] with \fBovs\-appctl \-t ovn\-controller exit\fR (but not \fBSIGTERM\fR), \fBovn\-controller\fR removes its row\[char46] +.TP +\fBEncap\fR +Upon startup, \fBovn\-controller\fR creates a row or rows in this table that represent the tunnel encapsulations by which its chassis can be reached, and points its \fBChassis\fR row to them\[char46] Upon graceful termination, \fBovn\-controller\fR removes these rows\[char46] +.TP +\fBPort_Binding\fR +At runtime, \fBovn\-controller\fR sets the \fBchassis\fR columns of ports that are resident on its chassis to point to its \fBChassis\fR row, and, conversely, clears the \fBchassis\fR column of ports that point to its \fBChassis\fR row but are no longer resident on its chassis\[char46] The \fBchassis\fR column has a weak reference type, so when \fBovn\-controller\fR gracefully exits and removes its \fBChassis\fR row, the database server automatically clears any remaining references to that row\[char46] +.TP +\fBMAC_Binding\fR +At runtime, \fBovn\-controller\fR updates the \fBMAC_Binding\fR table as instructed by \fBput_arp\fR and \fBput_nd\fR logical actions\[char46] These changes persist beyond the lifetime of \fBovn\-controller\fR\[char46] +.RE +.SH "RUNTIME MANAGEMENT COMMANDS" +.PP +.PP +\fBovs\-appctl\fR can send commands to a running \fBovn\-controller\fR process\[char46] The currently supported commands are described below\[char46] +.RS +.TP +\fBexit\fR +Causes \fBovn\-controller\fR to gracefully terminate\[char46] +.TP +\fBct\-zone\-list\fR +Lists each local logical port and its connection tracking zone\[char46] +.TP +\fBmeter\-table\-list\fR +Lists each meter table entry and its local meter id\[char46] +.TP +\fBgroup\-table\-list\fR +Lists each group table entry and its local group id\[char46] +.TP +\fBinject\-pkt\fR \fImicroflow\fR +Injects \fImicroflow\fR into the connected Open vSwitch instance\[char46] \fImicroflow\fR must contain an ingress logical port (\fBinport\fR argument) that is present on the Open vSwitch instance\[char46] +.IP +The \fImicroflow\fR argument describes the packet whose forwarding is to be simulated, in the syntax of an OVN logical expression, as described in \fBovn\-sb\fR(5), to express constraints\[char46] The parser understands prerequisites; for example, if the expression refers to \fBip4\[char46]src\fR, there is no need to explicitly state \fBip4\fR or \fBeth\[char46]type == +0x800\fR\[char46] +.TP +\fBconnection\-status\fR +Show OVN SBDB connection status for the chassis\[char46] +.TP +\fBrecompute\fR +Trigger a full compute iteration in \fBovn\-controller\fR based on the contents of the Southbound database and local OVS database\[char46] +.IP +This command is intended to use only in the event of a bug in the incremental processing engine in \fBovn\-controller\fR to avoid inconsistent states\[char46] It should therefore be used with care as full recomputes are cpu intensive\[char46] +.TP +\fBsb\-cluster\-state\-reset\fR +Reset southbound database cluster status when databases are destroyed and rebuilt\[char46] +.IP +If all databases in a clustered southbound database are removed from disk, then the stored index of all databases will be reset to zero\[char46] This will cause ovn-controller to be unable to read or write to the southbound database, because it will always detect the data as stale\[char46] In such a case, run this command so that ovn-controller will reset its local index so that it can interact with the southbound database again\[char46] +.TP +\fBdebug/delay\-nb\-cfg\-report\fR \fIseconds\fR +This command is used to delay ovn-controller updating the \fBnb_cfg\fR back to \fBOVN_Southbound\fR database\[char46] This is useful when \fBovn\-nbctl \-\-wait=hv\fR is used to measure end-to-end latency in a large scale environment\[char46] See \fBovn\-nbctl\fR(8) for more details\[char46] +.TP +\fBlflow\-cache/flush\fR +Flushes the \fBovn\-controller\fR logical flow cache\[char46] +.TP +\fBlflow\-cache/show\-stats\fR +Displays logical flow cache statistics: enabled/disabled, per cache type entry counts\[char46] +.TP +\fBinc\-engine/show\-stats\fR +Display \fBovn\-controller\fR engine counters\[char46] For each engine node the following counters have been added: +.RS +.IP \(bu +\fBrecompute\fR +.IP \(bu +\fBcompute\fR +.IP \(bu +\fBabort\fR +.RE +.TP +\fBinc\-engine/show\-stats \fIengine_node_name\fB \fIcounter_name\fB\fR +Display the \fBovn\-controller\fR engine counter(s) for the specified \fIengine_node_name\fR\[char46] \fIcounter_name\fR is optional and can be one of \fBrecompute\fR, \fBcompute\fR or \fBabort\fR\[char46] +.TP +\fBinc\-engine/clear\-stats\fR +Reset \fBovn\-controller\fR engine counters\[char46] +.RE diff --git a/src/static/support/dist-docs-branch-23.06/ovn-controller.8.html b/src/static/support/dist-docs-branch-23.06/ovn-controller.8.html new file mode 100644 index 00000000..191063a8 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-controller.8.html @@ -0,0 +1,784 @@ +
+ovn-controller(8)                 OVN Manual                 ovn-controller(8)
+
+NAME
+       ovn-controller - Open Virtual Network local controller
+
+SYNOPSIS
+       ovn-controller [options] [ovs-database]
+
+DESCRIPTION
+       ovn-controller is the local controller daemon for OVN, the Open Virtual
+       Network.  It connects up to the OVN Southbound database (see ovn-sb(5))
+       over the OVSDB protocol, and down to the  Open  vSwitch  database  (see
+       ovs-vswitchd.conf.db(5)) over the OVSDB protocol and to ovs-vswitchd(8)
+       via OpenFlow. Each hypervisor and software gateway in an OVN deployment
+       runs its own independent copy of ovn-controller; thus, ovn-controllerā€™s
+       downward  connections  are machine-local and do not run over a physical
+       network.
+
+ACL LOGGING
+       ACL log messages are logged through ovn-controllerā€™s logging mechanism.
+       ACL log entries have the module acl_log at log level info.  Configuring
+       logging is described below in the Logging Options section.
+
+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
+              specified, or if it does not begin with /, then it is created in
+              .
+
+              If --pidfile is not specified, no pidfile is created.
+
+       --overwrite-pidfile
+              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.
+
+              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
+              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
+              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ā€ā€
+              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ā€
+              tions without it.
+
+       --no-chdir
+              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.
+
+              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-
+              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.
+
+       --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
+              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
+              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
+              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
+            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
+                   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,  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
+                   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
+                   definition of each log level.
+
+            Case is not significant within spec.
+
+            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
+            word but has no effect.
+
+       -v
+       --verbose
+            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-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,
+            local4, local5, local6 or local7. If this option is not specified,
+            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
+            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.
+
+       --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ā€
+            name.
+
+       --syslog-method=method
+            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
+                   /dev/log UNIX domain socket.
+
+            ā€¢      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 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
+       to the Northbound and Southbound databases.
+
+              -p privkey.pem
+              --private-key=privkey.pem
+                   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ā€
+                   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
+                   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
+                   verify the certificate specified on -c or --certificate, or
+                   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
+                   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ā€
+                     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.
+
+                     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
+                     certificate as part of the SSL certificate chain. The SSL
+                     protocol  does not require the server to send the CA cerā€
+                     tificate.
+
+                     This option is mutually exclusive with -C and --ca-cert.
+
+              --peer-ca-cert=peer-cacert.pem
+                     Specifies a PEM file that contains one or more additional
+                     certificates to send to SSL peers. peer-cacert.pem should
+                     be the CA certificate used to sign the programā€™s own cerā€
+                     tificate, that is, the certificate  specified  on  -c  or
+                     --certificate.  If  the  programā€™s  certificate  is self-
+                     signed,  then  --certificate  and  --peer-ca-cert  should
+                     specify the same file.
+
+                     This  option  is  not useful in normal operation, because
+                     the SSL peer must already have the CA certificate for the
+                     peer to have any confidence in  the  programā€™s  identity.
+                     However,  this  offers  a  way  for a new installation to
+                     bootstrap the CA certificate on its first SSL connection.
+
+   Other Options
+       -h
+       --help
+            Prints a brief help message to the console.
+
+       -V
+       --version
+            Prints version information to the console.
+
+CONFIGURATION
+       ovn-controller retrieves most of its configuration information from the
+       local Open vSwitchā€™s ovsdb-server instance.  The  default  location  is
+       db.sock in the local Open vSwitchā€™s "run" directory. It may be overridā€
+       den  by specifying the ovs-database argument as an OVSDB active or pasā€
+       sive connection method, as described in ovsdb(7).
+
+       ovn-controller assumes it gets configuration information from the  folā€
+       lowing keys in the Open_vSwitch table of the local OVS instance:
+
+              external_ids:system-id
+                     The  chassis  name  to use in the Chassis table. Changing
+                     the system-id while ovn-controller is running is not  diā€
+                     rectly  supported.  Users  have two options: either first
+                     gracefully stop ovn-controller  or  manually  delete  the
+                     stale  Chassis and Chassis_Private records after changing
+                     the system-id. Note that the chassis  name  can  also  be
+                     provided via the system-id-override file in the local OVN
+                     "etc"  directory  or  via the -n command-line option. The
+                     following precedence is used: first, the command-line opā€
+                     tion is read; if not present, the system-id-override file
+                     is read; if not present, then the name configured in  the
+                     database is used.
+
+              external_ids:hostname
+                     The hostname to use in the Chassis table.
+
+              external_ids:ovn-bridge
+                     The  integration  bridge  to  which logical ports are atā€
+                     tached. The default is br-int. If this  bridge  does  not
+                     exist  when ovn-controller starts, it will be created auā€
+                     tomatically with the default configuration  suggested  in
+                     ovn-architecture(7).  When  more than one controllers are
+                     running on the same  host,  external_ids:ovn-bridge-CHASā€ā€
+                     SIS_NAME  should  be  set for each of them, pointing to a
+                     unique bridge. This  is  required  to  avoid  controllers
+                     stepping on each othersā€™ feet.
+
+              external_ids:ovn-bridge-datapath-type
+                     This configuration is optional. If set, then the datapath
+                     type of the integration bridge will be set to the configā€
+                     ured  value.  If  this  option  is not set, then ovn-conā€ā€
+                     troller will not modify the existing datapath-type of the
+                     integration bridge.
+
+              external_ids:ovn-remote
+                     The OVN database that this system should connect  to  for
+                     its  configuration,  in  one of the same forms documented
+                     above for the ovs-database.
+
+              external_ids:ovn-monitor-all
+                     A boolean value that tells if ovn-controller should moniā€
+                     tor all records of tables  in  ovs-database.  If  set  to
+                     false,  it will conditionally monitor the records that is
+                     needed in the current chassis.
+
+                     It is more efficient to set it to true in use cases where
+                     the chassis would anyway need  to  monitor  most  of  the
+                     records  in OVN Southbound database, which would save the
+                     overhead of conditions processing, especially for  server
+                     side. Typically, set it to true for environments that all
+                     workloads need to be reachable from each other.
+
+                     Default value is false.
+
+              external_ids:ovn-remote-probe-interval
+                     The  inactivity  probe  interval of the connection to the
+                     OVN database, in milliseconds. If the value is  zero,  it
+                     disables the connection keepalive feature.
+
+                     If  the  value  is  nonzero,  then it will be forced to a
+                     value of at least 1000 ms.
+
+              external_ids:ovn-openflow-probe-interval
+                     The inactivity probe interval of the OpenFlow  connection
+                     to the OpenvSwitch integration bridge, in seconds. If the
+                     value  is zero, it disables the connection keepalive feaā€
+                     ture.
+
+                     If the value is nonzero, then it  will  be  forced  to  a
+                     value of at least 5s.
+
+              external_ids:ovn-encap-type
+                     The  encapsulation type that a chassis should use to conā€
+                     nect to this node. Multiple encapsulation  types  may  be
+                     specified with a comma-separated list. Each listed encapā€
+                     sulation type will be paired with ovn-encap-ip.
+
+                     Supported  tunnel  types  for  connecting hypervisors and
+                     gateways are geneve, vxlan, and stt.
+
+                     Due to the limited amount of metadata in vxlan, the capaā€
+                     bilities and performance of connected gateways and hyperā€
+                     visors will be reduced versus other tunnel formats.
+
+              external_ids:ovn-encap-ip
+                     The IP address that a chassis should use  to  connect  to
+                     this  node  using encapsulation types specified by exterā€ā€
+                     nal_ids:ovn-encap-type.
+
+              external_ids:ovn-encap-df_default
+                     indicates the DF flag handling of the  encapulation.  Set
+                     to true to set the DF flag for new data paths or false to
+                     clear the DF flag.
+
+              external_ids:ovn-bridge-mappings
+                     A  list  of  key-value  pairs that map a physical network
+                     name to a local ovs bridge that provides connectivity  to
+                     that  network. An example value mapping two physical netā€
+                     work  names  to  two  ovs   bridges   would   be:   physā€ā€
+                     net1:br-eth0,physnet2:br-eth1.
+
+              external_ids:ovn-encap-csum
+                     ovn-encap-csum indicates that encapsulation checksums can
+                     be  transmitted and received with reasonable performance.
+                     It is a hint to senders transmitting data to this chassis
+                     that they should use checksums to protect  OVN  metadata.
+                     Set  to  true to enable or false to disable. Depending on
+                     the capabilities of the network interface card,  enabling
+                     encapsulation  checksum  may  incur  performance loss. In
+                     such cases, encapsulation checksums can be disabled.
+
+              external_ids:ovn-encap-tos
+                     ovn-encap-tos indicates the value to be  applied  to  OVN
+                     tunnel   interfaceā€™s   option:tos  as  specified  in  the
+                     Open_vSwitch database Interface table.  Please  refer  to
+                     Open VSwitch Manual for details.
+
+              external_ids:ovn-cms-options
+                     A list of options that will be consumed by the CMS Plugin
+                     and which specific to this particular chassis. An example
+                     would be: cms_option1,cms_option2:foo.
+
+              external_ids:ovn-transport-zones
+                     The  transport  zone(s)  that  this  chassis  belongs to.
+                     Transport zones is a way to group  different  chassis  so
+                     that  tunnels are only formed between members of the same
+                     group(s). Multiple transport zones may be specified  with
+                     a comma-separated list. For example: tz1,tz2,tz3.
+
+                     If  not set, the Chassis will be considered part of a deā€
+                     fault transport zone.
+
+              external_ids:ovn-chassis-mac-mappings
+                     A list of key-value pairs that map a chassis specific mac
+                     to a physical network name. An example value mapping  two
+                     chassis  macs  to  two  physical  network names would be:
+                     physnet1:aa:bb:cc:dd:ee:ff,physnet2:a1:b2:c3:d4:e5:f6.
+                     These are the macs that  ovn-controller  will  replace  a
+                     router  port mac with, if packet is going from a distribā€
+                     uted router port on vlan type logical switch.
+
+              external_ids:ovn-is-interconn
+                     The boolean flag indicates if the chassis is used  as  an
+                     interconnection gateway.
+
+              external_ids:ovn-match-northd-version
+                     The  boolean  flag  indicates  if ovn-controller needs to
+                     check ovn-northd version. If this flag is set to true and
+                     the ovn-northdā€™ā€™s  version  (reported  in  the  Southbound
+                     database)  doesnā€™t match with the ovn-controllerā€™ā€™s interā€
+                     nal version, then it will stop processing the  southbound
+                     and  local  Open  vSwitch  database  changes. The default
+                     value is considered false if this option is not defined.
+
+              external_ids:ovn-ofctrl-wait-before-clear
+                     The time, in milliseconds, to wait before clearing  flows
+                     in  OVS  after  OpenFlow  connection/reconnection  during
+                     ovn-controller initialization. The purpose of  this  wait
+                     is  to  give  time  for ovn-controller to compute the new
+                     flows before clearing existing ones, to avoid data  plane
+                     down  time during ovn-controller restart/upgrade at large
+                     scale environments where recomputing the flows takes more
+                     than a few seconds or even longer. It  is  difficult  for
+                     ovn-controller  to determine when the new flows computing
+                     is completed, because of the dynamics in the cloud  enviā€
+                     ronments, which is why this configuration is provided for
+                     users to adjust based on the scale of the environment. By
+                     default,  it  is  0,  which means clearing existing flows
+                     without waiting. Not setting the value, or setting it too
+                     small, may result in data  plane  down  time  during  upā€
+                     grade/restart, while setting it too big may result in unā€
+                     necessary  extra  control  plane  latency of applying new
+                     changes of CMS during upgrade/restart. In most  cases,  a
+                     slightly  bigger  value is not harmful, because the extra
+                     control plane latency happens only once during the  Openā€
+                     Flow  connection.  To get a reasonable range of the value
+                     setting, it is recommended to run the below commands on a
+                     node in the target environment and then set this configuā€
+                     ration to twice the value of Maximum shown in the  output
+                     of the second command.
+
+                     ā€¢      ovn-appctl -t ovn-controller inc-engine/recompute
+
+                     ā€¢      ovn-appctl    -t   ovn-controller   stopwatch/show
+                            flow-generation
+
+              external_ids:ovn-enable-lflow-cache
+                     The boolean flag indicates if ovn-controller  should  enā€
+                     able/disable  the  logical  flow  in-memory cache it uses
+                     when processing Southbound database logical flow changes.
+                     By default caching is enabled.
+
+              external_ids:ovn-limit-lflow-cache
+                     When used, this configuration value determines the  maxiā€
+                     mum  number  of logical flow cache entries ovn-controller
+                     may create when the logical flow cache is enabled. By deā€
+                     fault the size of the cache is unlimited.
+
+              external_ids:ovn-memlimit-lflow-cache-kb
+                     When used, this configuration value determines the  maxiā€
+                     mum size of the logical flow cache (in KB) ovn-controller
+                     may create when the logical flow cache is enabled. By deā€
+                     fault the size of the cache is unlimited.
+
+              external_ids:ovn-trim-limit-lflow-cache
+                     When used, this configuration value sets the minimum numā€
+                     ber  of  entries  in the logical flow cache starting with
+                     which automatic memory trimming is performed. By  default
+                     this is set to 10000 entries.
+
+              external_ids:ovn-trim-wmark-perc-lflow-cache
+                     When  used,  this configuration value sets the percentage
+                     from the high watermark number of entries in the  logical
+                     flow  cache under which automatic memory trimming is perā€
+                     formed. E.g., if the trim watermark percentage is set  to
+                     50%, automatic memory trimming happens only when the numā€
+                     ber  of entries in the logical flow cache gets reduced to
+                     less than half of the last measured  high  watermark.  By
+                     default this is set to 50.
+
+              external_ids:ovn-trim-timeout-ms
+                     When  used,  this configuration value specifies the time,
+                     in milliseconds, since the last logical flow cache operaā€
+                     tion after which ovn-controller performs memory  trimming
+                     regardless of how many entries there are in the cache. By
+                     default this is set to 30000 (30 seconds).
+
+              external_ids:ovn-set-local-ip
+                     The  boolean flag indicates if ovn-controller when create
+                     tunnel ports should set local_ip parameter. Can be  heplā€
+                     ful  to  pin source outer IP for the tunnel when multiple
+                     interfaces are used on the host for overlay traffic. This
+                     is also useful when running multiple  ovn-controller  inā€
+                     stances  on  the same chassis, in which case this setting
+                     will guarantee that their tunnel ports have  unique  conā€
+                     figuration and can exist in parallel.
+
+              external_ids:garp-max-timeout-sec
+                     When used, this configuration value specifies the maximum
+                     timeout (in seconds) between two consecutive GARP packets
+                     sent  by  ovn-controller. ovn-controller by default sends
+                     just 4 GARP packets with an exponential backoff  timeout.
+                     Setting  external_ids:garp-max-timeout-sec  allows to cap
+                     for the exponential backoff  used  by  ovn-controller  to
+                     send GARPs packets.
+
+       Most  of  configuration options listed above can also be set for a parā€
+       ticular chassis name (see  external_ids:system-id   for  more  informaā€
+       tion).  This  can  be achieved by setting external_ids:option-[chassis]
+       instead of external_ids:option. For example,  set  external_ids:ovn-enā€ā€
+       cap-ip-otherhv  to  use  a particular IP address for the controller inā€
+       stance named otherhv. Name specific configuration options always  overā€
+       ride any global options set in the database.
+
+       Chassis-specific configuration options in the database plus the ability
+       to configure the chassis name to use via the system-id-override file or
+       command  line  allows  to  run  multiple  ovn-controller instances with
+       unique chassis names on the same host using the same vswitchd instance.
+       This may be useful when running a hybrid setup with more than  one  CMS
+       managing  ports  on the host, or to use different datapath types on the
+       same host. Make sure you also  set  external_ids:ovn-set-local-ip  when
+       using such configuration. Also note that this ability is highly experiā€
+       mental  and  has  known limitations (for example, stateful ACLs are not
+       supported). Use at your own risk.
+
+       ovn-controller reads the following values from the  Open_vSwitch  dataā€
+       base of the local OVS instance:
+
+              datapath-type from Bridge table
+                     This  value is read from local OVS integration bridge row
+                     of Bridge table and populated  in  other_config:datapath-
+                     type of the Chassis table in the OVN_Southbound database.
+
+              iface-types from Open_vSwitch table
+                     This  value  is  populated in external_ids:iface-types of
+                     the Chassis table in the OVN_Southbound database.
+
+              private_key, certificate, ca_cert, and bootstrap_ca_cert from
+              SSL table
+                     These values provide the SSL configuration used for  conā€
+                     necting to the OVN southbound database server when an SSL
+                     connection  type  is  configured via external_ids:ovn-reā€ā€
+                     mote. Note that this SSL configuration can also  be  proā€
+                     vided  via command-line options, the configuration in the
+                     database takes precedence if both are present.
+
+OPEN VSWITCH DATABASE USAGE
+       ovn-controller uses a number of external_ids keys in the  Open  vSwitch
+       database  to  keep track of ports and interfaces. For proper operation,
+       users should not change or clear these keys:
+
+              external_ids:ovn-chassis-id in the Port table
+                     The presence of this key identifies a tunnel port  within
+                     the  integration  bridge as one created by ovn-controller
+                     to reach a remote chassis. Its value is the chassis ID of
+                     the remote chassis.
+
+              external_ids:ct-zone-* in the Bridge table
+                     Logical ports and gateway routers are assigned a  connecā€
+                     tion  tracking  zone  by ovn-controller for stateful serā€
+                     vices. To keep state across restarts  of  ovn-controller,
+                     these  keys are stored in the integration bridgeā€™s Bridge
+                     table. The name contains a prefix of ct-zone- followed by
+                     the name of the logical port  or  gateway  routerā€™s  zone
+                     key.  The value for this key identifies the zone used for
+                     this port.
+
+              external_ids:ovn-localnet-port in the Port table
+                     The presence of this key identifies a patch port  as  one
+                     created  by  ovn-controller  to  connect  the integration
+                     bridge and another bridge to implement a localnet logical
+                     port. Its value is the name of the logical port with type
+                     set to localnet that  the  port  implements.  See  exterā€ā€
+                     nal_ids:ovn-bridge-mappings, above, for more information.
+
+                     Each  localnet  logical  port is implemented as a pair of
+                     patch ports, one in the integration bridge, one in a difā€
+                     ferent  bridge,  with  the  same  external_ids:ovn-localā€ā€
+                     net-port value.
+
+              external_ids:ovn-l2gateway-port in the Port table
+                     The  presence  of this key identifies a patch port as one
+                     created by  ovn-controller  to  connect  the  integration
+                     bridge  and another bridge to implement a l2gateway logiā€
+                     cal port. Its value is the name of the logical port  with
+                     type  set  to l2gateway that the port implements. See exā€ā€
+                     ternal_ids:ovn-bridge-mappings, above, for more  informaā€
+                     tion.
+
+                     Each  l2gateway  logical port is implemented as a pair of
+                     patch ports, one in the integration bridge, one in a difā€
+                     ferent bridge,  with  the  same  external_ids:ovn-l2gateā€ā€
+                     way-port value.
+
+              external-ids:ovn-l3gateway-port in the Port table
+                     This  key  identifies  a  patch  port  as  one created by
+                     ovn-controller to implement a l3gateway logical port. Its
+                     value is the name of the logical port with  type  set  to
+                     l3gateway.  This patch port is similar to the OVN logical
+                     patch port, except that l3gateway port can only be  bound
+                     to a particular chassis.
+
+              external-ids:ovn-logical-patch-port in the Port table
+                     This  key  identifies  a  patch  port  as  one created by
+                     ovn-controller to implement an  OVN  logical  patch  port
+                     within  the  integration bridge. Its value is the name of
+                     the OVN logical patch port that it implements.
+
+              external-ids:ovn-startup-ts in the Bridge table
+                     This key represents the timestamp  (in  milliseconds)  at
+                     which ovn-controller process was started.
+
+              external-ids:ovn-nb-cfg in the Bridge table
+                     This   key   represents   the   last   known   OVN_Southā€ā€
+                     bound.SB_Global.nb_cfg value for  which  all  flows  have
+                     been successfully installed in OVS.
+
+              external-ids:ovn-nb-cfg-ts in the Bridge table
+                     This  key  represents  the timestamp (in milliseconds) of
+                     the last known OVN_Southbound.SB_Global.nb_cfg value  for
+                     which all flows have been successfully installed in OVS.
+
+              external_ids:ovn-installed and external_ids:ovn-installed-ts in
+              the Interface table
+                     This key is set after all openflow operations correspondā€
+                     ing  to  the  OVS  interface  have been processed by ovs-
+                     vswitchd. At the same time a timestamp,  in  milliseconds
+                     since   the  epoch,  is  stored  in  external_ids:ovn-inā€ā€
+                     stalled-ts.
+
+OVN SOUTHBOUND DATABASE USAGE
+       ovn-controller reads from much of the OVN_Southbound database to  guide
+       its operation. ovn-controller also writes to the following tables:
+
+              Chassis
+                     Upon  startup, ovn-controller creates a row in this table
+                     to represent its own chassis. Upon graceful  termination,
+                     e.g.  with  ovs-appctl  -t  ovn-controller  exit (but not
+                     SIGTERM), ovn-controller removes its row.
+
+              Encap  Upon startup, ovn-controller creates a  row  or  rows  in
+                     this  table  that  represent the tunnel encapsulations by
+                     which its chassis can be reached, and points its  Chassis
+                     row  to  them.  Upon graceful termination, ovn-controller
+                     removes these rows.
+
+              Port_Binding
+                     At runtime, ovn-controller sets the  chassis  columns  of
+                     ports  that  are  resident on its chassis to point to its
+                     Chassis row, and, conversely, clears the  chassis  column
+                     of  ports that point to its Chassis row but are no longer
+                     resident on its chassis. The chassis column  has  a  weak
+                     reference  type,  so when ovn-controller gracefully exits
+                     and removes its Chassis row, the database server automatā€
+                     ically clears any remaining references to that row.
+
+              MAC_Binding
+                     At runtime, ovn-controller updates the MAC_Binding  table
+                     as  instructed  by  put_arp  and  put_nd logical actions.
+                     These changes persist beyond  the  lifetime  of  ovn-conā€ā€
+                     troller.
+
+RUNTIME MANAGEMENT COMMANDS
+       ovs-appctl  can  send commands to a running ovn-controller process. The
+       currently supported commands are described below.
+
+              exit   Causes ovn-controller to gracefully terminate.
+
+              ct-zone-list
+                     Lists each local logical port and its connection tracking
+                     zone.
+
+              meter-table-list
+                     Lists each meter table entry and its local meter id.
+
+              group-table-list
+                     Lists each group table entry and its local group id.
+
+              inject-pkt microflow
+                     Injects microflow into the  connected  Open  vSwitch  inā€
+                     stance.  microflow  must  contain an ingress logical port
+                     (inport argument) that is present on the Open vSwitch inā€
+                     stance.
+
+                     The microflow argument describes the  packet  whose  forā€
+                     warding is to be simulated, in the syntax of an OVN logiā€
+                     cal  expression,  as  described  in ovn-sb(5), to express
+                     constraints. The parser  understands  prerequisites;  for
+                     example, if the expression refers to ip4.src, there is no
+                     need to explicitly state ip4 or eth.type == 0x800.
+
+              connection-status
+                     Show OVN SBDB connection status for the chassis.
+
+              recompute
+                     Trigger  a full compute iteration in ovn-controller based
+                     on the contents of the Southbound database and local  OVS
+                     database.
+
+                     This  command  is  intended to use only in the event of a
+                     bug in the  incremental  processing  engine  in  ovn-conā€ā€
+                     troller to avoid inconsistent states. It should therefore
+                     be used with care as full recomputes are cpu intensive.
+
+              sb-cluster-state-reset
+                     Reset  southbound  database cluster status when databases
+                     are destroyed and rebuilt.
+
+                     If all databases in a clustered southbound  database  are
+                     removed from disk, then the stored index of all databases
+                     will  be reset to zero. This will cause ovn-controller to
+                     be unable to read or write to  the  southbound  database,
+                     because  it will always detect the data as stale. In such
+                     a case, run this command so that ovn-controller will  reā€
+                     set  its  local  index  so  that it can interact with the
+                     southbound database again.
+
+              debug/delay-nb-cfg-report seconds
+                     This command is used to delay ovn-controller updating the
+                     nb_cfg back to OVN_Southbound database.  This  is  useful
+                     when  ovn-nbctl  --wait=hv  is used to measure end-to-end
+                     latency in a large scale  environment.  See  ovn-nbctl(8)
+                     for more details.
+
+              lflow-cache/flush
+                     Flushes the ovn-controller logical flow cache.
+
+              lflow-cache/show-stats
+                     Displays logical flow cache statistics: enabled/disabled,
+                     per cache type entry counts.
+
+              inc-engine/show-stats
+                     Display  ovn-controller  engine counters. For each engine
+                     node the following counters have been added:
+
+                     ā€¢      recompute
+
+                     ā€¢      compute
+
+                     ā€¢      abort
+
+              inc-engine/show-stats engine_node_name counter_name
+                     Display the  ovn-controller  engine  counter(s)  for  the
+                     specified  engine_node_name. counter_name is optional and
+                     can be one of recompute, compute or abort.
+
+              inc-engine/clear-stats
+                     Reset ovn-controller engine counters.
+
+OVN 23.06.3                     ovn-controller               ovn-controller(8)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-controller.8.pdf b/src/static/support/dist-docs-branch-23.06/ovn-controller.8.pdf new file mode 100644 index 00000000..b8a07aac Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-controller.8.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-controller.8.txt b/src/static/support/dist-docs-branch-23.06/ovn-controller.8.txt new file mode 100644 index 00000000..b72fd396 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-controller.8.txt @@ -0,0 +1,782 @@ +ovn-controller(8) OVN Manual ovn-controller(8) + +NAME + ovn-controller - Open Virtual Network local controller + +SYNOPSIS + ovn-controller [options] [ovs-database] + +DESCRIPTION + ovn-controller is the local controller daemon for OVN, the Open Virtual + Network. It connects up to the OVN Southbound database (see ovn-sb(5)) + over the OVSDB protocol, and down to the Open vSwitch database (see + ovs-vswitchd.conf.db(5)) over the OVSDB protocol and to ovs-vswitchd(8) + via OpenFlow. Each hypervisor and software gateway in an OVN deployment + runs its own independent copy of ovn-controller; thus, ovn-controllerā€™s + downward connections are machine-local and do not run over a physical + network. + +ACL LOGGING + ACL log messages are logged through ovn-controllerā€™s logging mechanism. + ACL log entries have the module acl_log at log level info. Configuring + logging is described below in the Logging Options section. + +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 + specified, or if it does not begin with /, then it is created in + . + + If --pidfile is not specified, no pidfile is created. + + --overwrite-pidfile + 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. + + 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 + 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 + 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ā€ā€ + 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ā€ + tions without it. + + --no-chdir + 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. + + 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- + 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. + + --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 + 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 + 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 + 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 + 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 + 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, 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 + 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 + definition of each log level. + + Case is not significant within spec. + + 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 + word but has no effect. + + -v + --verbose + 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-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, + local4, local5, local6 or local7. If this option is not specified, + 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 + 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. + + --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ā€ + name. + + --syslog-method=method + 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 + /dev/log UNIX domain socket. + + ā€¢ 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 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 + to the Northbound and Southbound databases. + + -p privkey.pem + --private-key=privkey.pem + 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ā€ + 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 + 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 + verify the certificate specified on -c or --certificate, or + 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 + 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ā€ + 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. + + 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 + certificate as part of the SSL certificate chain. The SSL + protocol does not require the server to send the CA cerā€ + tificate. + + This option is mutually exclusive with -C and --ca-cert. + + --peer-ca-cert=peer-cacert.pem + Specifies a PEM file that contains one or more additional + certificates to send to SSL peers. peer-cacert.pem should + be the CA certificate used to sign the programā€™s own cerā€ + tificate, that is, the certificate specified on -c or + --certificate. If the programā€™s certificate is self- + signed, then --certificate and --peer-ca-cert should + specify the same file. + + This option is not useful in normal operation, because + the SSL peer must already have the CA certificate for the + peer to have any confidence in the programā€™s identity. + However, this offers a way for a new installation to + bootstrap the CA certificate on its first SSL connection. + + Other Options + -h + --help + Prints a brief help message to the console. + + -V + --version + Prints version information to the console. + +CONFIGURATION + ovn-controller retrieves most of its configuration information from the + local Open vSwitchā€™s ovsdb-server instance. The default location is + db.sock in the local Open vSwitchā€™s "run" directory. It may be overridā€ + den by specifying the ovs-database argument as an OVSDB active or pasā€ + sive connection method, as described in ovsdb(7). + + ovn-controller assumes it gets configuration information from the folā€ + lowing keys in the Open_vSwitch table of the local OVS instance: + + external_ids:system-id + The chassis name to use in the Chassis table. Changing + the system-id while ovn-controller is running is not diā€ + rectly supported. Users have two options: either first + gracefully stop ovn-controller or manually delete the + stale Chassis and Chassis_Private records after changing + the system-id. Note that the chassis name can also be + provided via the system-id-override file in the local OVN + "etc" directory or via the -n command-line option. The + following precedence is used: first, the command-line opā€ + tion is read; if not present, the system-id-override file + is read; if not present, then the name configured in the + database is used. + + external_ids:hostname + The hostname to use in the Chassis table. + + external_ids:ovn-bridge + The integration bridge to which logical ports are atā€ + tached. The default is br-int. If this bridge does not + exist when ovn-controller starts, it will be created auā€ + tomatically with the default configuration suggested in + ovn-architecture(7). When more than one controllers are + running on the same host, external_ids:ovn-bridge-CHASā€ā€ + SIS_NAME should be set for each of them, pointing to a + unique bridge. This is required to avoid controllers + stepping on each othersā€™ feet. + + external_ids:ovn-bridge-datapath-type + This configuration is optional. If set, then the datapath + type of the integration bridge will be set to the configā€ + ured value. If this option is not set, then ovn-conā€ā€ + troller will not modify the existing datapath-type of the + integration bridge. + + external_ids:ovn-remote + The OVN database that this system should connect to for + its configuration, in one of the same forms documented + above for the ovs-database. + + external_ids:ovn-monitor-all + A boolean value that tells if ovn-controller should moniā€ + tor all records of tables in ovs-database. If set to + false, it will conditionally monitor the records that is + needed in the current chassis. + + It is more efficient to set it to true in use cases where + the chassis would anyway need to monitor most of the + records in OVN Southbound database, which would save the + overhead of conditions processing, especially for server + side. Typically, set it to true for environments that all + workloads need to be reachable from each other. + + Default value is false. + + external_ids:ovn-remote-probe-interval + The inactivity probe interval of the connection to the + OVN database, in milliseconds. If the value is zero, it + disables the connection keepalive feature. + + If the value is nonzero, then it will be forced to a + value of at least 1000 ms. + + external_ids:ovn-openflow-probe-interval + The inactivity probe interval of the OpenFlow connection + to the OpenvSwitch integration bridge, in seconds. If the + value is zero, it disables the connection keepalive feaā€ + ture. + + If the value is nonzero, then it will be forced to a + value of at least 5s. + + external_ids:ovn-encap-type + The encapsulation type that a chassis should use to conā€ + nect to this node. Multiple encapsulation types may be + specified with a comma-separated list. Each listed encapā€ + sulation type will be paired with ovn-encap-ip. + + Supported tunnel types for connecting hypervisors and + gateways are geneve, vxlan, and stt. + + Due to the limited amount of metadata in vxlan, the capaā€ + bilities and performance of connected gateways and hyperā€ + visors will be reduced versus other tunnel formats. + + external_ids:ovn-encap-ip + The IP address that a chassis should use to connect to + this node using encapsulation types specified by exterā€ā€ + nal_ids:ovn-encap-type. + + external_ids:ovn-encap-df_default + indicates the DF flag handling of the encapulation. Set + to true to set the DF flag for new data paths or false to + clear the DF flag. + + external_ids:ovn-bridge-mappings + A list of key-value pairs that map a physical network + name to a local ovs bridge that provides connectivity to + that network. An example value mapping two physical netā€ + work names to two ovs bridges would be: physā€ā€ + net1:br-eth0,physnet2:br-eth1. + + external_ids:ovn-encap-csum + ovn-encap-csum indicates that encapsulation checksums can + be transmitted and received with reasonable performance. + It is a hint to senders transmitting data to this chassis + that they should use checksums to protect OVN metadata. + Set to true to enable or false to disable. Depending on + the capabilities of the network interface card, enabling + encapsulation checksum may incur performance loss. In + such cases, encapsulation checksums can be disabled. + + external_ids:ovn-encap-tos + ovn-encap-tos indicates the value to be applied to OVN + tunnel interfaceā€™s option:tos as specified in the + Open_vSwitch database Interface table. Please refer to + Open VSwitch Manual for details. + + external_ids:ovn-cms-options + A list of options that will be consumed by the CMS Plugin + and which specific to this particular chassis. An example + would be: cms_option1,cms_option2:foo. + + external_ids:ovn-transport-zones + The transport zone(s) that this chassis belongs to. + Transport zones is a way to group different chassis so + that tunnels are only formed between members of the same + group(s). Multiple transport zones may be specified with + a comma-separated list. For example: tz1,tz2,tz3. + + If not set, the Chassis will be considered part of a deā€ + fault transport zone. + + external_ids:ovn-chassis-mac-mappings + A list of key-value pairs that map a chassis specific mac + to a physical network name. An example value mapping two + chassis macs to two physical network names would be: + physnet1:aa:bb:cc:dd:ee:ff,physnet2:a1:b2:c3:d4:e5:f6. + These are the macs that ovn-controller will replace a + router port mac with, if packet is going from a distribā€ + uted router port on vlan type logical switch. + + external_ids:ovn-is-interconn + The boolean flag indicates if the chassis is used as an + interconnection gateway. + + external_ids:ovn-match-northd-version + The boolean flag indicates if ovn-controller needs to + check ovn-northd version. If this flag is set to true and + the ovn-northdā€ā€™s version (reported in the Southbound + database) doesnā€™t match with the ovn-controllerā€ā€™s interā€ + nal version, then it will stop processing the southbound + and local Open vSwitch database changes. The default + value is considered false if this option is not defined. + + external_ids:ovn-ofctrl-wait-before-clear + The time, in milliseconds, to wait before clearing flows + in OVS after OpenFlow connection/reconnection during + ovn-controller initialization. The purpose of this wait + is to give time for ovn-controller to compute the new + flows before clearing existing ones, to avoid data plane + down time during ovn-controller restart/upgrade at large + scale environments where recomputing the flows takes more + than a few seconds or even longer. It is difficult for + ovn-controller to determine when the new flows computing + is completed, because of the dynamics in the cloud enviā€ + ronments, which is why this configuration is provided for + users to adjust based on the scale of the environment. By + default, it is 0, which means clearing existing flows + without waiting. Not setting the value, or setting it too + small, may result in data plane down time during upā€ + grade/restart, while setting it too big may result in unā€ + necessary extra control plane latency of applying new + changes of CMS during upgrade/restart. In most cases, a + slightly bigger value is not harmful, because the extra + control plane latency happens only once during the Openā€ + Flow connection. To get a reasonable range of the value + setting, it is recommended to run the below commands on a + node in the target environment and then set this configuā€ + ration to twice the value of Maximum shown in the output + of the second command. + + ā€¢ ovn-appctl -t ovn-controller inc-engine/recompute + + ā€¢ ovn-appctl -t ovn-controller stopwatch/show + flow-generation + + external_ids:ovn-enable-lflow-cache + The boolean flag indicates if ovn-controller should enā€ + able/disable the logical flow in-memory cache it uses + when processing Southbound database logical flow changes. + By default caching is enabled. + + external_ids:ovn-limit-lflow-cache + When used, this configuration value determines the maxiā€ + mum number of logical flow cache entries ovn-controller + may create when the logical flow cache is enabled. By deā€ + fault the size of the cache is unlimited. + + external_ids:ovn-memlimit-lflow-cache-kb + When used, this configuration value determines the maxiā€ + mum size of the logical flow cache (in KB) ovn-controller + may create when the logical flow cache is enabled. By deā€ + fault the size of the cache is unlimited. + + external_ids:ovn-trim-limit-lflow-cache + When used, this configuration value sets the minimum numā€ + ber of entries in the logical flow cache starting with + which automatic memory trimming is performed. By default + this is set to 10000 entries. + + external_ids:ovn-trim-wmark-perc-lflow-cache + When used, this configuration value sets the percentage + from the high watermark number of entries in the logical + flow cache under which automatic memory trimming is perā€ + formed. E.g., if the trim watermark percentage is set to + 50%, automatic memory trimming happens only when the numā€ + ber of entries in the logical flow cache gets reduced to + less than half of the last measured high watermark. By + default this is set to 50. + + external_ids:ovn-trim-timeout-ms + When used, this configuration value specifies the time, + in milliseconds, since the last logical flow cache operaā€ + tion after which ovn-controller performs memory trimming + regardless of how many entries there are in the cache. By + default this is set to 30000 (30 seconds). + + external_ids:ovn-set-local-ip + The boolean flag indicates if ovn-controller when create + tunnel ports should set local_ip parameter. Can be heplā€ + ful to pin source outer IP for the tunnel when multiple + interfaces are used on the host for overlay traffic. This + is also useful when running multiple ovn-controller inā€ + stances on the same chassis, in which case this setting + will guarantee that their tunnel ports have unique conā€ + figuration and can exist in parallel. + + external_ids:garp-max-timeout-sec + When used, this configuration value specifies the maximum + timeout (in seconds) between two consecutive GARP packets + sent by ovn-controller. ovn-controller by default sends + just 4 GARP packets with an exponential backoff timeout. + Setting external_ids:garp-max-timeout-sec allows to cap + for the exponential backoff used by ovn-controller to + send GARPs packets. + + Most of configuration options listed above can also be set for a parā€ + ticular chassis name (see external_ids:system-id for more informaā€ + tion). This can be achieved by setting external_ids:option-[chassis] + instead of external_ids:option. For example, set external_ids:ovn-enā€ā€ + cap-ip-otherhv to use a particular IP address for the controller inā€ + stance named otherhv. Name specific configuration options always overā€ + ride any global options set in the database. + + Chassis-specific configuration options in the database plus the ability + to configure the chassis name to use via the system-id-override file or + command line allows to run multiple ovn-controller instances with + unique chassis names on the same host using the same vswitchd instance. + This may be useful when running a hybrid setup with more than one CMS + managing ports on the host, or to use different datapath types on the + same host. Make sure you also set external_ids:ovn-set-local-ip when + using such configuration. Also note that this ability is highly experiā€ + mental and has known limitations (for example, stateful ACLs are not + supported). Use at your own risk. + + ovn-controller reads the following values from the Open_vSwitch dataā€ + base of the local OVS instance: + + datapath-type from Bridge table + This value is read from local OVS integration bridge row + of Bridge table and populated in other_config:datapath- + type of the Chassis table in the OVN_Southbound database. + + iface-types from Open_vSwitch table + This value is populated in external_ids:iface-types of + the Chassis table in the OVN_Southbound database. + + private_key, certificate, ca_cert, and bootstrap_ca_cert from + SSL table + These values provide the SSL configuration used for conā€ + necting to the OVN southbound database server when an SSL + connection type is configured via external_ids:ovn-reā€ā€ + mote. Note that this SSL configuration can also be proā€ + vided via command-line options, the configuration in the + database takes precedence if both are present. + +OPEN VSWITCH DATABASE USAGE + ovn-controller uses a number of external_ids keys in the Open vSwitch + database to keep track of ports and interfaces. For proper operation, + users should not change or clear these keys: + + external_ids:ovn-chassis-id in the Port table + The presence of this key identifies a tunnel port within + the integration bridge as one created by ovn-controller + to reach a remote chassis. Its value is the chassis ID of + the remote chassis. + + external_ids:ct-zone-* in the Bridge table + Logical ports and gateway routers are assigned a connecā€ + tion tracking zone by ovn-controller for stateful serā€ + vices. To keep state across restarts of ovn-controller, + these keys are stored in the integration bridgeā€™s Bridge + table. The name contains a prefix of ct-zone- followed by + the name of the logical port or gateway routerā€™s zone + key. The value for this key identifies the zone used for + this port. + + external_ids:ovn-localnet-port in the Port table + The presence of this key identifies a patch port as one + created by ovn-controller to connect the integration + bridge and another bridge to implement a localnet logical + port. Its value is the name of the logical port with type + set to localnet that the port implements. See exterā€ā€ + nal_ids:ovn-bridge-mappings, above, for more information. + + Each localnet logical port is implemented as a pair of + patch ports, one in the integration bridge, one in a difā€ + ferent bridge, with the same external_ids:ovn-localā€ā€ + net-port value. + + external_ids:ovn-l2gateway-port in the Port table + The presence of this key identifies a patch port as one + created by ovn-controller to connect the integration + bridge and another bridge to implement a l2gateway logiā€ + cal port. Its value is the name of the logical port with + type set to l2gateway that the port implements. See exā€ā€ + ternal_ids:ovn-bridge-mappings, above, for more informaā€ + tion. + + Each l2gateway logical port is implemented as a pair of + patch ports, one in the integration bridge, one in a difā€ + ferent bridge, with the same external_ids:ovn-l2gateā€ā€ + way-port value. + + external-ids:ovn-l3gateway-port in the Port table + This key identifies a patch port as one created by + ovn-controller to implement a l3gateway logical port. Its + value is the name of the logical port with type set to + l3gateway. This patch port is similar to the OVN logical + patch port, except that l3gateway port can only be bound + to a particular chassis. + + external-ids:ovn-logical-patch-port in the Port table + This key identifies a patch port as one created by + ovn-controller to implement an OVN logical patch port + within the integration bridge. Its value is the name of + the OVN logical patch port that it implements. + + external-ids:ovn-startup-ts in the Bridge table + This key represents the timestamp (in milliseconds) at + which ovn-controller process was started. + + external-ids:ovn-nb-cfg in the Bridge table + This key represents the last known OVN_Southā€ā€ + bound.SB_Global.nb_cfg value for which all flows have + been successfully installed in OVS. + + external-ids:ovn-nb-cfg-ts in the Bridge table + This key represents the timestamp (in milliseconds) of + the last known OVN_Southbound.SB_Global.nb_cfg value for + which all flows have been successfully installed in OVS. + + external_ids:ovn-installed and external_ids:ovn-installed-ts in + the Interface table + This key is set after all openflow operations correspondā€ + ing to the OVS interface have been processed by ovs- + vswitchd. At the same time a timestamp, in milliseconds + since the epoch, is stored in external_ids:ovn-inā€ā€ + stalled-ts. + +OVN SOUTHBOUND DATABASE USAGE + ovn-controller reads from much of the OVN_Southbound database to guide + its operation. ovn-controller also writes to the following tables: + + Chassis + Upon startup, ovn-controller creates a row in this table + to represent its own chassis. Upon graceful termination, + e.g. with ovs-appctl -t ovn-controller exit (but not + SIGTERM), ovn-controller removes its row. + + Encap Upon startup, ovn-controller creates a row or rows in + this table that represent the tunnel encapsulations by + which its chassis can be reached, and points its Chassis + row to them. Upon graceful termination, ovn-controller + removes these rows. + + Port_Binding + At runtime, ovn-controller sets the chassis columns of + ports that are resident on its chassis to point to its + Chassis row, and, conversely, clears the chassis column + of ports that point to its Chassis row but are no longer + resident on its chassis. The chassis column has a weak + reference type, so when ovn-controller gracefully exits + and removes its Chassis row, the database server automatā€ + ically clears any remaining references to that row. + + MAC_Binding + At runtime, ovn-controller updates the MAC_Binding table + as instructed by put_arp and put_nd logical actions. + These changes persist beyond the lifetime of ovn-conā€ā€ + troller. + +RUNTIME MANAGEMENT COMMANDS + ovs-appctl can send commands to a running ovn-controller process. The + currently supported commands are described below. + + exit Causes ovn-controller to gracefully terminate. + + ct-zone-list + Lists each local logical port and its connection tracking + zone. + + meter-table-list + Lists each meter table entry and its local meter id. + + group-table-list + Lists each group table entry and its local group id. + + inject-pkt microflow + Injects microflow into the connected Open vSwitch inā€ + stance. microflow must contain an ingress logical port + (inport argument) that is present on the Open vSwitch inā€ + stance. + + The microflow argument describes the packet whose forā€ + warding is to be simulated, in the syntax of an OVN logiā€ + cal expression, as described in ovn-sb(5), to express + constraints. The parser understands prerequisites; for + example, if the expression refers to ip4.src, there is no + need to explicitly state ip4 or eth.type == 0x800. + + connection-status + Show OVN SBDB connection status for the chassis. + + recompute + Trigger a full compute iteration in ovn-controller based + on the contents of the Southbound database and local OVS + database. + + This command is intended to use only in the event of a + bug in the incremental processing engine in ovn-conā€ā€ + troller to avoid inconsistent states. It should therefore + be used with care as full recomputes are cpu intensive. + + sb-cluster-state-reset + Reset southbound database cluster status when databases + are destroyed and rebuilt. + + If all databases in a clustered southbound database are + removed from disk, then the stored index of all databases + will be reset to zero. This will cause ovn-controller to + be unable to read or write to the southbound database, + because it will always detect the data as stale. In such + a case, run this command so that ovn-controller will reā€ + set its local index so that it can interact with the + southbound database again. + + debug/delay-nb-cfg-report seconds + This command is used to delay ovn-controller updating the + nb_cfg back to OVN_Southbound database. This is useful + when ovn-nbctl --wait=hv is used to measure end-to-end + latency in a large scale environment. See ovn-nbctl(8) + for more details. + + lflow-cache/flush + Flushes the ovn-controller logical flow cache. + + lflow-cache/show-stats + Displays logical flow cache statistics: enabled/disabled, + per cache type entry counts. + + inc-engine/show-stats + Display ovn-controller engine counters. For each engine + node the following counters have been added: + + ā€¢ recompute + + ā€¢ compute + + ā€¢ abort + + inc-engine/show-stats engine_node_name counter_name + Display the ovn-controller engine counter(s) for the + specified engine_node_name. counter_name is optional and + can be one of recompute, compute or abort. + + inc-engine/clear-stats + Reset ovn-controller engine counters. + +OVN 23.06.3 ovn-controller ovn-controller(8) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ctl.8 b/src/static/support/dist-docs-branch-23.06/ovn-ctl.8 new file mode 100644 index 00000000..002ebcb8 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ctl.8 @@ -0,0 +1,426 @@ +'\" p +.\" -*- nroff -*- +.TH "ovn-ctl" 8 "ovn-ctl" "OVN 23\[char46]06\[char46]3" "OVN Manual" +.fp 5 L CR \\" Make fixed-width font available as \\fL. +.de TQ +. br +. ns +. TP "\\$1" +.. +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +.de SU +. PP +. I "\\$1" +.. +.PP +.SH "NAME" +.PP +.PP +ovn-ctl \- Open Virtual Network northbound daemon lifecycle utility +.SH "SYNOPSIS" +.PP +.PP +\fBovn\-ctl\fR [\fIoptions\fR] \fIcommand\fR [\-- \fIextra_args\fR] +.SH "DESCRIPTION" +.PP +.PP +This program is intended to be invoked internally by Open Virtual Network startup scripts\[char46] System administrators should not normally invoke it directly\[char46] +.SH "COMMANDS" +.TP +\fBstart_northd\fR +.TQ .5in +\fBstart_controller\fR +.TQ .5in +\fBstart_controller_vtep\fR +.TQ .5in +\fBstart_ic\fR +.TQ .5in +\fBstop_northd\fR +.TQ .5in +\fBstop_controller\fR +.TQ .5in +\fBstop_controller_vtep\fR +.TQ .5in +\fBstop_ic\fR +.TQ .5in +\fBrestart_northd\fR +.TQ .5in +\fBrestart_controller\fR +.TQ .5in +\fBrestart_controller_vtep\fR +.TQ .5in +\fBrestart_ic\fR +.TQ .5in +\fBpromote_ovnnb\fR +.TQ .5in +\fBpromote_ovnsb\fR +.TQ .5in +\fBdemote_ovnnb\fR +.TQ .5in +\fBdemote_ovnsb\fR +.TQ .5in +\fBstatus_ovnnb\fR +.TQ .5in +\fBstatus_ovnsb\fR +.TQ .5in +\fBstart_ovsdb\fR +.TQ .5in +\fBstart_nb_ovsdb\fR +.TQ .5in +\fBstart_sb_ovsdb\fR +.TQ .5in +\fBstop_ovsdb\fR +.TQ .5in +\fBstop_nb_ovsdb\fR +.TQ .5in +\fBstop_sb_ovsdb\fR +.TQ .5in +\fBrestart_ovsdb\fR +.TQ .5in +\fBrun_nb_ovsdb\fR +.TQ .5in +\fBrun_sb_ovsdb\fR +.TQ .5in +\fBpromote_ic_nb\fR +.TQ .5in +\fBpromote_ic_sb\fR +.TQ .5in +\fBdemote_ic_nb\fR +.TQ .5in +\fBdemote_ic_sb\fR +.TQ .5in +\fBstatus_ic_nb\fR +.TQ .5in +\fBstatus_ic_sb\fR +.TQ .5in +\fBstart_ic_ovsdb\fR +.TQ .5in +\fBstart_ic_nb_ovsdb\fR +.TQ .5in +\fBstart_ic_sb_ovsdb\fR +.TQ .5in +\fBstop_ic_ovsdb\fR +.TQ .5in +\fBstop_ic_nb_ovsdb\fR +.TQ .5in +\fBstop_ic_sb_ovsdb\fR +.TQ .5in +\fBrestart_ic_ovsdb\fR +.TQ .5in +\fBrun_ic_nb_ovsdb\fR +.TQ .5in +\fBrun_ic_sb_ovsdb\fR +.SH "OPTIONS" +.PP +\fB\-\-ovn\-northd\-priority=\fINICE\fB\fR +.PP +\fB\-\-ovn\-northd\-wrapper=\fIWRAPPER\fB\fR +.PP +\fB\-\-ovn\-controller\-priority=\fINICE\fB\fR +.PP +\fB\-\-ovn\-controller\-wrapper=\fIWRAPPER\fB\fR +.PP +\fB\-\-ovn\-ic\-priority=\fINICE\fB\fR +.PP +\fB\-\-ovn\-ic\-wrapper=\fIWRAPPER\fB\fR +.PP +\fB\-\-ovsdb\-nb\-wrapper=\fIWRAPPER\fB\fR +.PP +\fB\-\-ovsdb\-sb\-wrapper=\fIWRAPPER\fB\fR +.PP +\fB\-\-ovn\-user=\fIUSER:GROUP\fB\fR +.PP +\fB\-\-ovs\-user=\fIUSER:GROUP\fB\fR +.PP +\fB\-h\fR | \fB\-\-help\fR +.SH "FILE LOCATION OPTIONS" +.PP +\fB\-\-db\-sock=\fISOCKET\fB\fR +.PP +\fB\-\-db\-nb\-file=\fIFILE\fB\fR +.PP +\fB\-\-db\-sb\-file=\fIFILE\fB\fR +.PP +\fB\-\-db\-nb\-schema=\fIFILE\fB\fR +.PP +\fB\-\-db\-sb\-schema=\fIFILE\fB\fR +.PP +\fB\-\-db\-sb\-create\-insecure\-remote=\fIyes|no\fB\fR +.PP +\fB\-\-db\-nb\-create\-insecure\-remote=\fIyes|no\fB\fR +.PP +\fB\-\-db\-ic\-nb\-file=\fIFILE\fB\fR +.PP +\fB\-\-db\-ic\-sb\-file=\fIFILE\fB\fR +.PP +\fB\-\-db\-ic\-nb\-schema=\fIFILE\fB\fR +.PP +\fB\-\-db\-ic\-sb\-schema=\fIFILE\fB\fR +.PP +\fB\-\-db\-ic\-sb\-create\-insecure\-remote=\fIyes|no\fB\fR +.PP +\fB\-\-db\-ic\-nb\-create\-insecure\-remote=\fIyes|no\fB\fR +.PP +\fB\-\-ovn\-controller\-ssl\-key=\fIKEY\fB\fR +.PP +\fB\-\-ovn\-controller\-ssl\-cert=\fICERT\fB\fR +.PP +\fB\-\-ovn\-controller\-ssl\-ca\-cert=\fICERT\fB\fR +.PP +\fB\-\-ovn\-controller\-ssl\-bootstrap\-ca\-cert=\fICERT\fB\fR +.SH "ADDRESS AND PORT OPTIONS" +.PP +\fB\-\-db\-nb\-sync\-from\-addr=\fIIP ADDRESS\fB\fR +.PP +\fB\-\-db\-nb\-sync\-from\-port=\fIPORT NUMBER\fB\fR +.PP +\fB\-\-db\-nb\-sync\-from\-proto=\fIPROTO\fB\fR +.PP +\fB\-\-db\-sb\-sync\-from\-addr=\fIIP ADDRESS\fB\fR +.PP +\fB\-\-db\-sb\-sync\-from\-port=\fIPORT NUMBER\fB\fR +.PP +\fB\-\-db\-sb\-sync\-from\-proto=\fIPROTO\fB\fR +.PP +\fB\-\-db\-ic\-nb\-sync\-from\-addr=\fIIP ADDRESS\fB\fR +.PP +\fB\-\-db\-ic\-nb\-sync\-from\-port=\fIPORT NUMBER\fB\fR +.PP +\fB\-\-db\-ic\-nb\-sync\-from\-proto=\fIPROTO\fB\fR +.PP +\fB\-\-db\-ic\-sb\-sync\-from\-addr=\fIIP ADDRESS\fB\fR +.PP +\fB\-\-db\-ic\-sb\-sync\-from\-port=\fIPORT NUMBER\fB\fR +.PP +\fB\-\-db\-ic\-sb\-sync\-from\-proto=\fIPROTO\fB\fR +.PP +.PP +\fB +\-\-ovn\-northd\-nb\-db=\fIPROTO\fB:\fIIP ADDRESS\fB: +\fIPORT\fB\[char46]\[char46] +\fR +.PP +.PP +\fB +\-\-ovn\-northd\-sb\-db=\fIPROTO\fB:\fIIP ADDRESS\fB: +\fIPORT\fB\[char46]\[char46] +\fR +.PP +.PP +\fB +\-\-ovn\-ic\-nb\-db=\fIPROTO\fB:\fIIP ADDRESS\fB: +\fIPORT\fB\[char46]\[char46] +\fR +.PP +.PP +\fB +\-\-ovn\-ic\-sb\-db=\fIPROTO\fB:\fIIP ADDRESS\fB: +\fIPORT\fB\[char46]\[char46] +\fR +.SH "CLUSTERING OPTIONS" +.PP +\fB\-\-db\-nb\-cluster\-local\-addr=\fIIP ADDRESS\fB\fR +.PP +\fB\-\-db\-nb\-cluster\-local\-port=\fIPORT NUMBER\fB\fR +.PP +\fB\-\-db\-nb\-cluster\-local\-proto=\fIPROTO (tcp/ssl)\fB\fR +.PP +\fB\-\-db\-nb\-cluster\-remote\-addr=\fIIP ADDRESS\fB\fR +.PP +\fB\-\-db\-nb\-cluster\-remote\-port=\fIPORT NUMBER\fB\fR +.PP +\fB\-\-db\-nb\-cluster\-remote\-proto=\fIPROTO (tcp/ssl)\fB\fR +.PP +\fB\-\-db\-nb\-election\-timer=\fITimeout in milliseconds\fB\fR +.PP +\fB\-\-db\-sb\-cluster\-local\-addr=\fIIP ADDRESS\fB\fR +.PP +\fB\-\-db\-sb\-cluster\-local\-port=\fIPORT NUMBER\fB\fR +.PP +\fB\-\-db\-sb\-cluster\-local\-proto=\fIPROTO (tcp/ssl)\fB\fR +.PP +\fB\-\-db\-sb\-cluster\-remote\-addr=\fIIP ADDRESS\fB\fR +.PP +\fB\-\-db\-sb\-cluster\-remote\-port=\fIPORT NUMBER\fB\fR +.PP +\fB\-\-db\-sb\-cluster\-remote\-proto=\fIPROTO (tcp/ssl)\fB\fR +.PP +\fB\-\-db\-sb\-election\-timer=\fITimeout in milliseconds\fB\fR +.PP +\fB\-\-db\-ic\-nb\-cluster\-local\-addr=\fIIP ADDRESS\fB\fR +.PP +\fB\-\-db\-ic\-nb\-cluster\-local\-port=\fIPORT NUMBER\fB\fR +.PP +\fB\-\-db\-ic\-nb\-cluster\-local\-proto=\fIPROTO (tcp/ssl)\fB\fR +.PP +\fB\-\-db\-ic\-nb\-cluster\-remote\-addr=\fIIP ADDRESS\fB\fR +.PP +\fB\-\-db\-ic\-nb\-cluster\-remote\-port=\fIPORT NUMBER\fB\fR +.PP +\fB\-\-db\-ic\-nb\-cluster\-remote\-proto=\fIPROTO (tcp/ssl)\fB\fR +.PP +\fB\-\-db\-ic\-sb\-cluster\-local\-addr=\fIIP ADDRESS\fB\fR +.PP +\fB\-\-db\-ic\-sb\-cluster\-local\-port=\fIPORT NUMBER\fB\fR +.PP +\fB\-\-db\-ic\-sb\-cluster\-local\-proto=\fIPROTO (tcp/ssl)\fB\fR +.PP +\fB\-\-db\-ic\-sb\-cluster\-remote\-addr=\fIIP ADDRESS\fB\fR +.PP +\fB\-\-db\-ic\-sb\-cluster\-remote\-port=\fIPORT NUMBER\fB\fR +.PP +\fB\-\-db\-ic\-sb\-cluster\-remote\-proto=\fIPROTO (tcp/ssl)\fB\fR +.SH "PROBE INTERVAL OPTIONS" +.PP +\fB\-\-db\-nb\-probe\-interval\-to\-active=\fITime in milliseconds\fB\fR +.PP +\fB\-\-db\-sb\-probe\-interval\-to\-active=\fITime in milliseconds\fB\fR +.SH "EXTRA OPTIONS" +.PP +.PP +Any options after \(cq\-\(cq will be passed on to the binary run by \fIcommand\fR with the exception of start_northd, which can have options specified in ovn-northd-db-params\[char46]conf\[char46] Any \fIextra_args\fR passed to start_northd will be passed to the ovsdb-servers if \fB\-\-ovn\-manage\-ovsdb=yes\fR +.SH "CONFIGURATION FILES" +.PP +.PP +Following are the optional configuration files\[char46] If present, it should be located in the etc dir +.SS "ovnnb\-active\[char46]conf" +.PP +.PP +If present, this file should hold the url to connect to the active Northbound DB server +.PP +\fBtcp:x\[char46]x\[char46]x\[char46]x:6641\fR +.SS "ovnsb\-active\[char46]conf" +.PP +.PP +If present, this file should hold the url to connect to the active Southbound DB server +.PP +\fBtcp:x\[char46]x\[char46]x\[char46]x:6642\fR +.SS "ovn\-northd\-db\-params\[char46]conf" +.PP +.PP +If present, start_northd will not start the DB server even if \fB\-\-ovn\-manage\-ovsdb=yes\fR\[char46] This file should hold the database url parameters to be passed to ovn-northd\[char46] +.PP +\fB\-\-ovnnb\-db=tcp:x\[char46]x\[char46]x\[char46]x:6641 \-\-ovnsb\-db=tcp:x\[char46]x\[char46]x\[char46]x:6642\fR +.SS "ic\-nb\-active\[char46]conf" +.PP +.PP +If present, this file should hold the url to connect to the active Interconnection Northbound DB server +.PP +\fBtcp:x\[char46]x\[char46]x\[char46]x:6645\fR +.SS "ic\-sb\-active\[char46]conf" +.PP +.PP +If present, this file should hold the url to connect to the active Interconnection Southbound DB server +.PP +\fBtcp:x\[char46]x\[char46]x\[char46]x:6646\fR +.SS "ovn\-ic\-db\-params\[char46]conf" +.PP +.PP +If present, this file should hold the database url parameters to be passed to ovn-ic\[char46] +.PP +\fB\-\-ic\-nb\-db=tcp:x\[char46]x\[char46]x\[char46]x:6645 \-\-ic\-sb\-db=tcp:x\[char46]x\[char46]x\[char46]x:6646\fR +.SH "RUNNING OVN DB SERVERS WITHOUT DETACHING" +.PP +\fB# ovn\-ctl run_nb_ovsdb\fR +.PP +.PP +This command runs the OVN nb ovsdb-server without passing the \fBdetach\fR option, making it to block until ovsdb-server exits\[char46] This command will be useful for starting the OVN nb ovsdb-server in a container\[char46] +.PP +\fB# ovn\-ctl run_sb_ovsdb\fR +.PP +.PP +This command runs the OVN sb ovsdb-server without passing the \fBdetach\fR option, making it to block until ovsdb-server exits\[char46] This command will be useful for starting the OVN sb ovsdb-server in a container\[char46] +.PP +\fB# ovn\-ctl run_ic_nb_ovsdb\fR +.PP +.PP +This command runs the OVN IC-NB ovsdb-server without passing the \fBdetach\fR option, making it to block until ovsdb-server exits\[char46] This command will be useful for starting the OVN IC-NB ovsdb-server in a container\[char46] +.PP +\fB# ovn\-ctl run_ic_sb_ovsdb\fR +.PP +.PP +This command runs the OVN IC-SB ovsdb-server without passing the \fBdetach\fR option, making it to block until ovsdb-server exits\[char46] This command will be useful for starting the OVN IC-SB ovsdb-server in a container\[char46] +.SH "EXAMPLE USAGE" +.SS "Run ovn\-controller on a host already running OVS" +.PP +\fB# ovn\-ctl start_controller\fR +.SS "Run ovn\-northd on a host already running OVS" +.PP +\fB# ovn\-ctl start_northd\fR +.SS "All\-in\-one OVS+OVN for testing" +.PP +\fB# ovs\-ctl start \-\-system\-id=\(dqrandom\(dq\fR +.PP +\fB# ovn\-ctl start_northd\fR +.PP +\fB# ovn\-ctl start_controller\fR +.SS "Promote and demote ovsdb servers" +.PP +\fB# ovn\-ctl promote_ovnnb\fR +.PP +\fB# ovn\-ctl promote_ovnsb\fR +.PP +\fB# ovn\-ctl \-\-db\-nb\-sync\-from\-addr=x\[char46]x\[char46]x\[char46]x \-\-db\-nb\-sync\-from\-port=6641 \-\-db\-nb\-probe\-interval\-to\-active=60000 demote_ovnnb\fR +.PP +\fB# ovn\-ctl \-\-db\-sb\-sync\-from\-addr=x\[char46]x\[char46]x\[char46]x \-\-db\-sb\-sync\-from\-port=6642 \-\-db\-sb\-probe\-interval\-to\-active=60000 demote_ovnsb\fR +.SS "Creating a clustered db on 3 nodes with IPs x\[char46]x\[char46]x\[char46]x, y\[char46]y\[char46]y\[char46]y and z\[char46]z\[char46]z\[char46]z" +.ST "Starting OVN ovsdb servers and ovn-northd on the node with IP x\[char46]x\[char46]x\[char46]x" +.PP +.PP +\fB +# ovn\-ctl \-\-db\-nb\-addr=x\[char46]x\[char46]x\[char46]x \-\-db\-nb\-create\-insecure\-remote=yes +\-\-db\-sb\-addr=x\[char46]x\[char46]x\[char46]x \-\-db\-sb\-create\-insecure\-remote=yes +\-\-db\-nb\-cluster\-local\-addr=x\[char46]x\[char46]x\[char46]x +\-\-db\-sb\-cluster\-local\-addr=x\[char46]x\[char46]x\[char46]x +\-\-ovn\-northd\-nb\-db=tcp:x\[char46]x\[char46]x\[char46]x:6641,tcp:y\[char46]y\[char46]y\[char46]y:6641,tcp:z\[char46]z\[char46]z\[char46]z:6641 +\-\-ovn\-northd\-sb\-db=tcp:x\[char46]x\[char46]x\[char46]x:6642,tcp:y\[char46]y\[char46]y\[char46]y:6642,tcp:z\[char46]z\[char46]z\[char46]z:6642 +start_northd +\fR +.ST "Starting OVN ovsdb-servers and ovn-northd on the node with IP y\[char46]y\[char46]y\[char46]y and joining the cluster started at x\[char46]x\[char46]x\[char46]x" +.PP +.PP +\fB +# ovn\-ctl \-\-db\-nb\-addr=y\[char46]y\[char46]y\[char46]y \-\-db\-nb\-create\-insecure\-remote=yes +\-\-db\-sb\-addr=y\[char46]y\[char46]y\[char46]y \-\-db\-sb\-create\-insecure\-remote=yes +\-\-db\-nb\-cluster\-local\-addr=y\[char46]y\[char46]y\[char46]y +\-\-db\-sb\-cluster\-local\-addr=y\[char46]y\[char46]y\[char46]y +\-\-db\-nb\-cluster\-remote\-addr=x\[char46]x\[char46]x\[char46]x +\-\-db\-sb\-cluster\-remote\-addr=x\[char46]x\[char46]x\[char46]x +\-\-ovn\-northd\-nb\-db=tcp:x\[char46]x\[char46]x\[char46]x:6641,tcp:y\[char46]y\[char46]y\[char46]y:6641,tcp:z\[char46]z\[char46]z\[char46]z:6641 +\-\-ovn\-northd\-sb\-db=tcp:x\[char46]x\[char46]x\[char46]x:6642,tcp:y\[char46]y\[char46]y\[char46]y:6642,tcp:z\[char46]z\[char46]z\[char46]z:6642 +start_northd +\fR +.ST "Starting OVN ovsdb-servers and ovn-northd on the node with IP z\[char46]z\[char46]z\[char46]z and joining the cluster started at x\[char46]x\[char46]x\[char46]x" +.PP +.PP +\fB +# ovn\-ctl \-\-db\-nb\-addr=z\[char46]z\[char46]z\[char46]z +\-\-db\-nb\-create\-insecure\-remote=yes +\-\-db\-nb\-cluster\-local\-addr=z\[char46]z\[char46]z\[char46]z +\-\-db\-sb\-addr=z\[char46]z\[char46]z\[char46]z +\-\-db\-sb\-create\-insecure\-remote=yes +\-\-db\-sb\-cluster\-local\-addr=z\[char46]z\[char46]z\[char46]z +\-\-db\-nb\-cluster\-remote\-addr=x\[char46]x\[char46]x\[char46]x +\-\-db\-sb\-cluster\-remote\-addr=x\[char46]x\[char46]x\[char46]x +\-\-ovn\-northd\-nb\-db=tcp:x\[char46]x\[char46]x\[char46]x:6641,tcp:y\[char46]y\[char46]y\[char46]y:6641,tcp:z\[char46]z\[char46]z\[char46]z:6641 +\-\-ovn\-northd\-sb\-db=tcp:x\[char46]x\[char46]x\[char46]x:6642,tcp:y\[char46]y\[char46]y\[char46]y:6642,tcp:z\[char46]z\[char46]z\[char46]z:6642 +start_northd +\fR +.SS "Passing ssl keys when starting OVN dbs will supersede the default ssl values in db" +.ST "Starting standalone ovn db server passing SSL certificates" +.PP +.PP +\fB +# ovn\-ctl \-\-ovn\-nb\-db\-ssl\-key=/etc/ovn/ovnnb\-privkey\[char46]pem +\-\-ovn\-nb\-db\-ssl\-cert=/etc/ovn/ovnnb\-cert\[char46]pem +\-\-ovn\-nb\-db\-ssl\-ca\-cert=/etc/ovn/cacert\[char46]pem +\-\-ovn\-sb\-db\-ssl\-key=/etc/ovn/ovnsb\-privkey\[char46]pem +\-\-ovn\-sb\-db\-ssl\-cert=/etc/ovn/ovnsb\-cert\[char46]pem +\-\-ovn\-sb\-db\-ssl\-ca\-cert=/etc/ovn/cacert\[char46]pem +start_northd +\fR diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ctl.8.html b/src/static/support/dist-docs-branch-23.06/ovn-ctl.8.html new file mode 100644 index 00000000..bc4b7266 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ctl.8.html @@ -0,0 +1,349 @@ +
+ovn-ctl(8)                        OVN Manual                        ovn-ctl(8)
+
+NAME
+       ovn-ctl - Open Virtual Network northbound daemon lifecycle utility
+
+SYNOPSIS
+       ovn-ctl [options] command [-- extra_args]
+
+DESCRIPTION
+       This  program is intended to be invoked internally by Open Virtual Netā€
+       work startup scripts. System administrators should not normally  invoke
+       it directly.
+
+COMMANDS
+       start_northd
+       start_controller
+       start_controller_vtep
+       start_ic
+       stop_northd
+       stop_controller
+       stop_controller_vtep
+       stop_ic
+       restart_northd
+       restart_controller
+       restart_controller_vtep
+       restart_ic
+       promote_ovnnb
+       promote_ovnsb
+       demote_ovnnb
+       demote_ovnsb
+       status_ovnnb
+       status_ovnsb
+       start_ovsdb
+       start_nb_ovsdb
+       start_sb_ovsdb
+       stop_ovsdb
+       stop_nb_ovsdb
+       stop_sb_ovsdb
+       restart_ovsdb
+       run_nb_ovsdb
+       run_sb_ovsdb
+       promote_ic_nb
+       promote_ic_sb
+       demote_ic_nb
+       demote_ic_sb
+       status_ic_nb
+       status_ic_sb
+       start_ic_ovsdb
+       start_ic_nb_ovsdb
+       start_ic_sb_ovsdb
+       stop_ic_ovsdb
+       stop_ic_nb_ovsdb
+       stop_ic_sb_ovsdb
+       restart_ic_ovsdb
+       run_ic_nb_ovsdb
+       run_ic_sb_ovsdb
+
+OPTIONS
+       --ovn-northd-priority=NICE
+
+       --ovn-northd-wrapper=WRAPPER
+
+       --ovn-controller-priority=NICE
+
+       --ovn-controller-wrapper=WRAPPER
+
+       --ovn-ic-priority=NICE
+
+       --ovn-ic-wrapper=WRAPPER
+
+       --ovsdb-nb-wrapper=WRAPPER
+
+       --ovsdb-sb-wrapper=WRAPPER
+
+       --ovn-user=USER:GROUP
+
+       --ovs-user=USER:GROUP
+
+       -h | --help
+
+FILE LOCATION OPTIONS
+       --db-sock=SOCKET
+
+       --db-nb-file=FILE
+
+       --db-sb-file=FILE
+
+       --db-nb-schema=FILE
+
+       --db-sb-schema=FILE
+
+       --db-sb-create-insecure-remote=yes|no
+
+       --db-nb-create-insecure-remote=yes|no
+
+       --db-ic-nb-file=FILE
+
+       --db-ic-sb-file=FILE
+
+       --db-ic-nb-schema=FILE
+
+       --db-ic-sb-schema=FILE
+
+       --db-ic-sb-create-insecure-remote=yes|no
+
+       --db-ic-nb-create-insecure-remote=yes|no
+
+       --ovn-controller-ssl-key=KEY
+
+       --ovn-controller-ssl-cert=CERT
+
+       --ovn-controller-ssl-ca-cert=CERT
+
+       --ovn-controller-ssl-bootstrap-ca-cert=CERT
+
+ADDRESS AND PORT OPTIONS
+       --db-nb-sync-from-addr=IP ADDRESS
+
+       --db-nb-sync-from-port=PORT NUMBER
+
+       --db-nb-sync-from-proto=PROTO
+
+       --db-sb-sync-from-addr=IP ADDRESS
+
+       --db-sb-sync-from-port=PORT NUMBER
+
+       --db-sb-sync-from-proto=PROTO
+
+       --db-ic-nb-sync-from-addr=IP ADDRESS
+
+       --db-ic-nb-sync-from-port=PORT NUMBER
+
+       --db-ic-nb-sync-from-proto=PROTO
+
+       --db-ic-sb-sync-from-addr=IP ADDRESS
+
+       --db-ic-sb-sync-from-port=PORT NUMBER
+
+       --db-ic-sb-sync-from-proto=PROTO
+
+        --ovn-northd-nb-db=PROTO:IP ADDRESS: PORT..
+
+        --ovn-northd-sb-db=PROTO:IP ADDRESS: PORT..
+
+        --ovn-ic-nb-db=PROTO:IP ADDRESS: PORT..
+
+        --ovn-ic-sb-db=PROTO:IP ADDRESS: PORT..
+
+CLUSTERING OPTIONS
+       --db-nb-cluster-local-addr=IP ADDRESS
+
+       --db-nb-cluster-local-port=PORT NUMBER
+
+       --db-nb-cluster-local-proto=PROTO (tcp/ssl)
+
+       --db-nb-cluster-remote-addr=IP ADDRESS
+
+       --db-nb-cluster-remote-port=PORT NUMBER
+
+       --db-nb-cluster-remote-proto=PROTO (tcp/ssl)
+
+       --db-nb-election-timer=Timeout in milliseconds
+
+       --db-sb-cluster-local-addr=IP ADDRESS
+
+       --db-sb-cluster-local-port=PORT NUMBER
+
+       --db-sb-cluster-local-proto=PROTO (tcp/ssl)
+
+       --db-sb-cluster-remote-addr=IP ADDRESS
+
+       --db-sb-cluster-remote-port=PORT NUMBER
+
+       --db-sb-cluster-remote-proto=PROTO (tcp/ssl)
+
+       --db-sb-election-timer=Timeout in milliseconds
+
+       --db-ic-nb-cluster-local-addr=IP ADDRESS
+
+       --db-ic-nb-cluster-local-port=PORT NUMBER
+
+       --db-ic-nb-cluster-local-proto=PROTO (tcp/ssl)
+
+       --db-ic-nb-cluster-remote-addr=IP ADDRESS
+
+       --db-ic-nb-cluster-remote-port=PORT NUMBER
+
+       --db-ic-nb-cluster-remote-proto=PROTO (tcp/ssl)
+
+       --db-ic-sb-cluster-local-addr=IP ADDRESS
+
+       --db-ic-sb-cluster-local-port=PORT NUMBER
+
+       --db-ic-sb-cluster-local-proto=PROTO (tcp/ssl)
+
+       --db-ic-sb-cluster-remote-addr=IP ADDRESS
+
+       --db-ic-sb-cluster-remote-port=PORT NUMBER
+
+       --db-ic-sb-cluster-remote-proto=PROTO (tcp/ssl)
+
+PROBE INTERVAL OPTIONS
+       --db-nb-probe-interval-to-active=Time in milliseconds
+
+       --db-sb-probe-interval-to-active=Time in milliseconds
+
+EXTRA OPTIONS
+       Any  options  after  ā€™-ā€™ will be passed on to the binary run by command
+       with the exception of start_northd, which can have options specified in
+       ovn-northd-db-params.conf. Any extra_args passed to  start_northd  will
+       be passed to the ovsdb-servers if --ovn-manage-ovsdb=yes
+
+CONFIGURATION FILES
+       Following  are  the optional configuration files. If present, it should
+       be located in the etc dir
+
+   ovnnb-active.conf
+       If present, this file should hold the url  to  connect  to  the  active
+       Northbound DB server
+
+       tcp:x.x.x.x:6641
+
+   ovnsb-active.conf
+       If  present,  this  file  should  hold the url to connect to the active
+       Southbound DB server
+
+       tcp:x.x.x.x:6642
+
+   ovn-northd-db-params.conf
+       If  present,  start_northd  will  not  start  the  DB  server  even  if
+       --ovn-manage-ovsdb=yes.  This file should hold the database url parameā€
+       ters to be passed to ovn-northd.
+
+       --ovnnb-db=tcp:x.x.x.x:6641 --ovnsb-db=tcp:x.x.x.x:6642
+
+   ic-nb-active.conf
+       If present, this file should hold the url to connect to the active  Inā€
+       terconnection Northbound DB server
+
+       tcp:x.x.x.x:6645
+
+   ic-sb-active.conf
+       If  present, this file should hold the url to connect to the active Inā€
+       terconnection Southbound DB server
+
+       tcp:x.x.x.x:6646
+
+   ovn-ic-db-params.conf
+       If present, this file should hold the database  url  parameters  to  be
+       passed to ovn-ic.
+
+       --ic-nb-db=tcp:x.x.x.x:6645 --ic-sb-db=tcp:x.x.x.x:6646
+
+RUNNING OVN DB SERVERS WITHOUT DETACHING
+       # ovn-ctl run_nb_ovsdb
+
+       This  command  runs  the OVN nb ovsdb-server without passing the detach
+       option, making it to block until ovsdb-server exits. This command  will
+       be useful for starting the OVN nb ovsdb-server in a container.
+
+       # ovn-ctl run_sb_ovsdb
+
+       This  command  runs  the OVN sb ovsdb-server without passing the detach
+       option, making it to block until ovsdb-server exits. This command  will
+       be useful for starting the OVN sb ovsdb-server in a container.
+
+       # ovn-ctl run_ic_nb_ovsdb
+
+       This command runs the OVN IC-NB ovsdb-server without passing the detach
+       option,  making it to block until ovsdb-server exits. This command will
+       be useful for starting the OVN IC-NB ovsdb-server in a container.
+
+       # ovn-ctl run_ic_sb_ovsdb
+
+       This command runs the OVN IC-SB ovsdb-server without passing the detach
+       option, making it to block until ovsdb-server exits. This command  will
+       be useful for starting the OVN IC-SB ovsdb-server in a container.
+
+EXAMPLE USAGE
+   Run ovn-controller on a host already running OVS
+       # ovn-ctl start_controller
+
+   Run ovn-northd on a host already running OVS
+       # ovn-ctl start_northd
+
+   All-in-one OVS+OVN for testing
+       # ovs-ctl start --system-id="random"
+
+       # ovn-ctl start_northd
+
+       # ovn-ctl start_controller
+
+   Promote and demote ovsdb servers
+       # ovn-ctl promote_ovnnb
+
+       # ovn-ctl promote_ovnsb
+
+       #  ovn-ctl  --db-nb-sync-from-addr=x.x.x.x  --db-nb-sync-from-port=6641
+       --db-nb-probe-interval-to-active=60000 demote_ovnnb
+
+       #  ovn-ctl  --db-sb-sync-from-addr=x.x.x.x  --db-sb-sync-from-port=6642
+       --db-sb-probe-interval-to-active=60000 demote_ovnsb
+
+   Creating a clustered db on 3 nodes with IPs x.x.x.x, y.y.y.y and z.z.z.z
+     Starting OVN ovsdb servers and ovn-northd on the node with IP x.x.x.x
+
+          #  ovn-ctl  --db-nb-addr=x.x.x.x  --db-nb-create-insecure-remote=yes
+       --db-sb-addr=x.x.x.x  --db-sb-create-insecure-remote=yes  --db-nb-clusā€ā€
+       ter-local-addr=x.x.x.x               --db-sb-cluster-local-addr=x.x.x.x
+       --ovn-northd-nb-db=tcp:x.x.x.x:6641,tcp:y.y.y.y:6641,tcp:z.z.z.z:6641
+       --ovn-northd-sb-db=tcp:x.x.x.x:6642,tcp:y.y.y.y:6642,tcp:z.z.z.z:6642
+       start_northd
+
+     Starting OVN ovsdb-servers and ovn-northd on the node with IP y.y.y.y and
+     joining the cluster started at x.x.x.x
+
+         #  ovn-ctl  --db-nb-addr=y.y.y.y   --db-nb-create-insecure-remote=yes
+       --db-sb-addr=y.y.y.y  --db-sb-create-insecure-remote=yes  --db-nb-clusā€ā€
+       ter-local-addr=y.y.y.y --db-sb-cluster-local-addr=y.y.y.y --db-nb-clusā€ā€
+       ter-remote-addr=x.x.x.x             --db-sb-cluster-remote-addr=x.x.x.x
+       --ovn-northd-nb-db=tcp:x.x.x.x:6641,tcp:y.y.y.y:6641,tcp:z.z.z.z:6641
+       --ovn-northd-sb-db=tcp:x.x.x.x:6642,tcp:y.y.y.y:6642,tcp:z.z.z.z:6642
+       start_northd
+
+     Starting OVN ovsdb-servers and ovn-northd on the node with IP z.z.z.z and
+     joining the cluster started at x.x.x.x
+
+          #  ovn-ctl  --db-nb-addr=z.z.z.z  --db-nb-create-insecure-remote=yes
+       --db-nb-cluster-local-addr=z.z.z.z  --db-sb-addr=z.z.z.z   --db-sb-creā€ā€
+       ate-insecure-remote=yes              --db-sb-cluster-local-addr=z.z.z.z
+       --db-nb-cluster-remote-addr=x.x.x.x --db-sb-cluster-remote-addr=x.x.x.x
+       --ovn-northd-nb-db=tcp:x.x.x.x:6641,tcp:y.y.y.y:6641,tcp:z.z.z.z:6641
+       --ovn-northd-sb-db=tcp:x.x.x.x:6642,tcp:y.y.y.y:6642,tcp:z.z.z.z:6642
+       start_northd
+
+   Passing ssl keys when starting OVN dbs will supersede the default ssl  valā€ā€
+       ues in db
+     Starting standalone ovn db server passing SSL certificates
+
+             #      ovn-ctl     --ovn-nb-db-ssl-key=/etc/ovn/ovnnb-privkey.pem
+       --ovn-nb-db-ssl-cert=/etc/ovn/ovnnb-cert.pem
+       --ovn-nb-db-ssl-ca-cert=/etc/ovn/cacert.pem
+       --ovn-sb-db-ssl-key=/etc/ovn/ovnsb-privkey.pem
+       --ovn-sb-db-ssl-cert=/etc/ovn/ovnsb-cert.pem
+       --ovn-sb-db-ssl-ca-cert=/etc/ovn/cacert.pem start_northd
+
+OVN 23.06.3                         ovn-ctl                         ovn-ctl(8)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ctl.8.pdf b/src/static/support/dist-docs-branch-23.06/ovn-ctl.8.pdf new file mode 100644 index 00000000..c9881a37 Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-ctl.8.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ctl.8.txt b/src/static/support/dist-docs-branch-23.06/ovn-ctl.8.txt new file mode 100644 index 00000000..ad63476a --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ctl.8.txt @@ -0,0 +1,347 @@ +ovn-ctl(8) OVN Manual ovn-ctl(8) + +NAME + ovn-ctl - Open Virtual Network northbound daemon lifecycle utility + +SYNOPSIS + ovn-ctl [options] command [-- extra_args] + +DESCRIPTION + This program is intended to be invoked internally by Open Virtual Netā€ + work startup scripts. System administrators should not normally invoke + it directly. + +COMMANDS + start_northd + start_controller + start_controller_vtep + start_ic + stop_northd + stop_controller + stop_controller_vtep + stop_ic + restart_northd + restart_controller + restart_controller_vtep + restart_ic + promote_ovnnb + promote_ovnsb + demote_ovnnb + demote_ovnsb + status_ovnnb + status_ovnsb + start_ovsdb + start_nb_ovsdb + start_sb_ovsdb + stop_ovsdb + stop_nb_ovsdb + stop_sb_ovsdb + restart_ovsdb + run_nb_ovsdb + run_sb_ovsdb + promote_ic_nb + promote_ic_sb + demote_ic_nb + demote_ic_sb + status_ic_nb + status_ic_sb + start_ic_ovsdb + start_ic_nb_ovsdb + start_ic_sb_ovsdb + stop_ic_ovsdb + stop_ic_nb_ovsdb + stop_ic_sb_ovsdb + restart_ic_ovsdb + run_ic_nb_ovsdb + run_ic_sb_ovsdb + +OPTIONS + --ovn-northd-priority=NICE + + --ovn-northd-wrapper=WRAPPER + + --ovn-controller-priority=NICE + + --ovn-controller-wrapper=WRAPPER + + --ovn-ic-priority=NICE + + --ovn-ic-wrapper=WRAPPER + + --ovsdb-nb-wrapper=WRAPPER + + --ovsdb-sb-wrapper=WRAPPER + + --ovn-user=USER:GROUP + + --ovs-user=USER:GROUP + + -h | --help + +FILE LOCATION OPTIONS + --db-sock=SOCKET + + --db-nb-file=FILE + + --db-sb-file=FILE + + --db-nb-schema=FILE + + --db-sb-schema=FILE + + --db-sb-create-insecure-remote=yes|no + + --db-nb-create-insecure-remote=yes|no + + --db-ic-nb-file=FILE + + --db-ic-sb-file=FILE + + --db-ic-nb-schema=FILE + + --db-ic-sb-schema=FILE + + --db-ic-sb-create-insecure-remote=yes|no + + --db-ic-nb-create-insecure-remote=yes|no + + --ovn-controller-ssl-key=KEY + + --ovn-controller-ssl-cert=CERT + + --ovn-controller-ssl-ca-cert=CERT + + --ovn-controller-ssl-bootstrap-ca-cert=CERT + +ADDRESS AND PORT OPTIONS + --db-nb-sync-from-addr=IP ADDRESS + + --db-nb-sync-from-port=PORT NUMBER + + --db-nb-sync-from-proto=PROTO + + --db-sb-sync-from-addr=IP ADDRESS + + --db-sb-sync-from-port=PORT NUMBER + + --db-sb-sync-from-proto=PROTO + + --db-ic-nb-sync-from-addr=IP ADDRESS + + --db-ic-nb-sync-from-port=PORT NUMBER + + --db-ic-nb-sync-from-proto=PROTO + + --db-ic-sb-sync-from-addr=IP ADDRESS + + --db-ic-sb-sync-from-port=PORT NUMBER + + --db-ic-sb-sync-from-proto=PROTO + + --ovn-northd-nb-db=PROTO:IP ADDRESS: PORT.. + + --ovn-northd-sb-db=PROTO:IP ADDRESS: PORT.. + + --ovn-ic-nb-db=PROTO:IP ADDRESS: PORT.. + + --ovn-ic-sb-db=PROTO:IP ADDRESS: PORT.. + +CLUSTERING OPTIONS + --db-nb-cluster-local-addr=IP ADDRESS + + --db-nb-cluster-local-port=PORT NUMBER + + --db-nb-cluster-local-proto=PROTO (tcp/ssl) + + --db-nb-cluster-remote-addr=IP ADDRESS + + --db-nb-cluster-remote-port=PORT NUMBER + + --db-nb-cluster-remote-proto=PROTO (tcp/ssl) + + --db-nb-election-timer=Timeout in milliseconds + + --db-sb-cluster-local-addr=IP ADDRESS + + --db-sb-cluster-local-port=PORT NUMBER + + --db-sb-cluster-local-proto=PROTO (tcp/ssl) + + --db-sb-cluster-remote-addr=IP ADDRESS + + --db-sb-cluster-remote-port=PORT NUMBER + + --db-sb-cluster-remote-proto=PROTO (tcp/ssl) + + --db-sb-election-timer=Timeout in milliseconds + + --db-ic-nb-cluster-local-addr=IP ADDRESS + + --db-ic-nb-cluster-local-port=PORT NUMBER + + --db-ic-nb-cluster-local-proto=PROTO (tcp/ssl) + + --db-ic-nb-cluster-remote-addr=IP ADDRESS + + --db-ic-nb-cluster-remote-port=PORT NUMBER + + --db-ic-nb-cluster-remote-proto=PROTO (tcp/ssl) + + --db-ic-sb-cluster-local-addr=IP ADDRESS + + --db-ic-sb-cluster-local-port=PORT NUMBER + + --db-ic-sb-cluster-local-proto=PROTO (tcp/ssl) + + --db-ic-sb-cluster-remote-addr=IP ADDRESS + + --db-ic-sb-cluster-remote-port=PORT NUMBER + + --db-ic-sb-cluster-remote-proto=PROTO (tcp/ssl) + +PROBE INTERVAL OPTIONS + --db-nb-probe-interval-to-active=Time in milliseconds + + --db-sb-probe-interval-to-active=Time in milliseconds + +EXTRA OPTIONS + Any options after ā€™-ā€™ will be passed on to the binary run by command + with the exception of start_northd, which can have options specified in + ovn-northd-db-params.conf. Any extra_args passed to start_northd will + be passed to the ovsdb-servers if --ovn-manage-ovsdb=yes + +CONFIGURATION FILES + Following are the optional configuration files. If present, it should + be located in the etc dir + + ovnnb-active.conf + If present, this file should hold the url to connect to the active + Northbound DB server + + tcp:x.x.x.x:6641 + + ovnsb-active.conf + If present, this file should hold the url to connect to the active + Southbound DB server + + tcp:x.x.x.x:6642 + + ovn-northd-db-params.conf + If present, start_northd will not start the DB server even if + --ovn-manage-ovsdb=yes. This file should hold the database url parameā€ + ters to be passed to ovn-northd. + + --ovnnb-db=tcp:x.x.x.x:6641 --ovnsb-db=tcp:x.x.x.x:6642 + + ic-nb-active.conf + If present, this file should hold the url to connect to the active Inā€ + terconnection Northbound DB server + + tcp:x.x.x.x:6645 + + ic-sb-active.conf + If present, this file should hold the url to connect to the active Inā€ + terconnection Southbound DB server + + tcp:x.x.x.x:6646 + + ovn-ic-db-params.conf + If present, this file should hold the database url parameters to be + passed to ovn-ic. + + --ic-nb-db=tcp:x.x.x.x:6645 --ic-sb-db=tcp:x.x.x.x:6646 + +RUNNING OVN DB SERVERS WITHOUT DETACHING + # ovn-ctl run_nb_ovsdb + + This command runs the OVN nb ovsdb-server without passing the detach + option, making it to block until ovsdb-server exits. This command will + be useful for starting the OVN nb ovsdb-server in a container. + + # ovn-ctl run_sb_ovsdb + + This command runs the OVN sb ovsdb-server without passing the detach + option, making it to block until ovsdb-server exits. This command will + be useful for starting the OVN sb ovsdb-server in a container. + + # ovn-ctl run_ic_nb_ovsdb + + This command runs the OVN IC-NB ovsdb-server without passing the detach + option, making it to block until ovsdb-server exits. This command will + be useful for starting the OVN IC-NB ovsdb-server in a container. + + # ovn-ctl run_ic_sb_ovsdb + + This command runs the OVN IC-SB ovsdb-server without passing the detach + option, making it to block until ovsdb-server exits. This command will + be useful for starting the OVN IC-SB ovsdb-server in a container. + +EXAMPLE USAGE + Run ovn-controller on a host already running OVS + # ovn-ctl start_controller + + Run ovn-northd on a host already running OVS + # ovn-ctl start_northd + + All-in-one OVS+OVN for testing + # ovs-ctl start --system-id="random" + + # ovn-ctl start_northd + + # ovn-ctl start_controller + + Promote and demote ovsdb servers + # ovn-ctl promote_ovnnb + + # ovn-ctl promote_ovnsb + + # ovn-ctl --db-nb-sync-from-addr=x.x.x.x --db-nb-sync-from-port=6641 + --db-nb-probe-interval-to-active=60000 demote_ovnnb + + # ovn-ctl --db-sb-sync-from-addr=x.x.x.x --db-sb-sync-from-port=6642 + --db-sb-probe-interval-to-active=60000 demote_ovnsb + + Creating a clustered db on 3 nodes with IPs x.x.x.x, y.y.y.y and z.z.z.z + Starting OVN ovsdb servers and ovn-northd on the node with IP x.x.x.x + + # ovn-ctl --db-nb-addr=x.x.x.x --db-nb-create-insecure-remote=yes + --db-sb-addr=x.x.x.x --db-sb-create-insecure-remote=yes --db-nb-clusā€ā€ + ter-local-addr=x.x.x.x --db-sb-cluster-local-addr=x.x.x.x + --ovn-northd-nb-db=tcp:x.x.x.x:6641,tcp:y.y.y.y:6641,tcp:z.z.z.z:6641 + --ovn-northd-sb-db=tcp:x.x.x.x:6642,tcp:y.y.y.y:6642,tcp:z.z.z.z:6642 + start_northd + + Starting OVN ovsdb-servers and ovn-northd on the node with IP y.y.y.y and + joining the cluster started at x.x.x.x + + # ovn-ctl --db-nb-addr=y.y.y.y --db-nb-create-insecure-remote=yes + --db-sb-addr=y.y.y.y --db-sb-create-insecure-remote=yes --db-nb-clusā€ā€ + ter-local-addr=y.y.y.y --db-sb-cluster-local-addr=y.y.y.y --db-nb-clusā€ā€ + ter-remote-addr=x.x.x.x --db-sb-cluster-remote-addr=x.x.x.x + --ovn-northd-nb-db=tcp:x.x.x.x:6641,tcp:y.y.y.y:6641,tcp:z.z.z.z:6641 + --ovn-northd-sb-db=tcp:x.x.x.x:6642,tcp:y.y.y.y:6642,tcp:z.z.z.z:6642 + start_northd + + Starting OVN ovsdb-servers and ovn-northd on the node with IP z.z.z.z and + joining the cluster started at x.x.x.x + + # ovn-ctl --db-nb-addr=z.z.z.z --db-nb-create-insecure-remote=yes + --db-nb-cluster-local-addr=z.z.z.z --db-sb-addr=z.z.z.z --db-sb-creā€ā€ + ate-insecure-remote=yes --db-sb-cluster-local-addr=z.z.z.z + --db-nb-cluster-remote-addr=x.x.x.x --db-sb-cluster-remote-addr=x.x.x.x + --ovn-northd-nb-db=tcp:x.x.x.x:6641,tcp:y.y.y.y:6641,tcp:z.z.z.z:6641 + --ovn-northd-sb-db=tcp:x.x.x.x:6642,tcp:y.y.y.y:6642,tcp:z.z.z.z:6642 + start_northd + + Passing ssl keys when starting OVN dbs will supersede the default ssl valā€ā€ + ues in db + Starting standalone ovn db server passing SSL certificates + + # ovn-ctl --ovn-nb-db-ssl-key=/etc/ovn/ovnnb-privkey.pem + --ovn-nb-db-ssl-cert=/etc/ovn/ovnnb-cert.pem + --ovn-nb-db-ssl-ca-cert=/etc/ovn/cacert.pem + --ovn-sb-db-ssl-key=/etc/ovn/ovnsb-privkey.pem + --ovn-sb-db-ssl-cert=/etc/ovn/ovnsb-cert.pem + --ovn-sb-db-ssl-ca-cert=/etc/ovn/cacert.pem start_northd + +OVN 23.06.3 ovn-ctl ovn-ctl(8) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-detrace.1 b/src/static/support/dist-docs-branch-23.06/ovn-detrace.1 new file mode 100644 index 00000000..703f8992 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-detrace.1 @@ -0,0 +1,273 @@ +.\" -*- nroff -*- +.\" ovs.tmac +.\" +.\" Open vSwitch troff macro library +. +. +.\" Continuation line for .IP. +.de IQ +. br +. ns +. IP "\\$1" +.. +. +.\" Introduces a sub-subsection +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +. +.\" The content between the lines below is from an-ext.tmac in groff +.\" 1.21, with some modifications. +.\" ---------------------------------------------------------------------- +.\" an-ext.tmac +.\" +.\" Written by Eric S. Raymond +.\" Werner Lemberg +.\" +.\" Version 2007-Feb-02 +.\" +.\" Copyright (C) 2007, 2009, 2011 Free Software Foundation, Inc. +.\" You may freely use, modify and/or distribute this file. +.\" +.\" +.\" The code below provides extension macros for the `man' macro package. +.\" Care has been taken to make the code portable; groff extensions are +.\" properly hidden so that all troff implementations can use it without +.\" changes. +.\" +.\" With groff, this file is sourced by the `man' macro package itself. +.\" Man page authors who are concerned about portability might add the +.\" used macros directly to the prologue of the man page(s). +. +. +.\" Convention: Auxiliary macros and registers start with `m' followed +.\" by an uppercase letter or digit. +. +. +.\" Declare start of command synopsis. Sets up hanging indentation. +.de SY +. ie !\\n(mS \{\ +. nh +. nr mS 1 +. nr mA \\n(.j +. ad l +. nr mI \\n(.i +. \} +. el \{\ +. br +. ns +. \} +. +. HP \w'\fB\\$1\fP\ 'u +. B "\\$1" +.. +. +. +.\" End of command synopsis. Restores adjustment. +.de YS +. in \\n(mIu +. ad \\n(mA +. hy \\n(HY +. nr mS 0 +.. +. +. +.\" Declare optional option. +.de OP +. ie \\n(.$-1 \ +. RI "[\fB\\$1\fP" "\ \\$2" "]" +. el \ +. RB "[" "\\$1" "]" +.. +. +. +.\" Start URL. +.de UR +. ds m1 \\$1\" +. nh +. if \\n(mH \{\ +. \" Start diversion in a new environment. +. do ev URL-div +. do di URL-div +. \} +.. +. +. +.\" End URL. +.de UE +. ie \\n(mH \{\ +. br +. di +. ev +. +. \" Has there been one or more input lines for the link text? +. ie \\n(dn \{\ +. do HTML-NS "" +. \" Yes, strip off final newline of diversion and emit it. +. do chop URL-div +. do URL-div +\c +. do HTML-NS +. \} +. el \ +. do HTML-NS "\\*(m1" +\&\\$*\" +. \} +. el \ +\\*(la\\*(m1\\*(ra\\$*\" +. +. hy \\n(HY +.. +. +. +.\" Start email address. +.de MT +. ds m1 \\$1\" +. nh +. if \\n(mH \{\ +. \" Start diversion in a new environment. +. do ev URL-div +. do di URL-div +. \} +.. +. +. +.\" End email address. +.de ME +. ie \\n(mH \{\ +. br +. di +. ev +. +. \" Has there been one or more input lines for the link text? +. ie \\n(dn \{\ +. do HTML-NS "" +. \" Yes, strip off final newline of diversion and emit it. +. do chop URL-div +. do URL-div +\c +. do HTML-NS +. \} +. el \ +. do HTML-NS "\\*(m1" +\&\\$*\" +. \} +. el \ +\\*(la\\*(m1\\*(ra\\$*\" +. +. hy \\n(HY +.. +. +. +.\" Continuation line for .TP header. +.de TQ +. br +. ns +. TP \\$1\" no doublequotes around argument! +.. +. +. +.\" Start example. +.de EX +. nr mE \\n(.f +. nf +. nh +. ft CR +.. +. +. +.\" End example. +.de EE +. ft \\n(mE +. fi +. hy \\n(HY +.. +. +.\" EOF +.\" ---------------------------------------------------------------------- +.TH ovn\-detrace 1 "23.06.3" "OVN" "OVN Manual" +.\" This program's name: +.ds PN ovn\-detrace +. +.SH NAME +\*(PN \- convert ``ovs\-appctl ofproto/trace'' output to combine +OVN logical flow information. +. +.SH SYNOPSIS +\fB\*(PN < \fIfile\fR +.IP "Common options:" +[\fB\-h\fR | \fB\-\-help\fR] +[\fB\-V\fR | \fB\-\-version\fR] + +. +.SH DESCRIPTION +The \fB\*(PN\fR program reads \fBovs\-appctl ofproto/trace\fR output on +stdin, looking for flow cookies, and expand each cookie with corresponding OVN +logical flows. It expands logical flow further with the north-bound information +e.g. the ACL that generated the logical flow, when relevant. +.PP +. +.SH "OPTIONS" +.IP "\fB\-h\fR" +.IQ "\fB\-\-help\fR" +Prints a brief help message to the console. +. +.IP "\fB\-V\fR" +.IQ "\fB\-\-version\fR" +Prints version information to the console. +. +.IP "\fB\-\-ovnsb=\fIserver\fR" +The OVN Southbound DB remote to contact. If the \fBOVN_SB_DB\fR +environment variable is set, its value is used as the default. +Otherwise, the default is \fBunix:@RUNDIR@/ovnsb_db.sock\fR, but this +default is unlikely to be useful outside of single-machine OVN test +environments. +. +.IP "\fB\-\-ovnnb=\fIserver\fR" +The OVN Northbound DB remote to contact. If the \fBOVN_NB_DB\fR +environment variable is set, its value is used as the default. +Otherwise, the default is \fBunix:@RUNDIR@/ovnnb_db.sock\fR, but this +default is unlikely to be useful outside of single-machine OVN test +environments. +. +.IP "\fB\-\-ovs=\fR" +Also decode flow information (like OVS ofport) from the flows by connecting +to the OVS DB. +. +.IP "\fB\-\-no-leader-only\fR" +Connect to any cluster member, not just the leader. The option works for +OVN Southbound DB and OVN Northbound DB. +. +.IP "\fB\-\-ovsdb=\fIserver\fR" +The OVS DB remote to contact if \fB\-\-ovs\fR is present. If the +\fBOVS_RUNDIR\fR environment variable is set, its value is used as the +default. Otherwise, the default is \fBunix:@RUNDIR@/db.sock\fR, but this +default is unlikely to be useful outside of single-machine OVN test +environments. +. +.IP "\fB\-p\fR \fIprivkey.pem\fR" +.IQ "\fB\-\-private\-key=\fIprivkey.pem\fR" +Specifies a PEM file containing the private key used as \fB\*(PN\fR's +identity for outgoing SSL connections. +. +.IP "\fB\-c\fR \fIcert.pem\fR" +.IQ "\fB\-\-certificate=\fIcert.pem\fR" +Specifies a PEM file containing a certificate that certifies the +private key specified on \fB\-p\fR or \fB\-\-private\-key\fR to be +trustworthy. The certificate must be signed by the certificate +authority (CA) that the peer in SSL connections will use to verify it. +. +.IP "\fB\-C\fR \fIcacert.pem\fR" +.IQ "\fB\-\-ca\-cert=\fIcacert.pem\fR" +Specifies a PEM file containing the CA certificate that \fB\*(PN\fR +should use to verify certificates presented to it by SSL peers. (This +may be the same certificate that SSL peers use to verify the +certificate specified on \fB\-c\fR or \fB\-\-certificate\fR, or it may +be a different one, depending on the PKI design in use.) +. +.SH "SEE ALSO" +. +.BR ovs\-appctl (8), ovn\-sbctl (8), ovn\-nbctl (8), ovn\-trace (8) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-detrace.1.html b/src/static/support/dist-docs-branch-23.06/ovn-detrace.1.html new file mode 100644 index 00000000..088eb6a6 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-detrace.1.html @@ -0,0 +1,81 @@ +
+ovn-detrace(1)                    OVN Manual                    ovn-detrace(1)
+
+NAME
+       ovn-detrace  -  convert  ``ovs-appctl ofproto/trace'' output to combine
+       OVN logical flow information.
+
+SYNOPSIS
+       ovn-detrace file
+
+       Common options:
+              [-h | --help] [-V | --version]
+
+
+DESCRIPTION
+       The ovn-detrace program reads ovs-appctl ofproto/trace output on stdin,
+       looking for flow cookies, and expand each cookie with corresponding OVN
+       logical flows. It expands logical flow further with the north-bound inā€
+       formation e.g. the ACL that generated the logical flow, when relevant.
+
+OPTIONS
+       -h
+       --help Prints a brief help message to the console.
+
+       -V
+       --version
+              Prints version information to the console.
+
+       --ovnsb=server
+              The OVN Southbound DB remote to contact.  If the OVN_SB_DB enviā€
+              ronment variable is set, its value is used as the default.  Othā€
+              erwise, the default is unix:@RUNDIR@/ovnsb_db.sock, but this deā€
+              fault is unlikely to be useful  outside  of  single-machine  OVN
+              test environments.
+
+       --ovnnb=server
+              The OVN Northbound DB remote to contact.  If the OVN_NB_DB enviā€
+              ronment variable is set, its value is used as the default.  Othā€
+              erwise, the default is unix:@RUNDIR@/ovnnb_db.sock, but this deā€
+              fault  is  unlikely  to  be useful outside of single-machine OVN
+              test environments.
+
+       --ovs= Also decode flow information (like OVS ofport) from the flows by
+              connecting to the OVS DB.
+
+       --no-leader-only
+              Connect to any cluster member, not just the leader.  The  option
+              works for OVN Southbound DB and OVN Northbound DB.
+
+       --ovsdb=server
+              The  OVS  DB  remote  to  contact  if  --ovs is present.  If the
+              OVS_RUNDIR environment variable is set, its value is used as the
+              default. Otherwise, the default  is  unix:@RUNDIR@/db.sock,  but
+              this  default is unlikely to be useful outside of single-machine
+              OVN test environments.
+
+       -p privkey.pem
+       --private-key=privkey.pem
+              Specifies a PEM file containing the private key used as  ovn-deā€ā€
+              trace's identity for outgoing SSL connections.
+
+       -c cert.pem
+       --certificate=cert.pem
+              Specifies a PEM file containing a certificate that certifies the
+              private  key specified on -p or --private-key to be trustworthy.
+              The certificate must be signed by the certificate 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 that  ovn-deā€ā€
+              trace  should  use to verify certificates presented to it 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 use.)
+
+SEE ALSO
+       ovs-appctl(8),ovn-sbctl(8),ovn-nbctl(8),ovn-trace(8)
+
+OVN                                 23.06.3                     ovn-detrace(1)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-detrace.1.pdf b/src/static/support/dist-docs-branch-23.06/ovn-detrace.1.pdf new file mode 100644 index 00000000..7a08cd34 Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-detrace.1.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-detrace.1.txt b/src/static/support/dist-docs-branch-23.06/ovn-detrace.1.txt new file mode 100644 index 00000000..9a01436b --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-detrace.1.txt @@ -0,0 +1,79 @@ +ovn-detrace(1) OVN Manual ovn-detrace(1) + +NAME + ovn-detrace - convert ``ovs-appctl ofproto/trace'' output to combine + OVN logical flow information. + +SYNOPSIS + ovn-detrace < file + + Common options: + [-h | --help] [-V | --version] + + +DESCRIPTION + The ovn-detrace program reads ovs-appctl ofproto/trace output on stdin, + looking for flow cookies, and expand each cookie with corresponding OVN + logical flows. It expands logical flow further with the north-bound inā€ + formation e.g. the ACL that generated the logical flow, when relevant. + +OPTIONS + -h + --help Prints a brief help message to the console. + + -V + --version + Prints version information to the console. + + --ovnsb=server + The OVN Southbound DB remote to contact. If the OVN_SB_DB enviā€ + ronment variable is set, its value is used as the default. Othā€ + erwise, the default is unix:@RUNDIR@/ovnsb_db.sock, but this deā€ + fault is unlikely to be useful outside of single-machine OVN + test environments. + + --ovnnb=server + The OVN Northbound DB remote to contact. If the OVN_NB_DB enviā€ + ronment variable is set, its value is used as the default. Othā€ + erwise, the default is unix:@RUNDIR@/ovnnb_db.sock, but this deā€ + fault is unlikely to be useful outside of single-machine OVN + test environments. + + --ovs= Also decode flow information (like OVS ofport) from the flows by + connecting to the OVS DB. + + --no-leader-only + Connect to any cluster member, not just the leader. The option + works for OVN Southbound DB and OVN Northbound DB. + + --ovsdb=server + The OVS DB remote to contact if --ovs is present. If the + OVS_RUNDIR environment variable is set, its value is used as the + default. Otherwise, the default is unix:@RUNDIR@/db.sock, but + this default is unlikely to be useful outside of single-machine + OVN test environments. + + -p privkey.pem + --private-key=privkey.pem + Specifies a PEM file containing the private key used as ovn-deā€ā€ + trace's identity for outgoing SSL connections. + + -c cert.pem + --certificate=cert.pem + Specifies a PEM file containing a certificate that certifies the + private key specified on -p or --private-key to be trustworthy. + The certificate must be signed by the certificate 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 that ovn-deā€ā€ + trace should use to verify certificates presented to it 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 use.) + +SEE ALSO + ovs-appctl(8),ovn-sbctl(8),ovn-nbctl(8),ovn-trace(8) + +OVN 23.06.3 ovn-detrace(1) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic-nb.5 b/src/static/support/dist-docs-branch-23.06/ovn-ic-nb.5 new file mode 100644 index 00000000..2f0515c7 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ic-nb.5 @@ -0,0 +1,397 @@ +'\" p +.\" -*- nroff -*- +.TH "ovn-ic-nb" 5 " DB Schema 1.0.0" "Open vSwitch 23.06.3" "Open vSwitch Manual" +.fp 5 L CR \\" Make fixed-width font available as \\fL. +.de TQ +. br +. ns +. TP "\\$1" +.. +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +.SH NAME +ovn-ic-nb \- OVN_IC_Northbound database schema +.PP +.PP +.PP +.PP +This database is the interface for cloud management system (CMS), such as OpenStack, to configure OVN interconnection settings\[char46] The CMS produces almost all of the contents of the database\[char46] The \fBovn\-ic\fR program monitors the database contents, transforms it, and stores it into the \fBOVN_IC_Southbound\fR database\[char46] +.PP +.PP +We generally speak of ``the\(cq\(cq CMS, but one can imagine scenarios in which multiple CMSes manage different parts of OVN interconnection\[char46] +.SS "External IDs" +.PP +.PP +Each of the tables in this database contains a special column, named \fBexternal_ids\fR\[char46] This column has the same form and purpose each place it appears\[char46] +.RS +.TP +\fBexternal_ids\fR: map of string-string pairs +Key-value pairs for use by the CMS\[char46] The CMS might use certain pairs, for example, to identify entities in its own configuration that correspond to those in this database\[char46] +.RE +.SH "TABLE SUMMARY" +.PP +The following list summarizes the purpose of each of the tables in the +\fBOVN_IC_Northbound\fR database. Each table is described in more detail on a later +page. +.IP "Table" 1in +Purpose +.TQ 1in +\fBIC_NB_Global\fR +IC Northbound configuration +.TQ 1in +\fBTransit_Switch\fR +Transit logical switch +.TQ 1in +\fBSSL\fR +SSL configuration\[char46] +.TQ 1in +\fBConnection\fR +OVSDB client connections\[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.684030,0.625000 wid 1.368100 height 0.500000 "IC_NB_Global" +box at 0.684030,0.625000 wid 1.312544 height 0.444444 +linethick = 1.000000; +box at 3.401000,1.000000 wid 1.086800 height 0.500000 "Connection" +linethick = 1.000000; +box at 3.401000,0.250000 wid 0.750000 height 0.500000 "SSL" +linethick = 0.500000; +box at 0.684030,1.375000 wid 1.357600 height 0.500000 "Transit_Switch" +box at 0.684030,1.375000 wid 1.302044 height 0.444444 +linethick = 1.000000; +spline -> from 1.369600,0.718660 to 1.369600,0.718660 to 1.828500,0.782660 to 2.428400,0.866310 to 2.854400,0.925710 +"connections*" at 2.112800,0.987850 +linethick = 1.000000; +spline -> from 1.371300,0.530960 to 1.371300,0.530960 to 1.454400,0.519360 to 1.538200,0.507670 to 1.618100,0.496530 to 2.103300,0.428840 to 2.663500,0.350800 to 3.021200,0.300960 +"ssl?" at 2.112800,0.585070 +.ps +3 +.PE +.RE\} +.bp +.SH "IC_NB_Global TABLE" +.PP +.PP +.PP +Northbound configuration for OVN interconnection\[char46] This table must have exactly one row\[char46] +.SS "Summary: +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.TQ .25in +\fICommon options:\fR +.RS .25in +.TQ 2.75in +\fBoptions\fR +map of string-string pairs +.TQ 2.75in +\fBoptions : ic_probe_interval\fR +optional string +.RE +.TQ .25in +\fIConnection Options:\fR +.RS .25in +.TQ 2.75in +\fBconnections\fR +set of \fBConnection\fRs +.TQ 2.75in +\fBssl\fR +optional \fBSSL\fR +.RE +.SS "Details: +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.ST "Common options:" +.PP +.IP "\fBoptions\fR: map of string-string pairs" +This column provides general key/value settings\[char46] The supported options are described individually below\[char46] +.IP "\fBoptions : ic_probe_interval\fR: optional string" +The inactivity probe interval of the connection to the OVN IC 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] +.ST "Connection Options:" +.PP +.IP "\fBconnections\fR: set of \fBConnection\fRs" +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\[char46] See the \fBConnection\fR table for more information\[char46] +.IP "\fBssl\fR: optional \fBSSL\fR" +Global SSL configuration\[char46] +.bp +.SH "Transit_Switch TABLE" +.PP +.PP +.PP +Each row represents one transit logical switch for interconnection between different OVN deployments (availability zones)\[char46] +.SS "Summary: +.TQ .25in +\fINaming:\fR +.RS .25in +.TQ 2.75in +\fBname\fR +string (must be unique within table) +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBother_config\fR +map of string-string pairs +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.ST "Naming:" +.PP +.IP "\fBname\fR: string (must be unique within table)" +A name that uniquely identifies the transit logical switch\[char46] +.ST "Common Columns:" +.PP +.IP "\fBother_config\fR: map of string-string pairs" +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "SSL TABLE" +.PP +SSL configuration for ovn-nb database access\[char46] +.SS "Summary: +.TQ 3.00in +\fBprivate_key\fR +string +.TQ 3.00in +\fBcertificate\fR +string +.TQ 3.00in +\fBca_cert\fR +string +.TQ 3.00in +\fBbootstrap_ca_cert\fR +boolean +.TQ 3.00in +\fBssl_protocols\fR +string +.TQ 3.00in +\fBssl_ciphers\fR +string +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBprivate_key\fR: string" +Name of a PEM file containing the private key used as the switch\(cqs identity for SSL connections to the controller\[char46] +.IP "\fBcertificate\fR: string" +Name of a PEM file containing a certificate, signed by the certificate authority (CA) used by the controller and manager, that certifies the switch\(cqs private key, identifying a trustworthy switch\[char46] +.IP "\fBca_cert\fR: string" +Name of a PEM file containing the CA certificate used to verify that the switch is connected to a trustworthy controller\[char46] +.IP "\fBbootstrap_ca_cert\fR: boolean" +If set to \fBtrue\fR, 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\[char46] 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\[char46] \fBThis option exposes the +SSL connection to a man\-in\-the\-middle attack obtaining the initial +CA certificate\[char46]\fR It may still be useful for bootstrapping\[char46] +.IP "\fBssl_protocols\fR: string" +List of SSL protocols to be enabled for SSL connections\[char46] The default when this option is omitted is \fBTLSv1,TLSv1\[char46]1,TLSv1\[char46]2\fR\[char46] +.IP "\fBssl_ciphers\fR: string" +List of ciphers (in OpenSSL cipher string format) to be supported for SSL connections\[char46] The default when this option is omitted is \fBHIGH:!aNULL:!MD5\fR\[char46] +.ST "Common Columns:" +.PP +The overall purpose of these columns is described under \fBCommon +Columns\fR at the beginning of this document\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +.bp +.SH "Connection TABLE" +.PP +.PP +.PP +Configuration for a database connection to an Open vSwitch database (OVSDB) client\[char46] +.PP +.PP +This table primarily configures the Open vSwitch database server (\fBovsdb\-server\fR)\[char46] +.PP +.PP +The Open vSwitch database server can initiate and maintain active connections to remote clients\[char46] It can also listen for database connections\[char46] +.SS "Summary: +.TQ .25in +\fICore Features:\fR +.RS .25in +.TQ 2.75in +\fBtarget\fR +string (must be unique within table) +.RE +.TQ .25in +\fIClient Failure Detection and Handling:\fR +.RS .25in +.TQ 2.75in +\fBmax_backoff\fR +optional integer, at least 1,000 +.TQ 2.75in +\fBinactivity_probe\fR +optional integer +.RE +.TQ .25in +\fIStatus:\fR +.RS .25in +.TQ 2.75in +\fBis_connected\fR +boolean +.TQ 2.75in +\fBstatus : last_error\fR +optional string +.TQ 2.75in +\fBstatus : state\fR +optional string, one of \fBACTIVE\fR, \fBBACKOFF\fR, \fBCONNECTING\fR, \fBIDLE\fR, or \fBVOID\fR +.TQ 2.75in +\fBstatus : sec_since_connect\fR +optional string, containing an integer, at least 0 +.TQ 2.75in +\fBstatus : sec_since_disconnect\fR +optional string, containing an integer, at least 0 +.TQ 2.75in +\fBstatus : locks_held\fR +optional string +.TQ 2.75in +\fBstatus : locks_waiting\fR +optional string +.TQ 2.75in +\fBstatus : locks_lost\fR +optional string +.TQ 2.75in +\fBstatus : n_connections\fR +optional string, containing an integer, at least 2 +.TQ 2.75in +\fBstatus : bound_port\fR +optional string, containing an integer +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.TQ 2.75in +\fBother_config\fR +map of string-string pairs +.RE +.SS "Details: +.ST "Core Features:" +.PP +.IP "\fBtarget\fR: string (must be unique within table)" +Connection methods for clients\[char46] +.IP +The following connection methods are currently supported: +.RS +.TP +\fBssl:\fIhost\fB\fR[\fB:\fIport\fB\fR] +The specified SSL \fIport\fR on the host at the given \fIhost\fR, which can either be a DNS name (if built with unbound library) or an IP address\[char46] A valid SSL configuration must be provided when this form is used, this configuration can be specified via command-line options or the \fBSSL\fR table\[char46] +.IP +If \fIport\fR is not specified, it defaults to 6640\[char46] +.IP +SSL support is an optional feature that is not always built as part of Open vSwitch\[char46] +.TP +\fBtcp:\fIhost\fB\fR[\fB:\fIport\fB\fR] +The specified TCP \fIport\fR on the host at the given \fIhost\fR, which can either be a DNS name (if built with unbound library) or an IP address\[char46] If \fIhost\fR is an IPv6 address, wrap it in square brackets, e\[char46]g\[char46] \fBtcp:[::1]:6640\fR\[char46] +.IP +If \fIport\fR is not specified, it defaults to 6640\[char46] +.TP +\fBpssl:\fR[\fIport\fR][\fB:\fIhost\fB\fR] +Listens for SSL connections on the specified TCP \fIport\fR\[char46] Specify 0 for \fIport\fR to have the kernel automatically choose an available port\[char46] If \fIhost\fR, which can either be a DNS name (if built with unbound library) or an IP address, is specified, then connections are restricted to the resolved or specified local IPaddress (either IPv4 or IPv6 address)\[char46] If \fIhost\fR is an IPv6 address, wrap in square brackets, e\[char46]g\[char46] \fBpssl:6640:[::1]\fR\[char46] If \fIhost\fR is not specified then it listens only on IPv4 (but not IPv6) addresses\[char46] A valid SSL configuration must be provided when this form is used, this can be specified either via command-line options or the \fBSSL\fR table\[char46] +.IP +If \fIport\fR is not specified, it defaults to 6640\[char46] +.IP +SSL support is an optional feature that is not always built as part of Open vSwitch\[char46] +.TP +\fBptcp:\fR[\fIport\fR][\fB:\fIhost\fB\fR] +Listens for connections on the specified TCP \fIport\fR\[char46] Specify 0 for \fIport\fR to have the kernel automatically choose an available port\[char46] If \fIhost\fR, 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)\[char46] If \fIhost\fR is an IPv6 address, wrap it in square brackets, e\[char46]g\[char46] \fBptcp:6640:[::1]\fR\[char46] If \fIhost\fR is not specified then it listens only on IPv4 addresses\[char46] +.IP +If \fIport\fR is not specified, it defaults to 6640\[char46] +.RE +.IP +When multiple clients are configured, the \fBtarget\fR values must be unique\[char46] Duplicate \fBtarget\fR values yield unspecified results\[char46] +.ST "Client Failure Detection and Handling:" +.PP +.IP "\fBmax_backoff\fR: optional integer, at least 1,000" +Maximum number of milliseconds to wait between connection attempts\[char46] Default is implementation-specific\[char46] +.IP "\fBinactivity_probe\fR: optional integer" +Maximum number of milliseconds of idle time on connection to the client before sending an inactivity probe message\[char46] If Open vSwitch does not communicate with the client for the specified number of seconds, it will send a probe\[char46] If a response is not received for the same additional amount of time, Open vSwitch assumes the connection has been broken and attempts to reconnect\[char46] Default is implementation-specific\[char46] A value of 0 disables inactivity probes\[char46] +.ST "Status:" +.PP +.PP +.PP +Key-value pair of \fBis_connected\fR is always updated\[char46] Other key-value pairs in the status columns may be updated depends on the \fBtarget\fR type\[char46] +.PP +.PP +When \fBtarget\fR specifies a connection method that listens for inbound connections (e\[char46]g\[char46] \fBptcp:\fR or \fBpunix:\fR), both \fBn_connections\fR and \fBis_connected\fR may also be updated while the remaining key-value pairs are omitted\[char46] +.PP +.PP +On the other hand, when \fBtarget\fR specifies an outbound connection, all key-value pairs may be updated, except the above-mentioned two key-value pairs associated with inbound connection targets\[char46] They are omitted\[char46] +.IP "\fBis_connected\fR: boolean" +\fBtrue\fR if currently connected to this client, \fBfalse\fR otherwise\[char46] +.IP "\fBstatus : last_error\fR: optional string" +A human-readable description of the last error on the connection to the manager; i\[char46]e\[char46] \fBstrerror(errno)\fR\[char46] This key will exist only if an error has occurred\[char46] +.IP "\fBstatus : state\fR: optional string, one of \fBACTIVE\fR, \fBBACKOFF\fR, \fBCONNECTING\fR, \fBIDLE\fR, or \fBVOID\fR" +The state of the connection to the manager: +.RS +.TP +\fBVOID\fR +Connection is disabled\[char46] +.TP +\fBBACKOFF\fR +Attempting to reconnect at an increasing period\[char46] +.TP +\fBCONNECTING\fR +Attempting to connect\[char46] +.TP +\fBACTIVE\fR +Connected, remote host responsive\[char46] +.TP +\fBIDLE\fR +Connection is idle\[char46] Waiting for response to keep-alive\[char46] +.RE +.IP +These values may change in the future\[char46] They are provided only for human consumption\[char46] +.IP "\fBstatus : sec_since_connect\fR: optional string, containing an integer, at least 0" +The amount of time since this client last successfully connected to the database (in seconds)\[char46] Value is empty if client has never successfully been connected\[char46] +.IP "\fBstatus : sec_since_disconnect\fR: optional string, containing an integer, at least 0" +The amount of time since this client last disconnected from the database (in seconds)\[char46] Value is empty if client has never disconnected\[char46] +.IP "\fBstatus : locks_held\fR: optional string" +Space-separated list of the names of OVSDB locks that the connection holds\[char46] Omitted if the connection does not hold any locks\[char46] +.IP "\fBstatus : locks_waiting\fR: optional string" +Space-separated list of the names of OVSDB locks that the connection is currently waiting to acquire\[char46] Omitted if the connection is not waiting for any locks\[char46] +.IP "\fBstatus : locks_lost\fR: optional string" +Space-separated list of the names of OVSDB locks that the connection has had stolen by another OVSDB client\[char46] Omitted if no locks have been stolen from this connection\[char46] +.IP "\fBstatus : n_connections\fR: optional string, containing an integer, at least 2" +When \fBtarget\fR specifies a connection method that listens for inbound connections (e\[char46]g\[char46] \fBptcp:\fR or \fBpssl:\fR) and more than one connection is actually active, the value is the number of active connections\[char46] Otherwise, this key-value pair is omitted\[char46] +.IP "\fBstatus : bound_port\fR: optional string, containing an integer" +When \fBtarget\fR is \fBptcp:\fR or \fBpssl:\fR, this is the TCP port on which the OVSDB server is listening\[char46] (This is particularly useful when \fBtarget\fR specifies a port of 0, allowing the kernel to choose any available port\[char46]) +.ST "Common Columns:" +.PP +The overall purpose of these columns is described under \fBCommon +Columns\fR at the beginning of this document\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +.IP "\fBother_config\fR: map of string-string pairs" diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic-nb.5.html b/src/static/support/dist-docs-branch-23.06/ovn-ic-nb.5.html new file mode 100644 index 00000000..81c9a0cc --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ic-nb.5.html @@ -0,0 +1,374 @@ +
+ovn-ic-nb(5)                  Open vSwitch Manual                 ovn-ic-nb(5)
+
+NAME
+       ovn-ic-nb - OVN_IC_Northbound database schema
+
+       This  database is the interface for cloud management system (CMS), such
+       as OpenStack, to configure OVN interconnection settings. The  CMS  proā€
+       duces  almost  all  of the contents of the database. The ovn-ic program
+       monitors the database contents, transforms it, and stores it  into  the
+       OVN_IC_Southbound database.
+
+       We  generally  speak  of  ``theā€™ā€™ CMS, but one can imagine scenarios in
+       which multiple CMSes manage different parts of OVN interconnection.
+
+   External IDs
+       Each of the tables in this database contains a  special  column,  named
+       external_ids.  This  column has the same form and purpose each place it
+       appears.
+
+              external_ids: map of string-string pairs
+                     Key-value pairs for use by the CMS.  The  CMS  might  use
+                     certain  pairs,  for example, to identify entities in its
+                     own configuration that correspond to those in this  dataā€
+                     base.
+
+TABLE SUMMARY
+       The  following list summarizes the purpose of each of the tables in the
+       OVN_IC_Northbound database.  Each table is described in more detail  on
+       a later page.
+
+       Table     Purpose
+       IC_NB_Global
+                 IC Northbound configuration
+       Transit_Switch
+                 Transit logical switch
+       SSL       SSL configuration.
+       Connection
+                 OVSDB client connections.
+
+IC_NB_Global TABLE
+       Northbound  configuration for OVN interconnection. This table must have
+       exactly one row.
+
+   Summary:
+       Common Columns:
+         external_ids                map of string-string pairs
+       Common options:
+         options                     map of string-string pairs
+         options : ic_probe_interval
+                                     optional string
+       Connection Options:
+         connections                 set of Connections
+         ssl                         optional SSL
+
+   Details:
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+     Common options:
+
+       options: map of string-string pairs
+              This column provides general key/value settings.  The  supported
+              options are described individually below.
+
+       options : ic_probe_interval: optional string
+              The  inactivity  probe  interval of the connection to the OVN IC
+              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.
+
+     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ā€ā€
+              tion table for more information.
+
+       ssl: optional SSL
+              Global SSL configuration.
+
+Transit_Switch TABLE
+       Each row represents one transit logical switch for interconnection  beā€
+       tween different OVN deployments (availability zones).
+
+   Summary:
+       Naming:
+         name                        string (must be unique within table)
+       Common Columns:
+         other_config                map of string-string pairs
+         external_ids                map of string-string pairs
+
+   Details:
+     Naming:
+
+       name: string (must be unique within table)
+              A name that uniquely identifies the transit logical switch.
+
+     Common Columns:
+
+       other_config: map of string-string pairs
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+SSL TABLE
+       SSL configuration for ovn-nb database access.
+
+   Summary:
+       private_key                   string
+       certificate                   string
+       ca_cert                       string
+       bootstrap_ca_cert             boolean
+       ssl_protocols                 string
+       ssl_ciphers                   string
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       private_key: string
+              Name  of  a  PEM  file  containing  the  private key used as the
+              switchā€™s identity for SSL connections to the controller.
+
+       certificate: string
+              Name of a PEM file containing a certificate, signed by the  cerā€
+              tificate authority (CA) used by the controller and manager, that
+              certifies  the  switchā€™s  private key, identifying a trustworthy
+              switch.
+
+       ca_cert: string
+              Name of a PEM file containing the CA certificate used to  verify
+              that the switch is connected to a trustworthy controller.
+
+       bootstrap_ca_cert: boolean
+              If  set to true, then Open vSwitch will attempt to obtain the CA
+              certificate from the controller on its first SSL connection  and
+              save  it to the named PEM file. If it is successful, it will 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 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
+              omitted is HIGH:!aNULL:!MD5.
+
+     Common Columns:
+
+       The  overall purpose of these columns is described under Common Columns
+       at the beginning of this document.
+
+       external_ids: map of string-string pairs
+Connection TABLE
+       Configuration for a database connection to  an  Open  vSwitch  database
+       (OVSDB) client.
+
+       This  table  primarily  configures  the  Open  vSwitch  database server
+       (ovsdb-server).
+
+       The Open vSwitch database server can initiate and maintain active  conā€
+       nections  to  remote  clients.  It can also listen for database connecā€
+       tions.
+
+   Summary:
+       Core Features:
+         target                      string (must be unique within table)
+       Client Failure Detection and Handling:
+         max_backoff                 optional integer, at least 1,000
+         inactivity_probe            optional integer
+       Status:
+         is_connected                boolean
+         status : last_error         optional string
+         status : state              optional string, one of ACTIVE,  BACKOFF,
+                                     CONNECTING, IDLE, or VOID
+         status : sec_since_connect  optional  string,  containing an integer,
+                                     at least 0
+         status : sec_since_disconnect
+                                     optional string, containing  an  integer,
+                                     at least 0
+         status : locks_held         optional string
+         status : locks_waiting      optional string
+         status : locks_lost         optional string
+         status : n_connections      optional  string,  containing an integer,
+                                     at least 2
+         status : bound_port         optional string, containing an integer
+       Common Columns:
+         external_ids                map of string-string pairs
+         other_config                map of string-string pairs
+
+   Details:
+     Core Features:
+
+       target: string (must be unique within table)
+              Connection methods for clients.
+
+              The following connection methods are currently supported:
+
+              ssl:host[:port]
+                     The specified SSL port on the host  at  the  given  host,
+                     which can either be a DNS name (if built with unbound 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.
+
+                     If port is not specified, it defaults to 6640.
+
+                     SSL support is an optional feature  that  is  not  always
+                     built as part of Open vSwitch.
+
+              tcp:host[:port]
+                     The  specified  TCP  port  on the host at the given host,
+                     which can either be a DNS name (if built with unbound 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.
+
+              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 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
+                     then it listens only on IPv4 (but not IPv6) addresses.  A
+                     valid  SSL  configuration must be provided when this form
+                     is used, this can be specified  either  via  command-line
+                     options or the SSL table.
+
+                     If port is not specified, it defaults to 6640.
+
+                     SSL  support  is  an  optional feature that is not always
+                     built as part of Open vSwitch.
+
+              ptcp:[port][:host]
+                     Listens for connections on the specified TCP port.  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 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
+              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 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
+              inactivity probes.
+
+     Status:
+
+       Key-value pair of is_connected is always updated. Other key-value pairs
+       in the status columns may be updated depends on the target type.
+
+       When target specifies a connection method that listens for inbound conā€
+       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ā€
+       ted.
+
+       is_connected: boolean
+              true if currently connected to this client, false otherwise.
+
+       status : last_error: optional string
+              A human-readable description of the last error on the connection
+              to the manager; i.e. strerror(errno). This key will  exist  only
+              if an error has occurred.
+
+       status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
+       IDLE, or VOID
+              The state of the connection to the manager:
+
+              VOID   Connection is disabled.
+
+              BACKOFF
+                     Attempting to reconnect at an increasing period.
+
+              CONNECTING
+                     Attempting to connect.
+
+              ACTIVE Connected, remote host responsive.
+
+              IDLE   Connection is idle. Waiting for response to keep-alive.
+
+              These  values  may  change in the future. They are provided only
+              for human consumption.
+
+       status : sec_since_connect: optional string, containing an integer, at
+       least 0
+              The amount of time since this client last successfully connected
+              to the database (in seconds). Value is empty if client has never
+              successfully been connected.
+
+       status : sec_since_disconnect: optional string, containing an integer,
+       at least 0
+              The amount of time since this client last disconnected from  the
+              database  (in  seconds). Value is empty if client has never 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
+              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ā€
+              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
+              locks have been stolen from this connection.
+
+       status : n_connections: optional string, containing an integer, at
+       least 2
+              When target specifies a connection method that listens  for  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
+              available port.)
+
+     Common Columns:
+
+       The  overall purpose of these columns is described under Common Columns
+       at the beginning of this document.
+
+       external_ids: map of string-string pairs
+
+       other_config: map of string-string pairs
+
+Open vSwitch 23.06.3            DB Schema 1.0.0                   ovn-ic-nb(5)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic-nb.5.pdf b/src/static/support/dist-docs-branch-23.06/ovn-ic-nb.5.pdf new file mode 100644 index 00000000..579be215 Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-ic-nb.5.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic-nb.5.txt b/src/static/support/dist-docs-branch-23.06/ovn-ic-nb.5.txt new file mode 100644 index 00000000..6cc1cf65 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ic-nb.5.txt @@ -0,0 +1,372 @@ +ovn-ic-nb(5) Open vSwitch Manual ovn-ic-nb(5) + +NAME + ovn-ic-nb - OVN_IC_Northbound database schema + + This database is the interface for cloud management system (CMS), such + as OpenStack, to configure OVN interconnection settings. The CMS proā€ + duces almost all of the contents of the database. The ovn-ic program + monitors the database contents, transforms it, and stores it into the + OVN_IC_Southbound database. + + We generally speak of ``theā€™ā€™ CMS, but one can imagine scenarios in + which multiple CMSes manage different parts of OVN interconnection. + + External IDs + Each of the tables in this database contains a special column, named + external_ids. This column has the same form and purpose each place it + appears. + + external_ids: map of string-string pairs + Key-value pairs for use by the CMS. The CMS might use + certain pairs, for example, to identify entities in its + own configuration that correspond to those in this dataā€ + base. + +TABLE SUMMARY + The following list summarizes the purpose of each of the tables in the + OVN_IC_Northbound database. Each table is described in more detail on + a later page. + + Table Purpose + IC_NB_Global + IC Northbound configuration + Transit_Switch + Transit logical switch + SSL SSL configuration. + Connection + OVSDB client connections. + +IC_NB_Global TABLE + Northbound configuration for OVN interconnection. This table must have + exactly one row. + + Summary: + Common Columns: + external_ids map of string-string pairs + Common options: + options map of string-string pairs + options : ic_probe_interval + optional string + Connection Options: + connections set of Connections + ssl optional SSL + + Details: + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + + Common options: + + options: map of string-string pairs + This column provides general key/value settings. The supported + options are described individually below. + + options : ic_probe_interval: optional string + The inactivity probe interval of the connection to the OVN IC + 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. + + 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ā€ā€ + tion table for more information. + + ssl: optional SSL + Global SSL configuration. + +Transit_Switch TABLE + Each row represents one transit logical switch for interconnection beā€ + tween different OVN deployments (availability zones). + + Summary: + Naming: + name string (must be unique within table) + Common Columns: + other_config map of string-string pairs + external_ids map of string-string pairs + + Details: + Naming: + + name: string (must be unique within table) + A name that uniquely identifies the transit logical switch. + + Common Columns: + + other_config: map of string-string pairs + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +SSL TABLE + SSL configuration for ovn-nb database access. + + Summary: + private_key string + certificate string + ca_cert string + bootstrap_ca_cert boolean + ssl_protocols string + ssl_ciphers string + Common Columns: + external_ids map of string-string pairs + + Details: + private_key: string + Name of a PEM file containing the private key used as the + switchā€™s identity for SSL connections to the controller. + + certificate: string + Name of a PEM file containing a certificate, signed by the cerā€ + tificate authority (CA) used by the controller and manager, that + certifies the switchā€™s private key, identifying a trustworthy + switch. + + ca_cert: string + Name of a PEM file containing the CA certificate used to verify + that the switch is connected to a trustworthy controller. + + bootstrap_ca_cert: boolean + If set to true, then Open vSwitch will attempt to obtain the CA + certificate from the controller on its first SSL connection and + save it to the named PEM file. If it is successful, it will 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 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 + omitted is HIGH:!aNULL:!MD5. + + Common Columns: + + The overall purpose of these columns is described under Common Columns + at the beginning of this document. + + external_ids: map of string-string pairs +Connection TABLE + Configuration for a database connection to an Open vSwitch database + (OVSDB) client. + + This table primarily configures the Open vSwitch database server + (ovsdb-server). + + The Open vSwitch database server can initiate and maintain active conā€ + nections to remote clients. It can also listen for database connecā€ + tions. + + Summary: + Core Features: + target string (must be unique within table) + Client Failure Detection and Handling: + max_backoff optional integer, at least 1,000 + inactivity_probe optional integer + Status: + is_connected boolean + status : last_error optional string + status : state optional string, one of ACTIVE, BACKOFF, + CONNECTING, IDLE, or VOID + status : sec_since_connect optional string, containing an integer, + at least 0 + status : sec_since_disconnect + optional string, containing an integer, + at least 0 + status : locks_held optional string + status : locks_waiting optional string + status : locks_lost optional string + status : n_connections optional string, containing an integer, + at least 2 + status : bound_port optional string, containing an integer + Common Columns: + external_ids map of string-string pairs + other_config map of string-string pairs + + Details: + Core Features: + + target: string (must be unique within table) + Connection methods for clients. + + The following connection methods are currently supported: + + ssl:host[:port] + The specified SSL port on the host at the given host, + which can either be a DNS name (if built with unbound 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. + + If port is not specified, it defaults to 6640. + + SSL support is an optional feature that is not always + built as part of Open vSwitch. + + tcp:host[:port] + The specified TCP port on the host at the given host, + which can either be a DNS name (if built with unbound 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. + + 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 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 + then it listens only on IPv4 (but not IPv6) addresses. A + valid SSL configuration must be provided when this form + is used, this can be specified either via command-line + options or the SSL table. + + If port is not specified, it defaults to 6640. + + SSL support is an optional feature that is not always + built as part of Open vSwitch. + + ptcp:[port][:host] + Listens for connections on the specified TCP port. 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 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 + 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 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 + inactivity probes. + + Status: + + Key-value pair of is_connected is always updated. Other key-value pairs + in the status columns may be updated depends on the target type. + + When target specifies a connection method that listens for inbound conā€ + 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ā€ + ted. + + is_connected: boolean + true if currently connected to this client, false otherwise. + + status : last_error: optional string + A human-readable description of the last error on the connection + to the manager; i.e. strerror(errno). This key will exist only + if an error has occurred. + + status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING, + IDLE, or VOID + The state of the connection to the manager: + + VOID Connection is disabled. + + BACKOFF + Attempting to reconnect at an increasing period. + + CONNECTING + Attempting to connect. + + ACTIVE Connected, remote host responsive. + + IDLE Connection is idle. Waiting for response to keep-alive. + + These values may change in the future. They are provided only + for human consumption. + + status : sec_since_connect: optional string, containing an integer, at + least 0 + The amount of time since this client last successfully connected + to the database (in seconds). Value is empty if client has never + successfully been connected. + + status : sec_since_disconnect: optional string, containing an integer, + at least 0 + The amount of time since this client last disconnected from the + database (in seconds). Value is empty if client has never 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 + 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ā€ + 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 + locks have been stolen from this connection. + + status : n_connections: optional string, containing an integer, at + least 2 + When target specifies a connection method that listens for 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 + available port.) + + Common Columns: + + The overall purpose of these columns is described under Common Columns + at the beginning of this document. + + external_ids: map of string-string pairs + + other_config: map of string-string pairs + +Open vSwitch 23.06.3 DB Schema 1.0.0 ovn-ic-nb(5) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic-nbctl.8 b/src/static/support/dist-docs-branch-23.06/ovn-ic-nbctl.8 new file mode 100644 index 00000000..db793d4b --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ic-nbctl.8 @@ -0,0 +1,424 @@ +'\" p +.\" -*- nroff -*- +.TH "ovn-ic-nbctl" 8 "ovn-ic-nbctl" "OVN 23\[char46]06\[char46]3" "OVN Manual" +.fp 5 L CR \\" Make fixed-width font available as \\fL. +.de TQ +. br +. ns +. TP "\\$1" +.. +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +.de SU +. PP +. I "\\$1" +.. +.PP +.SH "NAME" +.PP +.PP +ovn-ic-nbctl \- Open Virtual Network interconnection northbound db management utility +.SH "SYNOPSIS" +.PP +\fBovn\-ic\-nbctl\fR [\fIoptions\fR] \fIcommand\fR [\fIarg\fR\[char46]\[char46]\[char46]] +.SH "DESCRIPTION" +.PP +.PP +This utility can be used to manage the OVN interconnection northbound database\[char46] +.SH "GENERAL COMMANDS" +.TP +\fBinit\fR +Initializes the database, if it is empty\[char46] If the database has already been initialized, this command has no effect\[char46] +.TP +\fBshow\fR +Prints a brief overview of the database contents\[char46] +.SH "TRANSIT SWITCH COMMANDS" +.TP +[\fB\-\-may\-exist\fR] \fBts\-add\fR \fIswitch\fR +Creates a new transit switch named \fIswitch\fR\[char46] +.IP +Transit switch names must be unique\[char46] Adding a duplicated name results in error\[char46] With \fB\-\-may\-exist\fR, adding a duplicate name succeeds but does not create a new transit switch\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBts\-del\fR \fIswitch\fR +Deletes \fIswitch\fR\[char46] It is an error if \fIswitch\fR does not exist, unless \fB\-\-if\-exists\fR is specified\[char46] +.TP +\fBts\-list\fR +Lists all existing switches on standard output, one per line\[char46] +.SH "DATABASE COMMANDS" +.PP +.PP +These commands query and modify the contents of \fBovsdb\fR tables\[char46] They are a slight abstraction of the \fBovsdb\fR interface and as such they operate at a lower level than other \fBovn\-ic\-nbctl\fR commands\[char46] +.PP +\fIIdentifying Tables, Records, and Columns\fR +.PP +.PP +Each of these commands has a \fItable\fR parameter to identify a table within the database\[char46] Many of them also take a \fIrecord\fR parameter that identifies a particular record within a table\[char46] The \fIrecord\fR 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\[char46] Many tables offer additional ways to identify records\[char46] Some commands also take \fIcolumn\fR parameters that identify a particular field within the records in a table\[char46] +.PP +.PP +For a list of tables and their columns, see \fBovn\-ic\-nb\fR(5) or see the table listing from the \fB\-\-help\fR option\[char46] +.PP +.PP +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\[char46] Names of tables and columns are not case-sensitive, and \fB\-\fR and \fB_\fR are treated interchangeably\[char46] Unique abbreviations of table and column names are acceptable, e\[char46]g\[char46] \fBt\fR or \fBtransit\fR is sufficient to identify the \fBTransit_Switch\fR table\[char46] +.PP +.PP +.PP +\fIDatabase Values\fR +.PP +.PP +Each column in the database accepts a fixed type of data\[char46] The currently defined basic types, and their representations, are: +.RS +.TP +integer +A decimal integer in the range \-2**63 to 2**63\-1, inclusive\[char46] +.TP +real +A floating-point number\[char46] +.TP +Boolean +True or false, written \fBtrue\fR or \fBfalse\fR, respectively\[char46] +.TP +string +An arbitrary Unicode string, except that null bytes are not allowed\[char46] Quotes are optional for most strings that begin with an English letter or underscore and consist only of letters, underscores, hyphens, and periods\[char46] However, \fBtrue\fR and \fBfalse\fR and strings that match the syntax of UUIDs (see below) must be enclosed in double quotes to distinguish them from other basic types\[char46] When double quotes are used, the syntax is that of strings in JSON, e\[char46]g\[char46] backslashes may be used to escape special characters\[char46] The empty string must be represented as a pair of double quotes (\fB\(dq\(dq\fR)\[char46] +.TP +UUID +Either a universally unique identifier in the style of RFC 4122, e\[char46]g\[char46] \fBf81d4fae\-7dec\-11d0\-a765\-00a0c91e6bf6\fR, or an \fB@\fR\fIname\fR defined by a \fBget\fR or \fBcreate\fR command within the same \fBovs\-vsctl\fR invocation\[char46] +.RE +.PP +.PP +Multiple values in a single column may be separated by spaces or a single comma\[char46] When multiple values are present, duplicates are not allowed, and order is not important\[char46] Conversely, some database columns can have an empty set of values, represented as \fB[]\fR, and square brackets may optionally enclose other non-empty sets or single values as well\[char46] +.PP +.PP +A few database columns are ``maps\(cq\(cq of key-value pairs, where the key and the value are each some fixed database type\[char46] These are specified in the form \fIkey\fR\fB=\fR\fIvalue\fR, where \fIkey\fR and \fIvalue\fR follow the syntax for the column\(cqs key type and value type, respectively\[char46] When multiple pairs are present (separated by spaces or a comma), duplicate keys are not allowed, and again the order is not important\[char46] Duplicate values are allowed\[char46] An empty map is represented as \fB{}\fR\[char46] Curly braces may optionally enclose non-empty maps as well (but use quotes to prevent the shell from expanding \fBother\-config={0=x,1=y}\fR into \fBother\-config=0=x +other\-config=1=y\fR, which may not have the desired effect)\[char46] +.PP +\fIDatabase Command Syntax\fR +.RS +.TP +[\fB\-\-if\-exists\fR] [\fB\-\-columns=\fR\fIcolumn\fR[\fB,\fR\fIcolumn\fR]\[char46]\[char46]\[char46]] \fBlist\fR \fItable\fR [\fIrecord\fR]\[char46]\[char46]\[char46] +Lists the data in each specified \fIrecord\fR\[char46] If no records are specified, lists all the records in \fItable\fR\[char46] +.IP +If \fB\-\-columns\fR is specified, only the requested columns are listed, in the specified order\[char46] Otherwise, all columns are listed, in alphabetical order by column name\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if any specified \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, the command ignores any \fIrecord\fR that does not exist, without producing any output\[char46] +.TP +[\fB\-\-columns=\fR\fIcolumn\fR[\fB,\fR\fIcolumn\fR]\[char46]\[char46]\[char46]] \fBfind\fR \fItable\fR [\fIcolumn\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR]\[char46]\[char46]\[char46] +Lists the data in each record in \fItable\fR whose \fIcolumn\fR equals \fIvalue\fR or, if \fIkey\fR is specified, whose \fIcolumn\fR contains a \fIkey\fR with the specified \fIvalue\fR\[char46] The following operators may be used where \fB=\fR is written in the syntax summary: +.RS +.TP +\fB= != < > <= >=\fR +Selects records in which \fIcolumn\fR[\fB:\fR\fIkey\fR] equals, does not equal, is less than, is greater than, is less than or equal to, or is greater than or equal to \fIvalue\fR, respectively\[char46] +.IP +Consider \fIcolumn\fR[\fB:\fR\fIkey\fR] and \fIvalue\fR as sets of elements\[char46] Identical sets are considered equal\[char46] Otherwise, if the sets have different numbers of elements, then the set with more elements is considered to be larger\[char46] Otherwise, consider a element from each set pairwise, in increasing order within each set\[char46] The first pair that differs determines the result\[char46] (For a column that contains key-value pairs, first all the keys are compared, and values are considered only if the two sets contain identical keys\[char46]) +.TP +\fB{=} {!=}\fR +Test for set equality or inequality, respectively\[char46] +.TP +\fB{<=}\fR +Selects records in which \fIcolumn\fR[\fB:\fR\fIkey\fR] is a subset of \fIvalue\fR\[char46] For example, \fBflood\-vlans{<=}1,2\fR selects records in which the \fBflood\-vlans\fR column is the empty set or contains 1 or 2 or both\[char46] +.TP +\fB{<}\fR +Selects records in which \fIcolumn\fR[\fB:\fR\fIkey\fR] is a proper subset of \fIvalue\fR\[char46] For example, \fBflood\-vlans{<}1,2\fR selects records in which the \fBflood\-vlans\fR column is the empty set or contains 1 or 2 but not both\[char46] +.TP +\fB{>=} {>}\fR +Same as \fB{<=}\fR and \fB{<}\fR, respectively, except that the relationship is reversed\[char46] For example, \fBflood\-vlans{>=}1,2\fR selects records in which the \fBflood\-vlans\fR column contains both 1 and 2\[char46] +.RE +.IP +The following operators are available only in Open vSwitch 2\[char46]16 and later: +.RS +.TP +\fB{in}\fR +Selects records in which every element in \fIcolumn\fR[\fB:\fR\fIkey\fR] is also in \fIvalue\fR\[char46] (This is the same as \fB{<=}\fR\[char46]) +.TP +\fB{not\-in}\fR +Selects records in which every element in \fIcolumn\fR[\fB:\fR\fIkey\fR] is not in \fIvalue\fR\[char46] +.RE +.IP +For arithmetic operators (\fB= != < > <= >=\fR), when \fIkey\fR is specified but a particular record\(cqs \fIcolumn\fR does not contain \fIkey\fR, the record is always omitted from the results\[char46] Thus, the condition \fBother\-config:mtu!=1500\fR matches records that have a \fBmtu\fR key whose value is not 1500, but not those that lack an \fBmtu\fR key\[char46] +.IP +For the set operators, when \fIkey\fR is specified but a particular record\(cqs \fIcolumn\fR does not contain \fIkey\fR, the comparison is done against an empty set\[char46] Thus, the condition \fBother\-config:mtu{!=}1500\fR matches records that have a \fBmtu\fR key whose value is not 1500 and those that lack an \fBmtu\fR key\[char46] +.IP +Don\(cqt forget to escape \fB<\fR or \fB>\fR from interpretation by the shell\[char46] +.IP +If \fB\-\-columns\fR is specified, only the requested columns are listed, in the specified order\[char46] Otherwise all columns are listed, in alphabetical order by column name\[char46] +.IP +The UUIDs shown for rows created in the same \fBovs\-vsctl\fR invocation will be wrong\[char46] +.TP +[\fB\-\-if\-exists\fR] [\fB\-\-id=@\fR\fIname\fR] \fBget\fR \fItable record\fR [\fIcolumn\fR[\fB:\fR\fIkey\fR]]\[char46]\[char46]\[char46] +Prints the value of each specified \fIcolumn\fR in the given \fIrecord\fR in \fItable\fR\[char46] For map columns, a \fIkey\fR may optionally be specified, in which case the value associated with \fIkey\fR in the column is printed, instead of the entire map\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist or \fIkey\fR is specified, if \fIkey\fR does not exist in \fIrecord\fR\[char46] With \fB\-\-if\-exists\fR, a missing \fIrecord\fR yields no output and a missing \fIkey\fR prints a blank line\[char46] +.IP +If \fB@\fR\fIname\fR is specified, then the UUID for \fIrecord\fR may be referred to by that name later in the same \fBovs\-vsctl\fR invocation in contexts where a UUID is expected\[char46] +.IP +Both \fB\-\-id\fR and the \fIcolumn\fR arguments are optional, but usually at least one or the other should be specified\[char46] If both are omitted, then \fBget\fR has no effect except to verify that \fIrecord\fR exists in \fItable\fR\[char46] +.IP +\fB\-\-id\fR and \fB\-\-if\-exists\fR cannot be used together\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBset\fR \fItable record column\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR\[char46]\[char46]\[char46] +Sets the value of each specified \fIcolumn\fR in the given \fIrecord\fR in \fItable\fR to \fIvalue\fR\[char46] For map columns, a \fIkey\fR may optionally be specified, in which case the value associated with \fIkey\fR in that column is changed (or added, if none exists), instead of the entire map\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, this command does nothing if \fIrecord\fR does not exist\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBadd\fR \fItable record column\fR [\fIkey\fR\fB=\fR]\fIvalue\fR\[char46]\[char46]\[char46] +Adds the specified value or key-value pair to \fIcolumn\fR in \fIrecord\fR in \fItable\fR\[char46] If \fIcolumn\fR is a map, then \fIkey\fR is required, otherwise it is prohibited\[char46] If \fIkey\fR already exists in a map column, then the current \fIvalue\fR is not replaced (use the \fBset\fR command to replace an existing value)\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, this command does nothing if \fIrecord\fR does not exist\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBremove\fR \fItable record column value\fR\[char46]\[char46]\[char46] +.IP +[\fB\-\-if\-exists\fR] \fBremove\fR \fItable record column key\fR\[char46]\[char46]\[char46] +.IP +[\fB\-\-if\-exists\fR] \fBremove\fR \fItable record column key\fR\fB=\fR\fIvalue\fR\[char46]\[char46]\[char46] +Removes the specified values or key-value pairs from \fIcolumn\fR in \fIrecord\fR in \fItable\fR\[char46] The first form applies to columns that are not maps: each specified \fIvalue\fR is removed from the column\[char46] The second and third forms apply to map columns: if only a \fIkey\fR is specified, then any key-value pair with the given \fIkey\fR is removed, regardless of its value; if a \fIvalue\fR is given then a pair is removed only if both key and value match\[char46] +.IP +It is not an error if the column does not contain the specified key or value or pair\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, this command does nothing if \fIrecord\fR does not exist\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBclear\fR \fItable record column\fR\[char46]\[char46]\[char46] +Sets each \fIcolumn\fR in \fIrecord\fR in \fItable\fR to the empty set or empty map, as appropriate\[char46] This command applies only to columns that are allowed to be empty\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, this command does nothing if \fIrecord\fR does not exist\[char46] +.TP +[\fB\-\-id=(@\fR\fIname\fR|\fIuuid\fR)] \fBcreate\fR \fItable column\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR\[char46]\[char46]\[char46] +Creates a new record in \fItable\fR and sets the initial values of each \fIcolumn\fR\[char46] Columns not explicitly set will receive their default values\[char46] Outputs the UUID of the new row\[char46] +.IP +If \fB@\fR\fIname\fR is specified, then the UUID for the new row may be referred to by that name elsewhere in the same \fB\e*(PN\fR invocation in contexts where a UUID is expected\[char46] Such references may precede or follow the \fBcreate\fR command\[char46] +.IP +If a valid \fIuuid\fR is specified, then it is used as the UUID of the new row\[char46] +.RS +.TP +Caution (ovs-vsctl as example) +Records in the Open vSwitch database are significant only when they can be reached directly or indirectly from the \fBOpen_vSwitch\fR table\[char46] Except for records in the \fBQoS\fR or \fBQueue\fR tables, records that are not reachable from the \fBOpen_vSwitch\fR table are automatically deleted from the database\[char46] This deletion happens immediately, without waiting for additional \fBovs\-vsctl\fR commands or other database activity\[char46] Thus, a \fBcreate\fR command must generally be accompanied by additional commands \fIwithin the same\fR \fBovs\-vsctl\fR \fIinvocation\fR to add a chain of references to the newly created record from the top-level \fBOpen_vSwitch\fR record\[char46] The \fBEXAMPLES\fR section gives some examples that show how to do this\[char46] +.RE +.TP +[\fB\-\-if\-exists\fR] \fBdestroy\fR \fItable record\fR\[char46]\[char46]\[char46] +Deletes each specified \fIrecord\fR from \fItable\fR\[char46] Unless \fB\-\-if\-exists\fR is specified, each \fIrecord\fRs must exist\[char46] +.TP +\fB\-\-all destroy\fR \fItable\fR +Deletes all records from the \fItable\fR\[char46] +.RS +.TP +Caution (ovs-vsctl as example) +The \fBdestroy\fR command is only useful for records in the \fBQoS\fR or \fBQueue\fR tables\[char46] Records in other tables are automatically deleted from the database when they become unreachable from the \fBOpen_vSwitch\fR table\[char46] This means that deleting the last reference to a record is sufficient for deleting the record itself\[char46] For records in these tables, \fBdestroy\fR is silently ignored\[char46] See the \fBEXAMPLES\fR section below for more information\[char46] +.RE +.TP +\fBwait\-until\fR \fItable record\fR [\fIcolumn\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR]\[char46]\[char46]\[char46] +Waits until \fItable\fR contains a record named \fIrecord\fR whose \fIcolumn\fR equals \fIvalue\fR or, if \fIkey\fR is specified, whose \fIcolumn\fR contains a \fIkey\fR with the specified \fIvalue\fR\[char46] This command supports the same operators and semantics described for the \fBfind\fR command above\[char46] +.IP +If no \fIcolumn\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR arguments are given, this command waits only until \fIrecord\fR exists\[char46] If more than one such argument is given, the command waits until all of them are satisfied\[char46] +.RS +.TP +Caution (ovs-vsctl as example) +Usually \fBwait\-until\fR should be placed at the beginning of a set of \fBovs\-vsctl\fR commands\[char46] For example, \fBwait\-until bridge br0 +\-\- get bridge br0 datapath_id\fR waits until a bridge named \fBbr0\fR is created, then prints its \fBdatapath_id\fR column, whereas \fBget bridge br0 datapath_id \-\- wait\-until bridge br0\fR will abort if no bridge named \fBbr0\fR exists when \fBovs\-vsctl\fR initially connects to the database\[char46] +.RE +.IP +Consider specifying \fB\-\-timeout=0\fR along with \fB\-\-wait\-until\fR, to prevent \fBovs\-vsctl\fR from terminating after waiting only at most 5 seconds\[char46] +.TP +\fBcomment\fR [\fIarg\fR]\[char46]\[char46]\[char46] +This command has no effect on behavior, but any database log record created by the command will include the command and its arguments\[char46] +.RE +.SH "REMOTE CONNECTIVITY COMMANDS" +.TP +\fBget\-connection\fR +Prints the configured connection(s)\[char46] +.TP +\fBdel\-connection\fR +Deletes the configured connection(s)\[char46] +.TP +[\fB\-\-inactivity\-probe=\fR\fImsecs\fR] \fBset\-connection\fR \fItarget\fR\[char46]\[char46]\[char46] +Sets the configured manager target or targets\[char46] Use \fB\-\-inactivity\-probe=\fR\fImsecs\fR to override the default idle connection inactivity probe time\[char46] Use 0 to disable inactivity probes\[char46] +.SH "SSL CONFIGURATION COMMANDS" +.TP +\fBget\-ssl\fR +Prints the SSL configuration\[char46] +.TP +\fBdel\-ssl\fR +Deletes the current SSL configuration\[char46] +.TP +[\fB\-\-bootstrap\fR] \fBset\-ssl\fR \fIprivate-key\fR \fIcertificate\fR \fIca-cert\fR [\fIssl-protocol-list\fR [\fIssl-cipher-list\fR]] +Sets the SSL configuration\[char46] +.SH "OPTIONS" +.TP +\fB\-\-db\fR \fIdatabase\fR +The OVSDB database remote to contact\[char46] If the \fBOVN_IC_NB_DB\fR environment variable is set, its value is used as the default\[char46] Otherwise, the default is \fBunix:/ovn_ic_nb_db\[char46]sock\fR, but this default is unlikely to be useful outside of single-machine OVN test environments\[char46] +.TP +\fB\-\-leader\-only\fR +.TQ .5in +\fB\-\-no\-leader\-only\fR +By default, or with \fB\-\-leader\-only\fR, when the database server is a clustered database, \fBovn\-ic\-nbctl\fR will avoid servers other than the cluster leader\[char46] This ensures that any data that \fBovn\-ic\-nbctl\fR reads and reports is up-to-date\[char46] With \fB\-\-no\-leader\-only\fR, \fBovn\-ic\-nbctl\fR 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 \fB\-\-no\-leader\-only\fR)\[char46] Refer to \fBUnderstanding Cluster Consistency\fR in \fBovsdb\fR(7) for more information\[char46] +.SH "LOGGING OPTIONS" +.TP +\fB\-v\fR[\fIspec\fR] +.TQ .5in +\fB\-\-verbose=\fR[\fIspec\fR] +Sets logging levels\[char46] Without any \fIspec\fR, sets the log level for every module and destination to \fBdbg\fR\[char46] Otherwise, \fIspec\fR is a list of words separated by spaces or commas or colons, up to one from each category below: +.RS +.IP \(bu +A valid module name, as displayed by the \fBvlog/list\fR command on \fBovs\-appctl\fR(8), limits the log level change to the specified module\[char46] +.IP \(bu +\fBsyslog\fR, \fBconsole\fR, or \fBfile\fR, to limit the log level change to only to the system log, to the console, or to a file, respectively\[char46] (If \fB\-\-detach\fR is specified, the daemon closes its standard file descriptors, so logging to the console will have no effect\[char46]) +.IP +On Windows platform, \fBsyslog\fR is accepted as a word and is only useful along with the \fB\-\-syslog\-target\fR option (the word has no effect otherwise)\[char46] +.IP \(bu +\fBoff\fR, \fBemer\fR, \fBerr\fR, \fBwarn\fR, \fBinfo\fR, or \fBdbg\fR, to control the log level\[char46] Messages of the given severity or higher will be logged, and messages of lower severity will be filtered out\[char46] \fBoff\fR filters out all messages\[char46] See \fBovs\-appctl\fR(8) for a definition of each log level\[char46] +.RE +.IP +Case is not significant within \fIspec\fR\[char46] +.IP +Regardless of the log levels set for \fBfile\fR, logging to a file will not take place unless \fB\-\-log\-file\fR is also specified (see below)\[char46] +.IP +For compatibility with older versions of OVS, \fBany\fR is accepted as a word but has no effect\[char46] +.TP +\fB\-v\fR +.TQ .5in +\fB\-\-verbose\fR +Sets the maximum logging verbosity level, equivalent to \fB\-\-verbose=dbg\fR\[char46] +.TP +\fB\-vPATTERN:\fR\fIdestination\fR\fB:\fR\fIpattern\fR +.TQ .5in +\fB\-\-verbose=PATTERN:\fR\fIdestination\fR\fB:\fR\fIpattern\fR +Sets the log pattern for \fIdestination\fR to \fIpattern\fR\[char46] Refer to \fBovs\-appctl\fR(8) for a description of the valid syntax for \fIpattern\fR\[char46] +.TP +\fB\-vFACILITY:\fR\fIfacility\fR +.TQ .5in +\fB\-\-verbose=FACILITY:\fR\fIfacility\fR +Sets the RFC5424 facility of the log message\[char46] \fIfacility\fR can be one of \fBkern\fR, \fBuser\fR, \fBmail\fR, \fBdaemon\fR, \fBauth\fR, \fBsyslog\fR, \fBlpr\fR, \fBnews\fR, \fBuucp\fR, \fBclock\fR, \fBftp\fR, \fBntp\fR, \fBaudit\fR, \fBalert\fR, \fBclock2\fR, \fBlocal0\fR, \fBlocal1\fR, \fBlocal2\fR, \fBlocal3\fR, \fBlocal4\fR, \fBlocal5\fR, \fBlocal6\fR or \fBlocal7\fR\[char46] If this option is not specified, \fBdaemon\fR is used as the default for the local system syslog and \fBlocal0\fR is used while sending a message to the target provided via the \fB\-\-syslog\-target\fR option\[char46] +.TP +\fB\-\-log\-file\fR[\fB=\fR\fIfile\fR] +Enables logging to a file\[char46] If \fIfile\fR is specified, then it is used as the exact name for the log file\[char46] The default log file name used if \fIfile\fR is omitted is \fB/usr/local/var/log/ovn/\fIprogram\fB\[char46]log\fR\[char46] +.TP +\fB\-\-syslog\-target=\fR\fIhost\fR\fB:\fR\fIport\fR +Send syslog messages to UDP \fIport\fR on \fIhost\fR, in addition to the system syslog\[char46] The \fIhost\fR must be a numerical IP address, not a hostname\[char46] +.TP +\fB\-\-syslog\-method=\fR\fImethod\fR +Specify \fImethod\fR as how syslog messages should be sent to syslog daemon\[char46] The following forms are supported: +.RS +.IP \(bu +\fBlibc\fR, to use the libc \fBsyslog()\fR function\[char46] Downside of using this options is that libc adds fixed prefix to every message before it is actually sent to the syslog daemon over \fB/dev/log\fR UNIX domain socket\[char46] +.IP \(bu +\fBunix:\fIfile\fB\fR, to use a UNIX domain socket directly\[char46] It is possible to specify arbitrary message format with this option\[char46] However, \fBrsyslogd 8\[char46]9\fR and older versions use hard coded parser function anyway that limits UNIX domain socket use\[char46] If you want to use arbitrary message format with older \fBrsyslogd\fR versions, then use UDP socket to localhost IP address instead\[char46] +.IP \(bu +\fBudp:\fIip\fB:\fIport\fB\fR, to use a UDP socket\[char46] With this method it is possible to use arbitrary message format also with older \fBrsyslogd\fR\[char46] When sending syslog messages over UDP socket extra precaution needs to be taken into account, for example, 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\[char46] +.IP \(bu +\fBnull\fR, to discard all messages logged to syslog\[char46] +.RE +.IP +The default is taken from the \fBOVS_SYSLOG_METHOD\fR environment variable; if it is unset, the default is \fBlibc\fR\[char46] +.SH "TABLE FORMATTING OPTIONS" +These options control the format of output from the \fBlist\fR and \fBfind\fR commands\[char46] +.RS +.TP +\fB\-f\fR \fIformat\fR +.TQ .5in +\fB\-\-format=\fR\fIformat\fR +Sets the type of table formatting\[char46] The following types of \fIformat\fR are available: +.RS +.TP +\fBtable\fR +2-D text tables with aligned columns\[char46] +.TP +\fBlist\fR (default) +A list with one column per line and rows separated by a blank line\[char46] +.TP +\fBhtml\fR +HTML tables\[char46] +.TP +\fBcsv\fR +Comma-separated values as defined in RFC 4180\[char46] +.TP +\fBjson\fR +JSON format as defined in RFC 4627\[char46] The output is a sequence of JSON objects, each of which corresponds to one table\[char46] Each JSON object has the following members with the noted values: +.RS +.TP +\fBcaption\fR +The table\(cqs caption\[char46] This member is omitted if the table has no caption\[char46] +.TP +\fBheadings\fR +An array with one element per table column\[char46] Each array element is a string giving the corresponding column\(cqs heading\[char46] +.TP +\fBdata\fR +An array with one element per table row\[char46] Each element is also an array with one element per table column\[char46] The elements of this second-level array are the cells that constitute the table\[char46] Cells that represent OVSDB data or data types are expressed in the format described in the OVSDB specification; other cells are simply expressed as text strings\[char46] +.RE +.RE +.TP +\fB\-d\fR \fIformat\fR +.TQ .5in +\fB\-\-data=\fR\fIformat\fR +Sets the formatting for cells within output tables unless the table format is set to \fBjson\fR, in which case \fBjson\fR formatting is always used when formatting cells\[char46] The following types of \fIformat\fR are available: +.RS +.TP +\fBstring\fR (default) +The simple format described in the \fBDatabase Values\fR section of \fBovs\-vsctl\fR(8)\[char46] +.TP +\fBbare\fR +The simple format with punctuation stripped off: \fB[]\fR and \fB{}\fR are omitted around sets, maps, and empty columns, items within sets and maps are space-separated, and strings are never quoted\[char46] This format may be easier for scripts to parse\[char46] +.TP +\fBjson\fR +The RFC 4627 JSON format as described above\[char46] +.RE +.TP +\fB\-\-no\-headings\fR +This option suppresses the heading row that otherwise appears in the first row of table output\[char46] +.TP +\fB\-\-pretty\fR +By default, JSON in output is printed as compactly as possible\[char46] This option causes JSON in output to be printed in a more readable fashion\[char46] Members of objects and elements of arrays are printed one per line, with indentation\[char46] +.IP +This option does not affect JSON in tables, which is always printed compactly\[char46] +.TP +\fB\-\-bare\fR +Equivalent to \fB\-\-format=list \-\-data=bare \-\-no\-headings\fR\[char46] +.RE +.SS "PKI Options" +.PP +.PP +PKI configuration is required to use SSL for the connection to the database\[char46] +.RS +.TP +\fB\-p\fR \fIprivkey\[char46]pem\fR +.TQ .5in +\fB\-\-private\-key=\fR\fIprivkey\[char46]pem\fR +Specifies a PEM file containing the private key used as identity for outgoing SSL connections\[char46] +.TP +\fB\-c\fR \fIcert\[char46]pem\fR +.TQ .5in +\fB\-\-certificate=\fR\fIcert\[char46]pem\fR +Specifies a PEM file containing a certificate that certifies the private key specified on \fB\-p\fR or \fB\-\-private\-key\fR to be trustworthy\[char46] The certificate must be signed by the certificate authority (CA) that the peer in SSL connections will use to verify it\[char46] +.TP +\fB\-C\fR \fIcacert\[char46]pem\fR +.TQ .5in +\fB\-\-ca\-cert=\fR\fIcacert\[char46]pem\fR +Specifies a PEM file containing the CA certificate for verifying certificates presented to this program by SSL peers\[char46] (This may be the same certificate that SSL peers use to verify the certificate specified on \fB\-c\fR or \fB\-\-certificate\fR, or it may be a different one, depending on the PKI design in use\[char46]) +.TP +\fB\-C none\fR +.TQ .5in +\fB\-\-ca\-cert=none\fR +Disables verification of certificates presented by SSL peers\[char46] This introduces a security risk, because it means that certificates cannot be verified to be those of known trusted hosts\[char46] +.RE +.RS +.TP +\fB\-\-bootstrap\-ca\-cert=\fR\fIcacert\[char46]pem\fR +When \fIcacert\[char46]pem\fR exists, this option has the same effect as \fB\-C\fR or \fB\-\-ca\-cert\fR\[char46] If it does not exist, then the executable will attempt to obtain the CA certificate from the SSL peer on its first SSL connection and save it to the named PEM file\[char46] 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\[char46] +.IP +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\[char46] +.IP +This option is only useful if the SSL peer sends its CA certificate as part of the SSL certificate chain\[char46] The SSL protocol does not require the server to send the CA certificate\[char46] +.IP +This option is mutually exclusive with \fB\-C\fR and \fB\-\-ca\-cert\fR\[char46] +.RE +.SS "Other Options" +.TP +\fB\-h\fR +.TQ .5in +\fB\-\-help\fR +Prints a brief help message to the console\[char46] +.TP +\fB\-V\fR +.TQ .5in +\fB\-\-version\fR +Prints version information to the console\[char46] diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic-nbctl.8.html b/src/static/support/dist-docs-branch-23.06/ovn-ic-nbctl.8.html new file mode 100644 index 00000000..1145f1b2 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ic-nbctl.8.html @@ -0,0 +1,639 @@ +
+ovn-ic-nbctl(8)                   OVN Manual                   ovn-ic-nbctl(8)
+
+NAME
+       ovn-ic-nbctl  - Open Virtual Network interconnection northbound db manā€
+       agement utility
+
+SYNOPSIS
+       ovn-ic-nbctl [options] command [arg...]
+
+DESCRIPTION
+       This utility can be used to manage the OVN  interconnection  northbound
+       database.
+
+GENERAL COMMANDS
+       init   Initializes  the  database,  if it is empty. If the database has
+              already been initialized, this command has no effect.
+
+       show   Prints a brief overview of the database contents.
+
+TRANSIT SWITCH COMMANDS
+       [--may-exist] ts-add switch
+              Creates a new transit switch named switch.
+
+              Transit switch names must be unique. Adding  a  duplicated  name
+              results in error. With --may-exist, adding a duplicate name sucā€
+              ceeds but does not create a new transit switch.
+
+       [--if-exists] ts-del switch
+              Deletes  switch. It is an error if switch does not exist, unless
+              --if-exists is specified.
+
+       ts-list
+              Lists all existing switches on standard output, one per line.
+
+DATABASE COMMANDS
+       These commands query and modify the contents of ovsdb tables. They  are
+       a slight abstraction of the ovsdb interface and as such they operate at
+       a lower level than other ovn-ic-nbctl commands.
+
+       Identifying Tables, Records, and Columns
+
+       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
+       that identify a particular field within the records in a table.
+
+       For a list of tables and their columns, see ovn-ic-nb(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
+       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,
+       e.g. t or transit is sufficient to identify the Transit_Switch table.
+
+       Database Values
+
+       Each column in the database accepts a fixed type of data. The currently
+       defined basic types, and their representations, are:
+
+              integer
+                     A decimal integer in the range -2**63 to 2**63-1,  incluā€
+                     sive.
+
+              real   A floating-point number.
+
+              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ā€
+                     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
+                     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
+                     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 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  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
+              [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
+                     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  igā€
+                     nores  any  record that does not exist, without producing
+                     any output.
+
+              [--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ā€
+                     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
+                            value, respectively.
+
+                            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
+                            pairs, first all the keys are compared, and values
+                            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
+                            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 the flood-vlans column is
+                            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
+                            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
+                            {=}.)
+
+                     {not-in}
+                            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
+                     not those that lack an mtu key.
+
+                     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
+                     key.
+
+                     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
+                     invocation will be wrong.
+
+              [--if-exists] [--id=@name] get table record [column[:key]]...
+                     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
+                     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 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
+                     both are omitted, then get has no effect except to verify
+                     that record exists in table.
+
+                     --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  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
+                     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  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
+                     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ā€
+                     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
+                     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.
+
+                     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
+                     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
+                     record does not exist.
+
+              [--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
+                     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
+                     references may precede or follow the create command.
+
+                     If a valid uuid is specified, then it is used as the UUID
+                     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 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
+                            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
+                            some examples that show how to do this.
+
+              [--if-exists] destroy table record...
+                     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
+                            for more information.
+
+              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
+                     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
+                     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ā€ā€
+                            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
+                            ovs-vsctl initially connects to the database.
+
+                     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ā€
+                     mand and its arguments.
+
+REMOTE CONNECTIVITY COMMANDS
+       get-connection
+              Prints the configured connection(s).
+
+       del-connection
+              Deletes the configured connection(s).
+
+       [--inactivity-probe=msecs] set-connection target...
+              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.
+
+SSL CONFIGURATION COMMANDS
+       get-ssl
+              Prints the SSL configuration.
+
+       del-ssl
+              Deletes the current SSL configuration.
+
+       [--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_NB_DB enviā€
+              ronment variable is set, its value is used as the default.  Othā€
+              erwise, the default is unix:/ovn_ic_nb_db.sock, but this default
+              is  unlikely to be useful outside of single-machine OVN test enā€
+              vironments.
+
+       --leader-only
+       --no-leader-only
+            By default, or with --leader-only, when the database server  is  a
+            clustered database, ovn-ic-nbctl will avoid servers other than the
+            cluster leader. This ensures that any data that ovn-ic-nbctl reads
+            and  reports  is  up-to-date.  With --no-leader-only, ovn-ic-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  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
+            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
+                   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, 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
+                   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
+                   definition of each log level.
+
+            Case is not significant within spec.
+
+            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
+            word but has no effect.
+
+       -v
+       --verbose
+            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-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,
+            local4, local5, local6 or local7. If this option is not specified,
+            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
+            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.
+
+       --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ā€
+            name.
+
+       --syslog-method=method
+            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
+                   /dev/log UNIX domain socket.
+
+            ā€¢      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  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ā€
+       mands.
+
+              -f format
+              --format=format
+                   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
+                          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
+                          members with the noted values:
+
+                          caption
+                                 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
+                                 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-
+                                 level array are the cells that constitute the
+                                 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
+                   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:
+
+                   string (default)
+                          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
+                          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 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
+                   arrays are printed one per line, with indentation.
+
+                   This option does not affect JSON in tables, which is always
+                   printed compactly.
+
+              --bare
+                   Equivalent to --format=list --data=bare --no-headings.
+
+   PKI Options
+       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
+                   identity for outgoing SSL connections.
+
+              -c cert.pem
+              --certificate=cert.pem
+                   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
+                   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
+                   verify the certificate specified on -c or --certificate, or
+                   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
+                   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ā€
+                     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.
+
+                     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
+                     certificate as part of the SSL certificate chain. The SSL
+                     protocol does not require the server to send the CA  cerā€
+                     tificate.
+
+                     This option is mutually exclusive with -C and --ca-cert.
+
+   Other Options
+       -h
+       --help
+            Prints a brief help message to the console.
+
+       -V
+       --version
+            Prints version information to the console.
+
+OVN 23.06.3                      ovn-ic-nbctl                  ovn-ic-nbctl(8)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic-nbctl.8.pdf b/src/static/support/dist-docs-branch-23.06/ovn-ic-nbctl.8.pdf new file mode 100644 index 00000000..f0b7ec2e Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-ic-nbctl.8.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic-nbctl.8.txt b/src/static/support/dist-docs-branch-23.06/ovn-ic-nbctl.8.txt new file mode 100644 index 00000000..b39b76bd --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ic-nbctl.8.txt @@ -0,0 +1,637 @@ +ovn-ic-nbctl(8) OVN Manual ovn-ic-nbctl(8) + +NAME + ovn-ic-nbctl - Open Virtual Network interconnection northbound db manā€ + agement utility + +SYNOPSIS + ovn-ic-nbctl [options] command [arg...] + +DESCRIPTION + This utility can be used to manage the OVN interconnection northbound + database. + +GENERAL COMMANDS + init Initializes the database, if it is empty. If the database has + already been initialized, this command has no effect. + + show Prints a brief overview of the database contents. + +TRANSIT SWITCH COMMANDS + [--may-exist] ts-add switch + Creates a new transit switch named switch. + + Transit switch names must be unique. Adding a duplicated name + results in error. With --may-exist, adding a duplicate name sucā€ + ceeds but does not create a new transit switch. + + [--if-exists] ts-del switch + Deletes switch. It is an error if switch does not exist, unless + --if-exists is specified. + + ts-list + Lists all existing switches on standard output, one per line. + +DATABASE COMMANDS + These commands query and modify the contents of ovsdb tables. They are + a slight abstraction of the ovsdb interface and as such they operate at + a lower level than other ovn-ic-nbctl commands. + + Identifying Tables, Records, and Columns + + 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 + that identify a particular field within the records in a table. + + For a list of tables and their columns, see ovn-ic-nb(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 + 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, + e.g. t or transit is sufficient to identify the Transit_Switch table. + + Database Values + + Each column in the database accepts a fixed type of data. The currently + defined basic types, and their representations, are: + + integer + A decimal integer in the range -2**63 to 2**63-1, incluā€ + sive. + + real A floating-point number. + + 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ā€ + 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 + 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 + 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 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 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 + [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 + 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 igā€ + nores any record that does not exist, without producing + any output. + + [--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ā€ + 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 + value, respectively. + + 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 + pairs, first all the keys are compared, and values + 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 + 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 the flood-vlans column is + 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 + 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 + {<=}.) + + {not-in} + 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 + not those that lack an mtu key. + + 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 + key. + + 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 + invocation will be wrong. + + [--if-exists] [--id=@name] get table record [column[:key]]... + 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 + 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 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 + both are omitted, then get has no effect except to verify + that record exists in table. + + --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 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 + 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 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 + 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ā€ + 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 + 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. + + 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 + 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 + record does not exist. + + [--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 + 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 + references may precede or follow the create command. + + If a valid uuid is specified, then it is used as the UUID + 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 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 + 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 + some examples that show how to do this. + + [--if-exists] destroy table record... + 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 + for more information. + + 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 + 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 + 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ā€ā€ + 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 + ovs-vsctl initially connects to the database. + + 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ā€ + mand and its arguments. + +REMOTE CONNECTIVITY COMMANDS + get-connection + Prints the configured connection(s). + + del-connection + Deletes the configured connection(s). + + [--inactivity-probe=msecs] set-connection target... + 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. + +SSL CONFIGURATION COMMANDS + get-ssl + Prints the SSL configuration. + + del-ssl + Deletes the current SSL configuration. + + [--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_NB_DB enviā€ + ronment variable is set, its value is used as the default. Othā€ + erwise, the default is unix:/ovn_ic_nb_db.sock, but this default + is unlikely to be useful outside of single-machine OVN test enā€ + vironments. + + --leader-only + --no-leader-only + By default, or with --leader-only, when the database server is a + clustered database, ovn-ic-nbctl will avoid servers other than the + cluster leader. This ensures that any data that ovn-ic-nbctl reads + and reports is up-to-date. With --no-leader-only, ovn-ic-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 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 + 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 + 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, 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 + 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 + definition of each log level. + + Case is not significant within spec. + + 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 + word but has no effect. + + -v + --verbose + 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-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, + local4, local5, local6 or local7. If this option is not specified, + 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 + 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. + + --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ā€ + name. + + --syslog-method=method + 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 + /dev/log UNIX domain socket. + + ā€¢ 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 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ā€ + mands. + + -f format + --format=format + 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 + 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 + members with the noted values: + + caption + 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 + 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- + level array are the cells that constitute the + 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 + 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: + + string (default) + 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 + 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 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 + arrays are printed one per line, with indentation. + + This option does not affect JSON in tables, which is always + printed compactly. + + --bare + Equivalent to --format=list --data=bare --no-headings. + + PKI Options + 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 + identity for outgoing SSL connections. + + -c cert.pem + --certificate=cert.pem + 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 + 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 + verify the certificate specified on -c or --certificate, or + 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 + 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ā€ + 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. + + 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 + certificate as part of the SSL certificate chain. The SSL + protocol does not require the server to send the CA cerā€ + tificate. + + This option is mutually exclusive with -C and --ca-cert. + + Other Options + -h + --help + Prints a brief help message to the console. + + -V + --version + Prints version information to the console. + +OVN 23.06.3 ovn-ic-nbctl ovn-ic-nbctl(8) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic-sb.5 b/src/static/support/dist-docs-branch-23.06/ovn-ic-sb.5 new file mode 100644 index 00000000..177e2e05 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ic-sb.5 @@ -0,0 +1,656 @@ +'\" p +.\" -*- nroff -*- +.TH "ovn-ic-sb" 5 " DB Schema 1.1.1" "Open vSwitch 23.06.3" "Open vSwitch Manual" +.fp 5 L CR \\" Make fixed-width font available as \\fL. +.de TQ +. br +. ns +. TP "\\$1" +.. +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +.SH NAME +ovn-ic-sb \- OVN_IC_Southbound database schema +.PP +.PP +.PP +.PP +This database holds configuration and state for interconnecting different OVN deployments\[char46] The content of the database is populated and used by the \fBovn\-ic\fR program in each OVN deployment, and not supposed to be directly used by CMS or end user\[char46] +.PP +.PP +The OVN Interconnection Southbound database is shared by \fBovn\-ic\fR program in each OVN deployment\[char46] It contains interconnection information from all related OVN deployments, and is used as the intermediate store for each OVN deployment to exchange the information\[char46] The \fBovn\-ic\fR program in each deployment is responsible for syncing the data between this database and the its own northbound and southbound databases\[char46] +.SS "Database Structure" +.PP +.PP +The OVN Interconnection Southbound database contains classes of data with different properties, as described in the sections below\[char46] +.ST "Availability Zone Specific Information" +.PP +.PP +These tables contain objects that are availability zone specific\[char46] Each object is owned and populated by one availability zone, and read by other availability zones\[char46] +.PP +.PP +The \fBAvailability_Zone\fR, \fBGateway\fR, \fBEncap\fR and \fBPort_Binding\fR tables are the availability zone specific tables\[char46] +.ST "Global Information" +.PP +.PP +The data that does not belong to any specific availability zone but is common for all availability zones\[char46] +.PP +.PP +The \fBDatapath_Binding\fR table contains the common datapath binding information\[char46] +.ST "Common Columns" +.PP +.PP +Each of the tables in this database contains a special column, named \fBexternal_ids\fR\[char46] This column has the same form and purpose each place it appears\[char46] +.RS +.TP +\fBexternal_ids\fR: map of string-string pairs +Key-value pairs for use by \fBovn\-ic\fR\[char46] +.RE +.SH "TABLE SUMMARY" +.PP +The following list summarizes the purpose of each of the tables in the +\fBOVN_IC_Southbound\fR database. Each table is described in more detail on a later +page. +.IP "Table" 1in +Purpose +.TQ 1in +\fBIC_SB_Global\fR +IC Southbound configuration +.TQ 1in +\fBAvailability_Zone\fR +Availability Zone Information +.TQ 1in +\fBGateway\fR +Interconnection Gateway Information +.TQ 1in +\fBEncap\fR +Encapsulation Types +.TQ 1in +\fBDatapath_Binding\fR +Transit Switch Datapath Bindings +.TQ 1in +\fBPort_Binding\fR +Transit Port Bindings +.TQ 1in +\fBRoute\fR +Route +.TQ 1in +\fBConnection\fR +OVSDB client connections\[char46] +.TQ 1in +\fBSSL\fR +SSL 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.764118,0.478405 wid 1.279064 height 0.478405 "IC_SB_Global" +box at 0.764118,0.478405 wid 1.223508 height 0.422849 +linethick = 1.000000; +box at 4.006642,0.956810 wid 1.039861 height 0.478405 "Connection" +linethick = 1.000000; +box at 4.006642,0.239203 wid 0.717608 height 0.478405 "SSL" +linethick = 0.500000; +box at 4.006642,1.940219 wid 1.528217 height 0.478405 "Availability_Zone" +box at 4.006642,1.940219 wid 1.472661 height 0.422849 +linethick = 0.500000; +box at 0.764118,2.312323 wid 0.850499 height 0.478405 "Gateway" +box at 0.764118,2.312323 wid 0.794943 height 0.422849 +linethick = 1.000000; +box at 4.006642,3.029930 wid 0.717608 height 0.478405 "Encap" +linethick = 0.500000; +box at 0.764118,3.760837 wid 1.528217 height 0.478405 "Datapath_Binding" +box at 0.764118,3.760837 wid 1.472661 height 0.422849 +linethick = 0.500000; +box at 0.764118,3.043230 wid 1.189411 height 0.478405 "Port_Binding" +box at 0.764118,3.043230 wid 1.133855 height 0.422849 +linethick = 0.500000; +box at 0.764118,1.448515 wid 0.717608 height 0.478405 "Route" +box at 0.764118,1.448515 wid 0.662052 height 0.422849 +linethick = 1.000000; +spline -> from 1.405363,0.591510 to 1.405363,0.591510 to 1.525442,0.612138 to 1.650210,0.632892 to 1.767419,0.651167 to 2.355188,0.742762 to 3.032609,0.833697 to 3.484224,0.892244 +"connections*" at 2.385423,0.918605 +linethick = 1.000000; +spline -> from 1.408903,0.431435 to 1.408903,0.431435 to 2.076565,0.381767 to 3.105805,0.305222 to 3.641715,0.265362 +"ssl?" at 2.385423,0.506640 +linethick = 1.000000; +spline -> from 1.192472,2.124118 to 1.192472,2.124118 to 1.366325,2.054941 to 1.572900,1.985094 to 1.767419,1.950170 to 2.252426,1.863100 to 2.806419,1.860326 to 3.240428,1.879462 +"availability_zone" at 2.385423,2.034848 +linethick = 1.000000; +spline -> from 1.193908,2.278643 to 1.193908,2.278643 to 1.648966,2.255105 to 2.394417,2.255488 to 3.003331,2.441875 to 3.244160,2.515549 to 3.487764,2.659166 to 3.673098,2.786039 +"encaps+" at 2.385423,2.526552 +linethick = 1.000000; +spline -> from 1.364507,2.947740 to 1.364507,2.947740 to 1.972272,2.846797 to 2.853782,2.693803 to 3.003331,2.631228 to 3.264349,2.522055 to 3.525462,2.335860 to 3.713858,2.184206 +"availability_zone" at 2.385423,2.965154 +linethick = 0.500000; +spline -> from 1.363263,3.098246 to 1.363263,3.098246 to 1.496068,3.108484 to 1.636528,3.117670 to 1.767419,3.122932 to 2.316246,3.144939 to 2.454600,3.148670 to 3.003331,3.122932 to 3.217178,3.112886 to 3.456093,3.090783 to 3.645733,3.070595 +"encap?" at 2.385423,3.230860 +linethick = 1.000000; +spline -> from 1.127888,1.449471 to 1.127888,1.449471 to 1.569360,1.456552 to 2.349351,1.488605 to 3.003331,1.617966 to 3.104370,1.637963 to 3.209523,1.665041 to 3.311902,1.694989 +"availability_zone" at 2.385423,1.702643 +.ps +3 +.PE +.RE\} +.bp +.SH "IC_SB_Global TABLE" +.PP +.PP +.PP +Interconnection Southbound configuration\[char46] This table must have exactly one row\[char46] +.SS "Summary: +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.TQ 2.75in +\fBoptions\fR +map of string-string pairs +.RE +.TQ .25in +\fIConnection Options:\fR +.RS .25in +.TQ 2.75in +\fBconnections\fR +set of \fBConnection\fRs +.TQ 2.75in +\fBssl\fR +optional \fBSSL\fR +.RE +.SS "Details: +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.IP "\fBoptions\fR: map of string-string pairs" +.ST "Connection Options:" +.PP +.IP "\fBconnections\fR: set of \fBConnection\fRs" +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\[char46] See the \fBConnection\fR table for more information\[char46] +.IP "\fBssl\fR: optional \fBSSL\fR" +Global SSL configuration\[char46] +.bp +.SH "Availability_Zone TABLE" +.PP +.PP +.PP +Each row in this table represents an Availability Zone\[char46] Each OVN deployment is considered an availability zone from OVN control plane perspective, with its own central components, such as northbound and southbound databases and \fBovn\-northd\fR daemon\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.SS "Details: +.IP "\fBname\fR: string (must be unique within table)" +A name that uniquely identifies the availability zone\[char46] +.bp +.SH "Gateway TABLE" +.PP +.PP +.PP +Each row in this table represents a interconnection gateway chassis in an availability zone\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBavailability_zone\fR +\fBAvailability_Zone\fR +.TQ 3.00in +\fBhostname\fR +string +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.TQ .25in +\fIEncapsulation Configuration:\fR +.RS .25in +.TQ 2.75in +\fBencaps\fR +set of 1 or more \fBEncap\fRs +.RE +.SS "Details: +.IP "\fBname\fR: string (must be unique within table)" +The name of the gateway\[char46] See \fBname\fR column of the OVN Southbound database\(cqs \fBChassis\fR table\[char46] +.IP "\fBavailability_zone\fR: \fBAvailability_Zone\fR" +The availability zone that the gateway belongs to\[char46] +.IP "\fBhostname\fR: string" +The hostname of the gateway\[char46] +.ST "Common Columns:" +.PP +The overall purpose of these columns is described under \fBCommon +Columns\fR at the beginning of this document\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +.ST "Encapsulation Configuration:" +.PP +.PP +.PP +OVN uses encapsulation to transmit logical dataplane packets between gateways\[char46] +.IP "\fBencaps\fR: set of 1 or more \fBEncap\fRs" +Points to supported encapsulation configurations to transmit logical dataplane packets to this gateway\[char46] Each entry is a \fBEncap\fR record that describes the configuration\[char46] See \fBencaps\fR column of the OVN Southbound database\(cqs \fBChassis\fR table\[char46] +.bp +.SH "Encap TABLE" +.PP +.PP +.PP +The \fBencaps\fR column in the \fBGateway\fR table refers to rows in this table to identify how OVN may transmit logical dataplane packets to this gateway\[char46] +.SS "Summary: +.TQ 3.00in +\fBtype\fR +string, one of \fBgeneve\fR, \fBstt\fR, or \fBvxlan\fR +.TQ 3.00in +\fBoptions\fR +map of string-string pairs +.TQ 3.00in +\fBip\fR +string +.TQ 3.00in +\fBgateway_name\fR +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 gateway\[char46] See \fBtype\fR column of the OVN Southbound database\(cqs \fBEncap\fR table\[char46] +.IP "\fBoptions\fR: map of string-string pairs" +Options for configuring the encapsulation, which may be \fBtype\fR specific\[char46] See \fBoptions\fR column of the OVN Southbound database\(cqs \fBEncap\fR table\[char46] +.IP "\fBip\fR: string" +The IPv4 address of the encapsulation tunnel endpoint\[char46] +.IP "\fBgateway_name\fR: string" +The name of the gateway that created this encap\[char46] +.bp +.SH "Datapath_Binding TABLE" +.PP +.PP +.PP +Each row in this table represents a logical datapath for a transit logical switch configured in the OVN Interconnection Northbound database\(cqs \fBTransit_Switch\fR table\[char46] +.SS "Summary: +.TQ 3.00in +\fBtransit_switch\fR +string +.TQ 3.00in +\fBtunnel_key\fR +integer, in range 1 to 16,777,215 (must be unique within table) +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBtransit_switch\fR: string" +The name of the transit logical switch that is configured in the OVN Interconnection Northbound database\(cqs \fBTransit_Switch\fR table\[char46] +.IP "\fBtunnel_key\fR: integer, in range 1 to 16,777,215 (must be unique within table)" +The tunnel key value to which the logical datapath is bound\[char46] The key can be generated by any \fBovn\-ic\fR but the same key is shared by all availability zones so that the logical datapaths can be peered across them\[char46] A tunnel key for transit switch datapath binding must be globally unique\[char46] +.IP +For more information about the meanings of a tunnel key, see \fBtunnel_key\fR column of the OVN Southbound database\(cqs \fBDatapath_Binding\fR table\[char46] +.ST "Common Columns:" +.PP +The overall purpose of these columns is described under \fBCommon +Columns\fR at the beginning of this document\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +.bp +.SH "Port_Binding TABLE" +.PP +.PP +.PP +Each row in this table binds a logical port on the transit switch to a physical gateway and a tunnel key\[char46] Each port on the transit switch belongs to a specific availability zone\[char46] +.SS "Summary: +.TQ .25in +\fICore Features:\fR +.RS .25in +.TQ 2.75in +\fBtransit_switch\fR +string +.TQ 2.75in +\fBlogical_port\fR +string (must be unique within table) +.TQ 2.75in +\fBavailability_zone\fR +\fBAvailability_Zone\fR +.TQ 2.75in +\fBencap\fR +optional weak reference to \fBEncap\fR +.TQ 2.75in +\fBgateway\fR +string +.TQ 2.75in +\fBtunnel_key\fR +integer, in range 1 to 32,767 +.TQ 2.75in +\fBaddress\fR +string +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.ST "Core Features:" +.PP +.IP "\fBtransit_switch\fR: string" +The name of the transit switch that the corresponding logical port belongs to\[char46] +.IP "\fBlogical_port\fR: string (must be unique within table)" +A logical port, taken from \fBname\fR in the OVN_Northbound database\(cqs \fBLogical_Switch_Port\fR table\[char46] The logical port name must be unique across all availability zones\[char46] +.IP "\fBavailability_zone\fR: \fBAvailability_Zone\fR" +The availability zone that the port belongs to\[char46] +.IP "\fBencap\fR: optional weak reference to \fBEncap\fR" +Points to supported encapsulation configurations to transmit logical dataplane packets to this gateway\[char46] Each entry is a \fBEncap\fR record that describes the configuration\[char46] +.IP "\fBgateway\fR: string" +The name of the gateway that this port is physically located\[char46] +.IP "\fBtunnel_key\fR: integer, in range 1 to 32,767" +A number that represents the logical port in the key (e\[char46]g\[char46] STT key or Geneve TLV) field carried within tunnel protocol packets\[char46] The key can be generated by any \fBovn\-ic\fR but the same key is shared by all availability zones so that the packets can go through the datapath pipelines of different availability zones\[char46] +.IP +The tunnel ID must be unique within the scope of a logical datapath\[char46] +.IP +For more information about tunnel key, see \fBtunnel_key\fR column of the OVN Southbound database\(cqs \fBPort_Binding\fR table\[char46] +.IP "\fBaddress\fR: string" +The Ethernet address and IP addresses used by the corresponding logical router port peering with the transit switch port\[char46] It is a string combined with the value of \fBmac\fR column followed by the values in \fBnetworks\fR column in \fBLogical_Router_Port\fR table\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "Route TABLE" +.PP +.PP +.PP +Each row in this table represents a route advertised\[char46] +.SS "Summary: +.TQ .25in +\fICore Features:\fR +.RS .25in +.TQ 2.75in +\fBtransit_switch\fR +string +.TQ 2.75in +\fBavailability_zone\fR +\fBAvailability_Zone\fR +.TQ 2.75in +\fBroute_table\fR +string +.TQ 2.75in +\fBip_prefix\fR +string +.TQ 2.75in +\fBnexthop\fR +string +.TQ 2.75in +\fBorigin\fR +string, either \fBconnected\fR or \fBstatic\fR +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.ST "Core Features:" +.PP +.IP "\fBtransit_switch\fR: string" +The name of the transit switch, upon which the route is advertised\[char46] +.IP "\fBavailability_zone\fR: \fBAvailability_Zone\fR" +The availability zone that has advertised the route\[char46] +.IP "\fBroute_table\fR: string" +Route table within which this route was created\[char46] Empty value means \fI
\fR routing table\[char46] +.IP +Routes for directly-connected networks will be learned to \fI
\fR 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\[char46] +.IP +Static routes within route tables will be advertised and learned only if interconnecting transit switch\(cqs LRPs will have same value in \fBoptions:route_table\fR as NB \fBroute_table\fR or ICSB \fBroute_table\fR value respectively\[char46] +.IP "\fBip_prefix\fR: string" +IP prefix of this route (e\[char46]g\[char46] 192\[char46]168\[char46]100\[char46]0/24)\[char46] +.IP "\fBnexthop\fR: string" +Nexthop IP address for this route\[char46] +.IP "\fBorigin\fR: string, either \fBconnected\fR or \fBstatic\fR" +Can be one of \fBconnected\fR or \fBstatic\fR\[char46] Routes to directly-connected subnets - LRP\(cqs CIDRs are inserted to OVN IC SB DB with \fBconnected\fR value in \fBorigin\fR\[char46] Static routes are inserted to OVN IC SB DB with \fBstatic\fR value\[char46] Next when route is learned to another AZ NB DB by ovn-ic, route origin is synced to \fBoptions:origin\fR\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "Connection TABLE" +.PP +.PP +.PP +Configuration for a database connection to an Open vSwitch database (OVSDB) client\[char46] +.PP +.PP +This table primarily configures the Open vSwitch database server (\fBovsdb\-server\fR)\[char46] +.PP +.PP +The Open vSwitch database server can initiate and maintain active connections to remote clients\[char46] It can also listen for database connections\[char46] +.SS "Summary: +.TQ .25in +\fICore Features:\fR +.RS .25in +.TQ 2.75in +\fBtarget\fR +string (must be unique within table) +.RE +.TQ .25in +\fIClient Failure Detection and Handling:\fR +.RS .25in +.TQ 2.75in +\fBmax_backoff\fR +optional integer, at least 1,000 +.TQ 2.75in +\fBinactivity_probe\fR +optional integer +.RE +.TQ .25in +\fIStatus:\fR +.RS .25in +.TQ 2.75in +\fBis_connected\fR +boolean +.TQ 2.75in +\fBstatus : last_error\fR +optional string +.TQ 2.75in +\fBstatus : state\fR +optional string, one of \fBACTIVE\fR, \fBBACKOFF\fR, \fBCONNECTING\fR, \fBIDLE\fR, or \fBVOID\fR +.TQ 2.75in +\fBstatus : sec_since_connect\fR +optional string, containing an integer, at least 0 +.TQ 2.75in +\fBstatus : sec_since_disconnect\fR +optional string, containing an integer, at least 0 +.TQ 2.75in +\fBstatus : locks_held\fR +optional string +.TQ 2.75in +\fBstatus : locks_waiting\fR +optional string +.TQ 2.75in +\fBstatus : locks_lost\fR +optional string +.TQ 2.75in +\fBstatus : n_connections\fR +optional string, containing an integer, at least 2 +.TQ 2.75in +\fBstatus : bound_port\fR +optional string, containing an integer +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.TQ 2.75in +\fBother_config\fR +map of string-string pairs +.RE +.SS "Details: +.ST "Core Features:" +.PP +.IP "\fBtarget\fR: string (must be unique within table)" +Connection methods for clients\[char46] +.IP +The following connection methods are currently supported: +.RS +.TP +\fBssl:\fIhost\fB\fR[\fB:\fIport\fB\fR] +The specified SSL \fIport\fR on the given \fIhost\fR, which can either be a DNS name (if built with unbound library) or an IP address\[char46] A valid SSL configuration must be provided when this form is used, this configuration can be specified via command-line options or the \fBSSL\fR table\[char46] +.IP +If \fIport\fR is not specified, it defaults to 6640\[char46] +.IP +SSL support is an optional feature that is not always built as part of Open vSwitch\[char46] +.TP +\fBtcp:\fIhost\fB\fR[\fB:\fIport\fB\fR] +The specified TCP \fIport\fR on the given \fIhost\fR, which can either be a DNS name (if built with unbound library) or an IP address (IPv4 or IPv6)\[char46] If \fIhost\fR is an IPv6 address, wrap it in square brackets, e\[char46]g\[char46] \fBtcp:[::1]:6640\fR\[char46] +.IP +If \fIport\fR is not specified, it defaults to 6640\[char46] +.TP +\fBpssl:\fR[\fIport\fR][\fB:\fIhost\fB\fR] +Listens for SSL connections on the specified TCP \fIport\fR\[char46] Specify 0 for \fIport\fR to have the kernel automatically choose an available port\[char46] If \fIhost\fR, 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)\[char46] If \fIhost\fR is an IPv6 address, wrap in square brackets, e\[char46]g\[char46] \fBpssl:6640:[::1]\fR\[char46] If \fIhost\fR is not specified then it listens only on IPv4 (but not IPv6) addresses\[char46] A valid SSL configuration must be provided when this form is used, this can be specified either via command-line options or the \fBSSL\fR table\[char46] +.IP +If \fIport\fR is not specified, it defaults to 6640\[char46] +.IP +SSL support is an optional feature that is not always built as part of Open vSwitch\[char46] +.TP +\fBptcp:\fR[\fIport\fR][\fB:\fIhost\fB\fR] +Listens for connections on the specified TCP \fIport\fR\[char46] Specify 0 for \fIport\fR to have the kernel automatically choose an available port\[char46] If \fIhost\fR, 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)\[char46] If \fIhost\fR is an IPv6 address, wrap it in square brackets, e\[char46]g\[char46] \fBptcp:6640:[::1]\fR\[char46] If \fIhost\fR is not specified then it listens only on IPv4 addresses\[char46] +.IP +If \fIport\fR is not specified, it defaults to 6640\[char46] +.RE +.IP +When multiple clients are configured, the \fBtarget\fR values must be unique\[char46] Duplicate \fBtarget\fR values yield unspecified results\[char46] +.ST "Client Failure Detection and Handling:" +.PP +.IP "\fBmax_backoff\fR: optional integer, at least 1,000" +Maximum number of milliseconds to wait between connection attempts\[char46] Default is implementation-specific\[char46] +.IP "\fBinactivity_probe\fR: optional integer" +Maximum number of milliseconds of idle time on connection to the client before sending an inactivity probe message\[char46] If Open vSwitch does not communicate with the client for the specified number of seconds, it will send a probe\[char46] If a response is not received for the same additional amount of time, Open vSwitch assumes the connection has been broken and attempts to reconnect\[char46] Default is implementation-specific\[char46] A value of 0 disables inactivity probes\[char46] +.ST "Status:" +.PP +.PP +.PP +Key-value pair of \fBis_connected\fR is always updated\[char46] Other key-value pairs in the status columns may be updated depends on the \fBtarget\fR type\[char46] +.PP +.PP +When \fBtarget\fR specifies a connection method that listens for inbound connections (e\[char46]g\[char46] \fBptcp:\fR or \fBpunix:\fR), both \fBn_connections\fR and \fBis_connected\fR may also be updated while the remaining key-value pairs are omitted\[char46] +.PP +.PP +On the other hand, when \fBtarget\fR specifies an outbound connection, all key-value pairs may be updated, except the above-mentioned two key-value pairs associated with inbound connection targets\[char46] They are omitted\[char46] +.IP "\fBis_connected\fR: boolean" +\fBtrue\fR if currently connected to this client, \fBfalse\fR otherwise\[char46] +.IP "\fBstatus : last_error\fR: optional string" +A human-readable description of the last error on the connection to the manager; i\[char46]e\[char46] \fBstrerror(errno)\fR\[char46] This key will exist only if an error has occurred\[char46] +.IP "\fBstatus : state\fR: optional string, one of \fBACTIVE\fR, \fBBACKOFF\fR, \fBCONNECTING\fR, \fBIDLE\fR, or \fBVOID\fR" +The state of the connection to the manager: +.RS +.TP +\fBVOID\fR +Connection is disabled\[char46] +.TP +\fBBACKOFF\fR +Attempting to reconnect at an increasing period\[char46] +.TP +\fBCONNECTING\fR +Attempting to connect\[char46] +.TP +\fBACTIVE\fR +Connected, remote host responsive\[char46] +.TP +\fBIDLE\fR +Connection is idle\[char46] Waiting for response to keep-alive\[char46] +.RE +.IP +These values may change in the future\[char46] They are provided only for human consumption\[char46] +.IP "\fBstatus : sec_since_connect\fR: optional string, containing an integer, at least 0" +The amount of time since this client last successfully connected to the database (in seconds)\[char46] Value is empty if client has never successfully been connected\[char46] +.IP "\fBstatus : sec_since_disconnect\fR: optional string, containing an integer, at least 0" +The amount of time since this client last disconnected from the database (in seconds)\[char46] Value is empty if client has never disconnected\[char46] +.IP "\fBstatus : locks_held\fR: optional string" +Space-separated list of the names of OVSDB locks that the connection holds\[char46] Omitted if the connection does not hold any locks\[char46] +.IP "\fBstatus : locks_waiting\fR: optional string" +Space-separated list of the names of OVSDB locks that the connection is currently waiting to acquire\[char46] Omitted if the connection is not waiting for any locks\[char46] +.IP "\fBstatus : locks_lost\fR: optional string" +Space-separated list of the names of OVSDB locks that the connection has had stolen by another OVSDB client\[char46] Omitted if no locks have been stolen from this connection\[char46] +.IP "\fBstatus : n_connections\fR: optional string, containing an integer, at least 2" +When \fBtarget\fR specifies a connection method that listens for inbound connections (e\[char46]g\[char46] \fBptcp:\fR or \fBpssl:\fR) and more than one connection is actually active, the value is the number of active connections\[char46] Otherwise, this key-value pair is omitted\[char46] +.IP "\fBstatus : bound_port\fR: optional string, containing an integer" +When \fBtarget\fR is \fBptcp:\fR or \fBpssl:\fR, this is the TCP port on which the OVSDB server is listening\[char46] (This is particularly useful when \fBtarget\fR specifies a port of 0, allowing the kernel to choose any available port\[char46]) +.ST "Common Columns:" +.PP +The overall purpose of these columns is described under \fBCommon +Columns\fR at the beginning of this document\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +.IP "\fBother_config\fR: map of string-string pairs" +.bp +.SH "SSL TABLE" +.PP +SSL configuration for ovn-sb database access\[char46] +.SS "Summary: +.TQ 3.00in +\fBprivate_key\fR +string +.TQ 3.00in +\fBcertificate\fR +string +.TQ 3.00in +\fBca_cert\fR +string +.TQ 3.00in +\fBbootstrap_ca_cert\fR +boolean +.TQ 3.00in +\fBssl_protocols\fR +string +.TQ 3.00in +\fBssl_ciphers\fR +string +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBprivate_key\fR: string" +Name of a PEM file containing the private key used as the switch\(cqs identity for SSL connections to the controller\[char46] +.IP "\fBcertificate\fR: string" +Name of a PEM file containing a certificate, signed by the certificate authority (CA) used by the controller and manager, that certifies the switch\(cqs private key, identifying a trustworthy switch\[char46] +.IP "\fBca_cert\fR: string" +Name of a PEM file containing the CA certificate used to verify that the switch is connected to a trustworthy controller\[char46] +.IP "\fBbootstrap_ca_cert\fR: boolean" +If set to \fBtrue\fR, 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\[char46] 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\[char46] \fBThis option exposes the +SSL connection to a man\-in\-the\-middle attack obtaining the initial +CA certificate\[char46]\fR It may still be useful for bootstrapping\[char46] +.IP "\fBssl_protocols\fR: string" +List of SSL protocols to be enabled for SSL connections\[char46] The default when this option is omitted is \fBTLSv1,TLSv1\[char46]1,TLSv1\[char46]2\fR\[char46] +.IP "\fBssl_ciphers\fR: string" +List of ciphers (in OpenSSL cipher string format) to be supported for SSL connections\[char46] The default when this option is omitted is \fBHIGH:!aNULL:!MD5\fR\[char46] +.ST "Common Columns:" +.PP +The overall purpose of these columns is described under \fBCommon +Columns\fR at the beginning of this document\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic-sb.5.html b/src/static/support/dist-docs-branch-23.06/ovn-ic-sb.5.html new file mode 100644 index 00000000..4c4e7a38 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ic-sb.5.html @@ -0,0 +1,600 @@ +
+ovn-ic-sb(5)                  Open vSwitch Manual                 ovn-ic-sb(5)
+
+NAME
+       ovn-ic-sb - OVN_IC_Southbound database schema
+
+       This database holds configuration and state for interconnecting differā€
+       ent  OVN deployments. The content of the database is populated and used
+       by the ovn-ic program in each OVN deployment, and not  supposed  to  be
+       directly used by CMS or end user.
+
+       The OVN Interconnection Southbound database is shared by ovn-ic program
+       in  each  OVN  deployment. It contains interconnection information from
+       all related OVN deployments, and is used as the intermediate store  for
+       each  OVN deployment to exchange the information. The ovn-ic program in
+       each deployment is responsible for syncing the data between this  dataā€
+       base and the its own northbound and southbound databases.
+
+   Database Structure
+       The  OVN  Interconnection  Southbound database contains classes of data
+       with different properties, as described in the sections below.
+
+     Availability Zone Specific Information
+
+       These tables contain objects that are availability zone specific.  Each
+       object  is  owned  and  populated by one availability zone, and read by
+       other availability zones.
+
+       The Availability_Zone, Gateway, Encap and Port_Binding tables  are  the
+       availability zone specific tables.
+
+     Global Information
+
+       The  data that does not belong to any specific availability zone but is
+       common for all availability zones.
+
+       The Datapath_Binding table contains the common datapath binding  inforā€
+       mation.
+
+     Common Columns
+
+       Each  of  the  tables in this database contains a special column, named
+       external_ids. This column has the same form and purpose each  place  it
+       appears.
+
+              external_ids: map of string-string pairs
+                     Key-value pairs for use by ovn-ic.
+
+TABLE SUMMARY
+       The  following list summarizes the purpose of each of the tables in the
+       OVN_IC_Southbound database.  Each table is described in more detail  on
+       a later page.
+
+       Table     Purpose
+       IC_SB_Global
+                 IC Southbound configuration
+       Availability_Zone
+                 Availability Zone Information
+       Gateway   Interconnection Gateway Information
+       Encap     Encapsulation Types
+       Datapath_Binding
+                 Transit Switch Datapath Bindings
+       Port_Binding
+                 Transit Port Bindings
+       Route     Route
+       Connection
+                 OVSDB client connections.
+       SSL       SSL configuration.
+
+IC_SB_Global TABLE
+       Interconnection  Southbound configuration. This table must have exactly
+       one row.
+
+   Summary:
+       Common Columns:
+         external_ids                map of string-string pairs
+         options                     map of string-string pairs
+       Connection Options:
+         connections                 set of Connections
+         ssl                         optional SSL
+
+   Details:
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+       options: map of string-string pairs
+
+     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ā€ā€
+              tion table for more information.
+
+       ssl: optional SSL
+              Global SSL configuration.
+
+Availability_Zone TABLE
+       Each  row  in  this table represents an Availability Zone. Each OVN deā€
+       ployment is considered an availability zone from OVN control plane perā€
+       spective, with its own  central  components,  such  as  northbound  and
+       southbound databases and ovn-northd daemon.
+
+   Summary:
+       name                          string (must be unique within table)
+
+   Details:
+       name: string (must be unique within table)
+              A name that uniquely identifies the availability zone.
+
+Gateway TABLE
+       Each  row in this table represents a interconnection gateway chassis in
+       an availability zone.
+
+   Summary:
+       name                          string (must be unique within table)
+       availability_zone             Availability_Zone
+       hostname                      string
+       Common Columns:
+         external_ids                map of string-string pairs
+       Encapsulation Configuration:
+         encaps                      set of 1 or more Encaps
+
+   Details:
+       name: string (must be unique within table)
+              The name of the gateway. See name column of the  OVN  Southbound
+              databaseā€™s Chassis table.
+
+       availability_zone: Availability_Zone
+              The availability zone that the gateway belongs to.
+
+       hostname: string
+              The hostname of the gateway.
+
+     Common Columns:
+
+       The  overall purpose of these columns is described under Common Columns
+       at the beginning of this document.
+
+       external_ids: map of string-string pairs
+
+     Encapsulation Configuration:
+
+       OVN uses encapsulation to transmit logical  dataplane  packets  between
+       gateways.
+
+       encaps: set of 1 or more Encaps
+              Points  to  supported  encapsulation  configurations to transmit
+              logical dataplane packets to this gateway. Each entry is a Encap
+              record that describes the configuration. See  encaps  column  of
+              the OVN Southbound databaseā€™s Chassis table.
+
+Encap TABLE
+       The  encaps column in the Gateway table refers to rows in this table to
+       identify how OVN may transmit logical dataplane packets to  this  gateā€
+       way.
+
+   Summary:
+       type                          string, one of geneve, stt, or vxlan
+       options                       map of string-string pairs
+       ip                            string
+       gateway_name                  string
+
+   Details:
+       type: string, one of geneve, stt, or vxlan
+              The  encapsulation  to  use to transmit packets to this gateway.
+              See type column of the OVN Southbound databaseā€™s Encap table.
+
+       options: map of string-string pairs
+              Options for configuring the encapsulation,  which  may  be  type
+              specific.  See  options  column of the OVN Southbound databaseā€™s
+              Encap table.
+
+       ip: string
+              The IPv4 address of the encapsulation tunnel endpoint.
+
+       gateway_name: string
+              The name of the gateway that created this encap.
+
+Datapath_Binding TABLE
+       Each row in this table represents a logical datapath for a transit logā€
+       ical switch configured in the OVN Interconnection Northbound databaseā€™s
+       Transit_Switch table.
+
+   Summary:
+       transit_switch                string
+       tunnel_key                    integer, in range 1 to  16,777,215  (must
+                                     be unique within table)
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       transit_switch: string
+              The name of the transit logical switch that is configured in the
+              OVN Interconnection Northbound databaseā€™s Transit_Switch table.
+
+       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
+              key can be generated by any ovn-ic but the same key is shared by
+              all  availability  zones  so  that  the logical datapaths can be
+              peered across them. A tunnel key  for  transit  switch  datapath
+              binding must be globally unique.
+
+              For  more  information  about  the meanings of a tunnel key, see
+              tunnel_key  column  of  the  OVN  Southbound  databaseā€™s   Dataā€ā€
+              path_Binding table.
+
+     Common Columns:
+
+       The  overall purpose of these columns is described under Common Columns
+       at the beginning of this document.
+
+       external_ids: map of string-string pairs
+Port_Binding TABLE
+       Each row in this table binds a logical port on the transit switch to  a
+       physical  gateway and a tunnel key. Each port on the transit switch beā€
+       longs to a specific availability zone.
+
+   Summary:
+       Core Features:
+         transit_switch              string
+         logical_port                string (must be unique within table)
+         availability_zone           Availability_Zone
+         encap                       optional weak reference to Encap
+         gateway                     string
+         tunnel_key                  integer, in range 1 to 32,767
+         address                     string
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+     Core Features:
+
+       transit_switch: string
+              The name of the transit switch that  the  corresponding  logical
+              port belongs to.
+
+       logical_port: string (must be unique within table)
+              A logical port, taken from name in the OVN_Northbound databaseā€™s
+              Logical_Switch_Port  table. The logical port name must be unique
+              across all availability zones.
+
+       availability_zone: Availability_Zone
+              The availability zone that the port belongs to.
+
+       encap: optional weak reference to Encap
+              Points to supported  encapsulation  configurations  to  transmit
+              logical dataplane packets to this gateway. Each entry is a Encap
+              record that describes the configuration.
+
+       gateway: string
+              The name of the gateway that this port is physically located.
+
+       tunnel_key: integer, in range 1 to 32,767
+              A  number  that represents the logical port in the key (e.g. STT
+              key or Geneve TLV) field carried within tunnel protocol packets.
+              The key can be generated by any  ovn-ic  but  the  same  key  is
+              shared  by  all  availability  zones  so that the packets can go
+              through the datapath pipelines of different availability zones.
+
+              The tunnel ID must be unique within the scope of a logical dataā€
+              path.
+
+              For more information about tunnel key, see tunnel_key column  of
+              the OVN Southbound databaseā€™s Port_Binding table.
+
+       address: string
+              The  Ethernet address and IP addresses used by the corresponding
+              logical router port peering with the transit switch port. It  is
+              a  string  combined with the value of mac column followed by the
+              values in networks column in Logical_Router_Port table.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+Route TABLE
+       Each row in this table represents a route advertised.
+
+   Summary:
+       Core Features:
+         transit_switch              string
+         availability_zone           Availability_Zone
+         route_table                 string
+         ip_prefix                   string
+         nexthop                     string
+         origin                      string, either connected or static
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+     Core Features:
+
+       transit_switch: string
+              The name of the transit switch, upon which the route  is  adverā€
+              tised.
+
+       availability_zone: Availability_Zone
+              The availability zone that has advertised the route.
+
+       route_table: string
+              Route  table  within  which  this route was created. Empty value
+              means <lt;main>gt; routing table.
+
+              Routes for directly-connected networks will be learned to <lt;main>gt;
+              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ā€ā€
+              ble value respectively.
+
+       ip_prefix: string
+              IP prefix of this route (e.g. 192.168.100.0/24).
+
+       nexthop: string
+              Nexthop IP address for this route.
+
+       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ā€ā€
+              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.
+
+     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
+       (OVSDB) client.
+
+       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ā€
+       tions.
+
+   Summary:
+       Core Features:
+         target                      string (must be unique within table)
+       Client Failure Detection and Handling:
+         max_backoff                 optional integer, at least 1,000
+         inactivity_probe            optional integer
+       Status:
+         is_connected                boolean
+         status : last_error         optional string
+         status : state              optional  string, one of ACTIVE, BACKOFF,
+                                     CONNECTING, IDLE, or VOID
+         status : sec_since_connect  optional string, containing  an  integer,
+                                     at least 0
+         status : sec_since_disconnect
+                                     optional  string,  containing an integer,
+                                     at least 0
+         status : locks_held         optional string
+         status : locks_waiting      optional string
+         status : locks_lost         optional string
+         status : n_connections      optional string, containing  an  integer,
+                                     at least 2
+         status : bound_port         optional string, containing an integer
+       Common Columns:
+         external_ids                map of string-string pairs
+         other_config                map of string-string pairs
+
+   Details:
+     Core Features:
+
+       target: string (must be unique within table)
+              Connection methods for clients.
+
+              The following connection methods are currently supported:
+
+              ssl:host[:port]
+                     The  specified  SSL port on the 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
+                     built as part of Open vSwitch.
+
+              tcp:host[:port]
+                     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  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.
+
+                     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ā€
+                     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 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
+              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 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
+              inactivity probes.
+
+     Status:
+
+       Key-value pair of is_connected is always updated. Other key-value pairs
+       in the status columns may be updated depends on the target type.
+
+       When target specifies a connection method that listens for inbound conā€
+       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ā€
+       ted.
+
+       is_connected: boolean
+              true if currently connected to this client, false otherwise.
+
+       status : last_error: optional string
+              A human-readable description of the last error on the connection
+              to the manager; i.e. strerror(errno). This key will  exist  only
+              if an error has occurred.
+
+       status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
+       IDLE, or VOID
+              The state of the connection to the manager:
+
+              VOID   Connection is disabled.
+
+              BACKOFF
+                     Attempting to reconnect at an increasing period.
+
+              CONNECTING
+                     Attempting to connect.
+
+              ACTIVE Connected, remote host responsive.
+
+              IDLE   Connection is idle. Waiting for response to keep-alive.
+
+              These  values  may  change in the future. They are provided only
+              for human consumption.
+
+       status : sec_since_connect: optional string, containing an integer, at
+       least 0
+              The amount of time since this client last successfully connected
+              to the database (in seconds). Value is empty if client has never
+              successfully been connected.
+
+       status : sec_since_disconnect: optional string, containing an integer,
+       at least 0
+              The amount of time since this client last disconnected from  the
+              database  (in  seconds). Value is empty if client has never 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
+              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ā€
+              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
+              locks have been stolen from this connection.
+
+       status : n_connections: optional string, containing an integer, at
+       least 2
+              When target specifies a connection method that listens  for  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
+              available port.)
+
+     Common Columns:
+
+       The  overall purpose of these columns is described under Common Columns
+       at the beginning of this document.
+
+       external_ids: map of string-string pairs
+
+       other_config: map of string-string pairs
+SSL TABLE
+       SSL configuration for ovn-sb database access.
+
+   Summary:
+       private_key                   string
+       certificate                   string
+       ca_cert                       string
+       bootstrap_ca_cert             boolean
+       ssl_protocols                 string
+       ssl_ciphers                   string
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       private_key: string
+              Name of a PEM file  containing  the  private  key  used  as  the
+              switchā€™s identity for SSL connections to the controller.
+
+       certificate: string
+              Name  of a PEM file containing a certificate, signed by the cerā€
+              tificate authority (CA) used by the controller and manager, that
+              certifies the switchā€™s private key,  identifying  a  trustworthy
+              switch.
+
+       ca_cert: string
+              Name  of a PEM file containing the CA certificate used to verify
+              that the switch is connected to a trustworthy controller.
+
+       bootstrap_ca_cert: boolean
+              If set to true, then Open vSwitch will attempt to obtain the  CA
+              certificate  from the controller on its first SSL connection and
+              save it to the named PEM file. If it is successful, it will  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 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
+              omitted is HIGH:!aNULL:!MD5.
+
+     Common Columns:
+
+       The overall purpose of these columns is described under Common  Columns
+       at the beginning of this document.
+
+       external_ids: map of string-string pairs
+
+Open vSwitch 23.06.3            DB Schema 1.1.1                   ovn-ic-sb(5)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic-sb.5.pdf b/src/static/support/dist-docs-branch-23.06/ovn-ic-sb.5.pdf new file mode 100644 index 00000000..9a1d5d2f Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-ic-sb.5.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic-sb.5.txt b/src/static/support/dist-docs-branch-23.06/ovn-ic-sb.5.txt new file mode 100644 index 00000000..0403e397 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ic-sb.5.txt @@ -0,0 +1,598 @@ +ovn-ic-sb(5) Open vSwitch Manual ovn-ic-sb(5) + +NAME + ovn-ic-sb - OVN_IC_Southbound database schema + + This database holds configuration and state for interconnecting differā€ + ent OVN deployments. The content of the database is populated and used + by the ovn-ic program in each OVN deployment, and not supposed to be + directly used by CMS or end user. + + The OVN Interconnection Southbound database is shared by ovn-ic program + in each OVN deployment. It contains interconnection information from + all related OVN deployments, and is used as the intermediate store for + each OVN deployment to exchange the information. The ovn-ic program in + each deployment is responsible for syncing the data between this dataā€ + base and the its own northbound and southbound databases. + + Database Structure + The OVN Interconnection Southbound database contains classes of data + with different properties, as described in the sections below. + + Availability Zone Specific Information + + These tables contain objects that are availability zone specific. Each + object is owned and populated by one availability zone, and read by + other availability zones. + + The Availability_Zone, Gateway, Encap and Port_Binding tables are the + availability zone specific tables. + + Global Information + + The data that does not belong to any specific availability zone but is + common for all availability zones. + + The Datapath_Binding table contains the common datapath binding inforā€ + mation. + + Common Columns + + Each of the tables in this database contains a special column, named + external_ids. This column has the same form and purpose each place it + appears. + + external_ids: map of string-string pairs + Key-value pairs for use by ovn-ic. + +TABLE SUMMARY + The following list summarizes the purpose of each of the tables in the + OVN_IC_Southbound database. Each table is described in more detail on + a later page. + + Table Purpose + IC_SB_Global + IC Southbound configuration + Availability_Zone + Availability Zone Information + Gateway Interconnection Gateway Information + Encap Encapsulation Types + Datapath_Binding + Transit Switch Datapath Bindings + Port_Binding + Transit Port Bindings + Route Route + Connection + OVSDB client connections. + SSL SSL configuration. + +IC_SB_Global TABLE + Interconnection Southbound configuration. This table must have exactly + one row. + + Summary: + Common Columns: + external_ids map of string-string pairs + options map of string-string pairs + Connection Options: + connections set of Connections + ssl optional SSL + + Details: + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + + options: map of string-string pairs + + 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ā€ā€ + tion table for more information. + + ssl: optional SSL + Global SSL configuration. + +Availability_Zone TABLE + Each row in this table represents an Availability Zone. Each OVN deā€ + ployment is considered an availability zone from OVN control plane perā€ + spective, with its own central components, such as northbound and + southbound databases and ovn-northd daemon. + + Summary: + name string (must be unique within table) + + Details: + name: string (must be unique within table) + A name that uniquely identifies the availability zone. + +Gateway TABLE + Each row in this table represents a interconnection gateway chassis in + an availability zone. + + Summary: + name string (must be unique within table) + availability_zone Availability_Zone + hostname string + Common Columns: + external_ids map of string-string pairs + Encapsulation Configuration: + encaps set of 1 or more Encaps + + Details: + name: string (must be unique within table) + The name of the gateway. See name column of the OVN Southbound + databaseā€™s Chassis table. + + availability_zone: Availability_Zone + The availability zone that the gateway belongs to. + + hostname: string + The hostname of the gateway. + + Common Columns: + + The overall purpose of these columns is described under Common Columns + at the beginning of this document. + + external_ids: map of string-string pairs + + Encapsulation Configuration: + + OVN uses encapsulation to transmit logical dataplane packets between + gateways. + + encaps: set of 1 or more Encaps + Points to supported encapsulation configurations to transmit + logical dataplane packets to this gateway. Each entry is a Encap + record that describes the configuration. See encaps column of + the OVN Southbound databaseā€™s Chassis table. + +Encap TABLE + The encaps column in the Gateway table refers to rows in this table to + identify how OVN may transmit logical dataplane packets to this gateā€ + way. + + Summary: + type string, one of geneve, stt, or vxlan + options map of string-string pairs + ip string + gateway_name string + + Details: + type: string, one of geneve, stt, or vxlan + The encapsulation to use to transmit packets to this gateway. + See type column of the OVN Southbound databaseā€™s Encap table. + + options: map of string-string pairs + Options for configuring the encapsulation, which may be type + specific. See options column of the OVN Southbound databaseā€™s + Encap table. + + ip: string + The IPv4 address of the encapsulation tunnel endpoint. + + gateway_name: string + The name of the gateway that created this encap. + +Datapath_Binding TABLE + Each row in this table represents a logical datapath for a transit logā€ + ical switch configured in the OVN Interconnection Northbound databaseā€™s + Transit_Switch table. + + Summary: + transit_switch string + tunnel_key integer, in range 1 to 16,777,215 (must + be unique within table) + Common Columns: + external_ids map of string-string pairs + + Details: + transit_switch: string + The name of the transit logical switch that is configured in the + OVN Interconnection Northbound databaseā€™s Transit_Switch table. + + 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 + key can be generated by any ovn-ic but the same key is shared by + all availability zones so that the logical datapaths can be + peered across them. A tunnel key for transit switch datapath + binding must be globally unique. + + For more information about the meanings of a tunnel key, see + tunnel_key column of the OVN Southbound databaseā€™s Dataā€ā€ + path_Binding table. + + Common Columns: + + The overall purpose of these columns is described under Common Columns + at the beginning of this document. + + external_ids: map of string-string pairs +Port_Binding TABLE + Each row in this table binds a logical port on the transit switch to a + physical gateway and a tunnel key. Each port on the transit switch beā€ + longs to a specific availability zone. + + Summary: + Core Features: + transit_switch string + logical_port string (must be unique within table) + availability_zone Availability_Zone + encap optional weak reference to Encap + gateway string + tunnel_key integer, in range 1 to 32,767 + address string + Common Columns: + external_ids map of string-string pairs + + Details: + Core Features: + + transit_switch: string + The name of the transit switch that the corresponding logical + port belongs to. + + logical_port: string (must be unique within table) + A logical port, taken from name in the OVN_Northbound databaseā€™s + Logical_Switch_Port table. The logical port name must be unique + across all availability zones. + + availability_zone: Availability_Zone + The availability zone that the port belongs to. + + encap: optional weak reference to Encap + Points to supported encapsulation configurations to transmit + logical dataplane packets to this gateway. Each entry is a Encap + record that describes the configuration. + + gateway: string + The name of the gateway that this port is physically located. + + tunnel_key: integer, in range 1 to 32,767 + A number that represents the logical port in the key (e.g. STT + key or Geneve TLV) field carried within tunnel protocol packets. + The key can be generated by any ovn-ic but the same key is + shared by all availability zones so that the packets can go + through the datapath pipelines of different availability zones. + + The tunnel ID must be unique within the scope of a logical dataā€ + path. + + For more information about tunnel key, see tunnel_key column of + the OVN Southbound databaseā€™s Port_Binding table. + + address: string + The Ethernet address and IP addresses used by the corresponding + logical router port peering with the transit switch port. It is + a string combined with the value of mac column followed by the + values in networks column in Logical_Router_Port table. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +Route TABLE + Each row in this table represents a route advertised. + + Summary: + Core Features: + transit_switch string + availability_zone Availability_Zone + route_table string + ip_prefix string + nexthop string + origin string, either connected or static + Common Columns: + external_ids map of string-string pairs + + Details: + Core Features: + + transit_switch: string + The name of the transit switch, upon which the route is adverā€ + tised. + + availability_zone: Availability_Zone + The availability zone that has advertised the route. + + route_table: string + Route table within which this route was created. Empty value + means
routing table. + + Routes for directly-connected networks will be learned to
+ 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ā€ā€ + ble value respectively. + + ip_prefix: string + IP prefix of this route (e.g. 192.168.100.0/24). + + nexthop: string + Nexthop IP address for this route. + + 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ā€ā€ + 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. + + 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 + (OVSDB) client. + + 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ā€ + tions. + + Summary: + Core Features: + target string (must be unique within table) + Client Failure Detection and Handling: + max_backoff optional integer, at least 1,000 + inactivity_probe optional integer + Status: + is_connected boolean + status : last_error optional string + status : state optional string, one of ACTIVE, BACKOFF, + CONNECTING, IDLE, or VOID + status : sec_since_connect optional string, containing an integer, + at least 0 + status : sec_since_disconnect + optional string, containing an integer, + at least 0 + status : locks_held optional string + status : locks_waiting optional string + status : locks_lost optional string + status : n_connections optional string, containing an integer, + at least 2 + status : bound_port optional string, containing an integer + Common Columns: + external_ids map of string-string pairs + other_config map of string-string pairs + + Details: + Core Features: + + target: string (must be unique within table) + Connection methods for clients. + + The following connection methods are currently supported: + + ssl:host[:port] + The specified SSL port on the 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 + built as part of Open vSwitch. + + tcp:host[:port] + 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 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. + + 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ā€ + 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 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 + 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 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 + inactivity probes. + + Status: + + Key-value pair of is_connected is always updated. Other key-value pairs + in the status columns may be updated depends on the target type. + + When target specifies a connection method that listens for inbound conā€ + 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ā€ + ted. + + is_connected: boolean + true if currently connected to this client, false otherwise. + + status : last_error: optional string + A human-readable description of the last error on the connection + to the manager; i.e. strerror(errno). This key will exist only + if an error has occurred. + + status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING, + IDLE, or VOID + The state of the connection to the manager: + + VOID Connection is disabled. + + BACKOFF + Attempting to reconnect at an increasing period. + + CONNECTING + Attempting to connect. + + ACTIVE Connected, remote host responsive. + + IDLE Connection is idle. Waiting for response to keep-alive. + + These values may change in the future. They are provided only + for human consumption. + + status : sec_since_connect: optional string, containing an integer, at + least 0 + The amount of time since this client last successfully connected + to the database (in seconds). Value is empty if client has never + successfully been connected. + + status : sec_since_disconnect: optional string, containing an integer, + at least 0 + The amount of time since this client last disconnected from the + database (in seconds). Value is empty if client has never 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 + 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ā€ + 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 + locks have been stolen from this connection. + + status : n_connections: optional string, containing an integer, at + least 2 + When target specifies a connection method that listens for 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 + available port.) + + Common Columns: + + The overall purpose of these columns is described under Common Columns + at the beginning of this document. + + external_ids: map of string-string pairs + + other_config: map of string-string pairs +SSL TABLE + SSL configuration for ovn-sb database access. + + Summary: + private_key string + certificate string + ca_cert string + bootstrap_ca_cert boolean + ssl_protocols string + ssl_ciphers string + Common Columns: + external_ids map of string-string pairs + + Details: + private_key: string + Name of a PEM file containing the private key used as the + switchā€™s identity for SSL connections to the controller. + + certificate: string + Name of a PEM file containing a certificate, signed by the cerā€ + tificate authority (CA) used by the controller and manager, that + certifies the switchā€™s private key, identifying a trustworthy + switch. + + ca_cert: string + Name of a PEM file containing the CA certificate used to verify + that the switch is connected to a trustworthy controller. + + bootstrap_ca_cert: boolean + If set to true, then Open vSwitch will attempt to obtain the CA + certificate from the controller on its first SSL connection and + save it to the named PEM file. If it is successful, it will 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 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 + omitted is HIGH:!aNULL:!MD5. + + Common Columns: + + The overall purpose of these columns is described under Common Columns + at the beginning of this document. + + external_ids: map of string-string pairs + +Open vSwitch 23.06.3 DB Schema 1.1.1 ovn-ic-sb(5) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic-sbctl.8 b/src/static/support/dist-docs-branch-23.06/ovn-ic-sbctl.8 new file mode 100644 index 00000000..99ceab89 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ic-sbctl.8 @@ -0,0 +1,412 @@ +'\" p +.\" -*- nroff -*- +.TH "ovn-ic-sbctl" 8 "ovn-ic-sbctl" "OVN 23\[char46]06\[char46]3" "OVN Manual" +.fp 5 L CR \\" Make fixed-width font available as \\fL. +.de TQ +. br +. ns +. TP "\\$1" +.. +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +.de SU +. PP +. I "\\$1" +.. +.PP +.SH "NAME" +.PP +.PP +ovn-ic-sbctl \- Open Virtual Network interconnection southbound db management utility +.SH "SYNOPSIS" +.PP +\fBovn\-ic\-sbctl\fR [\fIoptions\fR] \fIcommand\fR [\fIarg\fR\[char46]\[char46]\[char46]] +.SH "DESCRIPTION" +.PP +.PP +This utility can be used to manage the OVN interconnection southbound database\[char46] +.SH "GENERAL COMMANDS" +.TP +\fBinit\fR +Initializes the database, if it is empty\[char46] If the database has already been initialized, this command has no effect\[char46] +.TP +\fBshow [\fIavailability_zone\fB]\fR +Prints a brief overview of the database contents\[char46] If \fIavailability_zone\fR is provided, only records related to that availability zone are shown\[char46] +.SH "DATABASE COMMANDS" +.PP +.PP +These commands query and modify the contents of \fBovsdb\fR tables\[char46] They are a slight abstraction of the \fBovsdb\fR interface and as such they operate at a lower level than other \fBovn\-ic\-sbctl\fR commands\[char46] +.PP +\fIIdentifying Tables, Records, and Columns\fR +.PP +.PP +Each of these commands has a \fItable\fR parameter to identify a table within the database\[char46] Many of them also take a \fIrecord\fR parameter that identifies a particular record within a table\[char46] The \fIrecord\fR 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\[char46] Many tables offer additional ways to identify records\[char46] Some commands also take \fIcolumn\fR parameters that identify a particular field within the records in a table\[char46] +.PP +.PP +For a list of tables and their columns, see \fBovn\-ic\-sb\fR(5) or see the table listing from the \fB\-\-help\fR option\[char46] +.PP +.PP +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\[char46] Names of tables and columns are not case-sensitive, and \fB\-\fR and \fB_\fR are treated interchangeably\[char46] Unique abbreviations of table and column names are acceptable, e\[char46]g\[char46] \fBg\fR or \fBgatew\fR is sufficient to identify the \fBGateway\fR table\[char46] +.PP +.PP +.PP +\fIDatabase Values\fR +.PP +.PP +Each column in the database accepts a fixed type of data\[char46] The currently defined basic types, and their representations, are: +.RS +.TP +integer +A decimal integer in the range \-2**63 to 2**63\-1, inclusive\[char46] +.TP +real +A floating-point number\[char46] +.TP +Boolean +True or false, written \fBtrue\fR or \fBfalse\fR, respectively\[char46] +.TP +string +An arbitrary Unicode string, except that null bytes are not allowed\[char46] Quotes are optional for most strings that begin with an English letter or underscore and consist only of letters, underscores, hyphens, and periods\[char46] However, \fBtrue\fR and \fBfalse\fR and strings that match the syntax of UUIDs (see below) must be enclosed in double quotes to distinguish them from other basic types\[char46] When double quotes are used, the syntax is that of strings in JSON, e\[char46]g\[char46] backslashes may be used to escape special characters\[char46] The empty string must be represented as a pair of double quotes (\fB\(dq\(dq\fR)\[char46] +.TP +UUID +Either a universally unique identifier in the style of RFC 4122, e\[char46]g\[char46] \fBf81d4fae\-7dec\-11d0\-a765\-00a0c91e6bf6\fR, or an \fB@\fR\fIname\fR defined by a \fBget\fR or \fBcreate\fR command within the same \fBovs\-vsctl\fR invocation\[char46] +.RE +.PP +.PP +Multiple values in a single column may be separated by spaces or a single comma\[char46] When multiple values are present, duplicates are not allowed, and order is not important\[char46] Conversely, some database columns can have an empty set of values, represented as \fB[]\fR, and square brackets may optionally enclose other non-empty sets or single values as well\[char46] +.PP +.PP +A few database columns are ``maps\(cq\(cq of key-value pairs, where the key and the value are each some fixed database type\[char46] These are specified in the form \fIkey\fR\fB=\fR\fIvalue\fR, where \fIkey\fR and \fIvalue\fR follow the syntax for the column\(cqs key type and value type, respectively\[char46] When multiple pairs are present (separated by spaces or a comma), duplicate keys are not allowed, and again the order is not important\[char46] Duplicate values are allowed\[char46] An empty map is represented as \fB{}\fR\[char46] Curly braces may optionally enclose non-empty maps as well (but use quotes to prevent the shell from expanding \fBother\-config={0=x,1=y}\fR into \fBother\-config=0=x +other\-config=1=y\fR, which may not have the desired effect)\[char46] +.PP +\fIDatabase Command Syntax\fR +.RS +.TP +[\fB\-\-if\-exists\fR] [\fB\-\-columns=\fR\fIcolumn\fR[\fB,\fR\fIcolumn\fR]\[char46]\[char46]\[char46]] \fBlist\fR \fItable\fR [\fIrecord\fR]\[char46]\[char46]\[char46] +Lists the data in each specified \fIrecord\fR\[char46] If no records are specified, lists all the records in \fItable\fR\[char46] +.IP +If \fB\-\-columns\fR is specified, only the requested columns are listed, in the specified order\[char46] Otherwise, all columns are listed, in alphabetical order by column name\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if any specified \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, the command ignores any \fIrecord\fR that does not exist, without producing any output\[char46] +.TP +[\fB\-\-columns=\fR\fIcolumn\fR[\fB,\fR\fIcolumn\fR]\[char46]\[char46]\[char46]] \fBfind\fR \fItable\fR [\fIcolumn\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR]\[char46]\[char46]\[char46] +Lists the data in each record in \fItable\fR whose \fIcolumn\fR equals \fIvalue\fR or, if \fIkey\fR is specified, whose \fIcolumn\fR contains a \fIkey\fR with the specified \fIvalue\fR\[char46] The following operators may be used where \fB=\fR is written in the syntax summary: +.RS +.TP +\fB= != < > <= >=\fR +Selects records in which \fIcolumn\fR[\fB:\fR\fIkey\fR] equals, does not equal, is less than, is greater than, is less than or equal to, or is greater than or equal to \fIvalue\fR, respectively\[char46] +.IP +Consider \fIcolumn\fR[\fB:\fR\fIkey\fR] and \fIvalue\fR as sets of elements\[char46] Identical sets are considered equal\[char46] Otherwise, if the sets have different numbers of elements, then the set with more elements is considered to be larger\[char46] Otherwise, consider a element from each set pairwise, in increasing order within each set\[char46] The first pair that differs determines the result\[char46] (For a column that contains key-value pairs, first all the keys are compared, and values are considered only if the two sets contain identical keys\[char46]) +.TP +\fB{=} {!=}\fR +Test for set equality or inequality, respectively\[char46] +.TP +\fB{<=}\fR +Selects records in which \fIcolumn\fR[\fB:\fR\fIkey\fR] is a subset of \fIvalue\fR\[char46] For example, \fBflood\-vlans{<=}1,2\fR selects records in which the \fBflood\-vlans\fR column is the empty set or contains 1 or 2 or both\[char46] +.TP +\fB{<}\fR +Selects records in which \fIcolumn\fR[\fB:\fR\fIkey\fR] is a proper subset of \fIvalue\fR\[char46] For example, \fBflood\-vlans{<}1,2\fR selects records in which the \fBflood\-vlans\fR column is the empty set or contains 1 or 2 but not both\[char46] +.TP +\fB{>=} {>}\fR +Same as \fB{<=}\fR and \fB{<}\fR, respectively, except that the relationship is reversed\[char46] For example, \fBflood\-vlans{>=}1,2\fR selects records in which the \fBflood\-vlans\fR column contains both 1 and 2\[char46] +.RE +.IP +The following operators are available only in Open vSwitch 2\[char46]16 and later: +.RS +.TP +\fB{in}\fR +Selects records in which every element in \fIcolumn\fR[\fB:\fR\fIkey\fR] is also in \fIvalue\fR\[char46] (This is the same as \fB{<=}\fR\[char46]) +.TP +\fB{not\-in}\fR +Selects records in which every element in \fIcolumn\fR[\fB:\fR\fIkey\fR] is not in \fIvalue\fR\[char46] +.RE +.IP +For arithmetic operators (\fB= != < > <= >=\fR), when \fIkey\fR is specified but a particular record\(cqs \fIcolumn\fR does not contain \fIkey\fR, the record is always omitted from the results\[char46] Thus, the condition \fBother\-config:mtu!=1500\fR matches records that have a \fBmtu\fR key whose value is not 1500, but not those that lack an \fBmtu\fR key\[char46] +.IP +For the set operators, when \fIkey\fR is specified but a particular record\(cqs \fIcolumn\fR does not contain \fIkey\fR, the comparison is done against an empty set\[char46] Thus, the condition \fBother\-config:mtu{!=}1500\fR matches records that have a \fBmtu\fR key whose value is not 1500 and those that lack an \fBmtu\fR key\[char46] +.IP +Don\(cqt forget to escape \fB<\fR or \fB>\fR from interpretation by the shell\[char46] +.IP +If \fB\-\-columns\fR is specified, only the requested columns are listed, in the specified order\[char46] Otherwise all columns are listed, in alphabetical order by column name\[char46] +.IP +The UUIDs shown for rows created in the same \fBovs\-vsctl\fR invocation will be wrong\[char46] +.TP +[\fB\-\-if\-exists\fR] [\fB\-\-id=@\fR\fIname\fR] \fBget\fR \fItable record\fR [\fIcolumn\fR[\fB:\fR\fIkey\fR]]\[char46]\[char46]\[char46] +Prints the value of each specified \fIcolumn\fR in the given \fIrecord\fR in \fItable\fR\[char46] For map columns, a \fIkey\fR may optionally be specified, in which case the value associated with \fIkey\fR in the column is printed, instead of the entire map\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist or \fIkey\fR is specified, if \fIkey\fR does not exist in \fIrecord\fR\[char46] With \fB\-\-if\-exists\fR, a missing \fIrecord\fR yields no output and a missing \fIkey\fR prints a blank line\[char46] +.IP +If \fB@\fR\fIname\fR is specified, then the UUID for \fIrecord\fR may be referred to by that name later in the same \fBovs\-vsctl\fR invocation in contexts where a UUID is expected\[char46] +.IP +Both \fB\-\-id\fR and the \fIcolumn\fR arguments are optional, but usually at least one or the other should be specified\[char46] If both are omitted, then \fBget\fR has no effect except to verify that \fIrecord\fR exists in \fItable\fR\[char46] +.IP +\fB\-\-id\fR and \fB\-\-if\-exists\fR cannot be used together\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBset\fR \fItable record column\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR\[char46]\[char46]\[char46] +Sets the value of each specified \fIcolumn\fR in the given \fIrecord\fR in \fItable\fR to \fIvalue\fR\[char46] For map columns, a \fIkey\fR may optionally be specified, in which case the value associated with \fIkey\fR in that column is changed (or added, if none exists), instead of the entire map\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, this command does nothing if \fIrecord\fR does not exist\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBadd\fR \fItable record column\fR [\fIkey\fR\fB=\fR]\fIvalue\fR\[char46]\[char46]\[char46] +Adds the specified value or key-value pair to \fIcolumn\fR in \fIrecord\fR in \fItable\fR\[char46] If \fIcolumn\fR is a map, then \fIkey\fR is required, otherwise it is prohibited\[char46] If \fIkey\fR already exists in a map column, then the current \fIvalue\fR is not replaced (use the \fBset\fR command to replace an existing value)\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, this command does nothing if \fIrecord\fR does not exist\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBremove\fR \fItable record column value\fR\[char46]\[char46]\[char46] +.IP +[\fB\-\-if\-exists\fR] \fBremove\fR \fItable record column key\fR\[char46]\[char46]\[char46] +.IP +[\fB\-\-if\-exists\fR] \fBremove\fR \fItable record column key\fR\fB=\fR\fIvalue\fR\[char46]\[char46]\[char46] +Removes the specified values or key-value pairs from \fIcolumn\fR in \fIrecord\fR in \fItable\fR\[char46] The first form applies to columns that are not maps: each specified \fIvalue\fR is removed from the column\[char46] The second and third forms apply to map columns: if only a \fIkey\fR is specified, then any key-value pair with the given \fIkey\fR is removed, regardless of its value; if a \fIvalue\fR is given then a pair is removed only if both key and value match\[char46] +.IP +It is not an error if the column does not contain the specified key or value or pair\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, this command does nothing if \fIrecord\fR does not exist\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBclear\fR \fItable record column\fR\[char46]\[char46]\[char46] +Sets each \fIcolumn\fR in \fIrecord\fR in \fItable\fR to the empty set or empty map, as appropriate\[char46] This command applies only to columns that are allowed to be empty\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, this command does nothing if \fIrecord\fR does not exist\[char46] +.TP +[\fB\-\-id=(@\fR\fIname\fR|\fIuuid\fR)] \fBcreate\fR \fItable column\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR\[char46]\[char46]\[char46] +Creates a new record in \fItable\fR and sets the initial values of each \fIcolumn\fR\[char46] Columns not explicitly set will receive their default values\[char46] Outputs the UUID of the new row\[char46] +.IP +If \fB@\fR\fIname\fR is specified, then the UUID for the new row may be referred to by that name elsewhere in the same \fB\e*(PN\fR invocation in contexts where a UUID is expected\[char46] Such references may precede or follow the \fBcreate\fR command\[char46] +.IP +If a valid \fIuuid\fR is specified, then it is used as the UUID of the new row\[char46] +.RS +.TP +Caution (ovs-vsctl as example) +Records in the Open vSwitch database are significant only when they can be reached directly or indirectly from the \fBOpen_vSwitch\fR table\[char46] Except for records in the \fBQoS\fR or \fBQueue\fR tables, records that are not reachable from the \fBOpen_vSwitch\fR table are automatically deleted from the database\[char46] This deletion happens immediately, without waiting for additional \fBovs\-vsctl\fR commands or other database activity\[char46] Thus, a \fBcreate\fR command must generally be accompanied by additional commands \fIwithin the same\fR \fBovs\-vsctl\fR \fIinvocation\fR to add a chain of references to the newly created record from the top-level \fBOpen_vSwitch\fR record\[char46] The \fBEXAMPLES\fR section gives some examples that show how to do this\[char46] +.RE +.TP +[\fB\-\-if\-exists\fR] \fBdestroy\fR \fItable record\fR\[char46]\[char46]\[char46] +Deletes each specified \fIrecord\fR from \fItable\fR\[char46] Unless \fB\-\-if\-exists\fR is specified, each \fIrecord\fRs must exist\[char46] +.TP +\fB\-\-all destroy\fR \fItable\fR +Deletes all records from the \fItable\fR\[char46] +.RS +.TP +Caution (ovs-vsctl as example) +The \fBdestroy\fR command is only useful for records in the \fBQoS\fR or \fBQueue\fR tables\[char46] Records in other tables are automatically deleted from the database when they become unreachable from the \fBOpen_vSwitch\fR table\[char46] This means that deleting the last reference to a record is sufficient for deleting the record itself\[char46] For records in these tables, \fBdestroy\fR is silently ignored\[char46] See the \fBEXAMPLES\fR section below for more information\[char46] +.RE +.TP +\fBwait\-until\fR \fItable record\fR [\fIcolumn\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR]\[char46]\[char46]\[char46] +Waits until \fItable\fR contains a record named \fIrecord\fR whose \fIcolumn\fR equals \fIvalue\fR or, if \fIkey\fR is specified, whose \fIcolumn\fR contains a \fIkey\fR with the specified \fIvalue\fR\[char46] This command supports the same operators and semantics described for the \fBfind\fR command above\[char46] +.IP +If no \fIcolumn\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR arguments are given, this command waits only until \fIrecord\fR exists\[char46] If more than one such argument is given, the command waits until all of them are satisfied\[char46] +.RS +.TP +Caution (ovs-vsctl as example) +Usually \fBwait\-until\fR should be placed at the beginning of a set of \fBovs\-vsctl\fR commands\[char46] For example, \fBwait\-until bridge br0 +\-\- get bridge br0 datapath_id\fR waits until a bridge named \fBbr0\fR is created, then prints its \fBdatapath_id\fR column, whereas \fBget bridge br0 datapath_id \-\- wait\-until bridge br0\fR will abort if no bridge named \fBbr0\fR exists when \fBovs\-vsctl\fR initially connects to the database\[char46] +.RE +.IP +Consider specifying \fB\-\-timeout=0\fR along with \fB\-\-wait\-until\fR, to prevent \fBovs\-vsctl\fR from terminating after waiting only at most 5 seconds\[char46] +.TP +\fBcomment\fR [\fIarg\fR]\[char46]\[char46]\[char46] +This command has no effect on behavior, but any database log record created by the command will include the command and its arguments\[char46] +.RE +.SH "REMOTE CONNECTIVITY COMMANDS" +.TP +\fBget\-connection\fR +Prints the configured connection(s)\[char46] +.TP +\fBdel\-connection\fR +Deletes the configured connection(s)\[char46] +.TP +[\fB\-\-inactivity\-probe=\fR\fImsecs\fR] \fBset\-connection\fR \fItarget\fR\[char46]\[char46]\[char46] +Sets the configured manager target or targets\[char46] Use \fB\-\-inactivity\-probe=\fR\fImsecs\fR to override the default idle connection inactivity probe time\[char46] Use 0 to disable inactivity probes\[char46] +.SH "SSL CONFIGURATION COMMANDS" +.TP +\fBget\-ssl\fR +Prints the SSL configuration\[char46] +.TP +\fBdel\-ssl\fR +Deletes the current SSL configuration\[char46] +.TP +[\fB\-\-bootstrap\fR] \fBset\-ssl\fR \fIprivate-key\fR \fIcertificate\fR \fIca-cert\fR [\fIssl-protocol-list\fR [\fIssl-cipher-list\fR]] +Sets the SSL configuration\[char46] +.SH "OPTIONS" +.TP +\fB\-\-db\fR \fIdatabase\fR +The OVSDB database remote to contact\[char46] If the \fBOVN_IC_SB_DB\fR environment variable is set, its value is used as the default\[char46] Otherwise, the default is \fBunix:/ovn_ic_sb_db\[char46]sock\fR, but this default is unlikely to be useful outside of single-machine OVN test environments\[char46] +.TP +\fB\-\-leader\-only\fR +.TQ .5in +\fB\-\-no\-leader\-only\fR +By default, or with \fB\-\-leader\-only\fR, when the database server is a clustered database, \fBovn\-ic\-sbctl\fR will avoid servers other than the cluster leader\[char46] This ensures that any data that \fBovn\-ic\-sbctl\fR reads and reports is up-to-date\[char46] With \fB\-\-no\-leader\-only\fR, \fBovn\-ic\-sbctl\fR 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 \fB\-\-no\-leader\-only\fR)\[char46] Refer to \fBUnderstanding Cluster Consistency\fR in \fBovsdb\fR(7) for more information\[char46] +.SH "LOGGING OPTIONS" +.TP +\fB\-v\fR[\fIspec\fR] +.TQ .5in +\fB\-\-verbose=\fR[\fIspec\fR] +Sets logging levels\[char46] Without any \fIspec\fR, sets the log level for every module and destination to \fBdbg\fR\[char46] Otherwise, \fIspec\fR is a list of words separated by spaces or commas or colons, up to one from each category below: +.RS +.IP \(bu +A valid module name, as displayed by the \fBvlog/list\fR command on \fBovs\-appctl\fR(8), limits the log level change to the specified module\[char46] +.IP \(bu +\fBsyslog\fR, \fBconsole\fR, or \fBfile\fR, to limit the log level change to only to the system log, to the console, or to a file, respectively\[char46] (If \fB\-\-detach\fR is specified, the daemon closes its standard file descriptors, so logging to the console will have no effect\[char46]) +.IP +On Windows platform, \fBsyslog\fR is accepted as a word and is only useful along with the \fB\-\-syslog\-target\fR option (the word has no effect otherwise)\[char46] +.IP \(bu +\fBoff\fR, \fBemer\fR, \fBerr\fR, \fBwarn\fR, \fBinfo\fR, or \fBdbg\fR, to control the log level\[char46] Messages of the given severity or higher will be logged, and messages of lower severity will be filtered out\[char46] \fBoff\fR filters out all messages\[char46] See \fBovs\-appctl\fR(8) for a definition of each log level\[char46] +.RE +.IP +Case is not significant within \fIspec\fR\[char46] +.IP +Regardless of the log levels set for \fBfile\fR, logging to a file will not take place unless \fB\-\-log\-file\fR is also specified (see below)\[char46] +.IP +For compatibility with older versions of OVS, \fBany\fR is accepted as a word but has no effect\[char46] +.TP +\fB\-v\fR +.TQ .5in +\fB\-\-verbose\fR +Sets the maximum logging verbosity level, equivalent to \fB\-\-verbose=dbg\fR\[char46] +.TP +\fB\-vPATTERN:\fR\fIdestination\fR\fB:\fR\fIpattern\fR +.TQ .5in +\fB\-\-verbose=PATTERN:\fR\fIdestination\fR\fB:\fR\fIpattern\fR +Sets the log pattern for \fIdestination\fR to \fIpattern\fR\[char46] Refer to \fBovs\-appctl\fR(8) for a description of the valid syntax for \fIpattern\fR\[char46] +.TP +\fB\-vFACILITY:\fR\fIfacility\fR +.TQ .5in +\fB\-\-verbose=FACILITY:\fR\fIfacility\fR +Sets the RFC5424 facility of the log message\[char46] \fIfacility\fR can be one of \fBkern\fR, \fBuser\fR, \fBmail\fR, \fBdaemon\fR, \fBauth\fR, \fBsyslog\fR, \fBlpr\fR, \fBnews\fR, \fBuucp\fR, \fBclock\fR, \fBftp\fR, \fBntp\fR, \fBaudit\fR, \fBalert\fR, \fBclock2\fR, \fBlocal0\fR, \fBlocal1\fR, \fBlocal2\fR, \fBlocal3\fR, \fBlocal4\fR, \fBlocal5\fR, \fBlocal6\fR or \fBlocal7\fR\[char46] If this option is not specified, \fBdaemon\fR is used as the default for the local system syslog and \fBlocal0\fR is used while sending a message to the target provided via the \fB\-\-syslog\-target\fR option\[char46] +.TP +\fB\-\-log\-file\fR[\fB=\fR\fIfile\fR] +Enables logging to a file\[char46] If \fIfile\fR is specified, then it is used as the exact name for the log file\[char46] The default log file name used if \fIfile\fR is omitted is \fB/usr/local/var/log/ovn/\fIprogram\fB\[char46]log\fR\[char46] +.TP +\fB\-\-syslog\-target=\fR\fIhost\fR\fB:\fR\fIport\fR +Send syslog messages to UDP \fIport\fR on \fIhost\fR, in addition to the system syslog\[char46] The \fIhost\fR must be a numerical IP address, not a hostname\[char46] +.TP +\fB\-\-syslog\-method=\fR\fImethod\fR +Specify \fImethod\fR as how syslog messages should be sent to syslog daemon\[char46] The following forms are supported: +.RS +.IP \(bu +\fBlibc\fR, to use the libc \fBsyslog()\fR function\[char46] Downside of using this options is that libc adds fixed prefix to every message before it is actually sent to the syslog daemon over \fB/dev/log\fR UNIX domain socket\[char46] +.IP \(bu +\fBunix:\fIfile\fB\fR, to use a UNIX domain socket directly\[char46] It is possible to specify arbitrary message format with this option\[char46] However, \fBrsyslogd 8\[char46]9\fR and older versions use hard coded parser function anyway that limits UNIX domain socket use\[char46] If you want to use arbitrary message format with older \fBrsyslogd\fR versions, then use UDP socket to localhost IP address instead\[char46] +.IP \(bu +\fBudp:\fIip\fB:\fIport\fB\fR, to use a UDP socket\[char46] With this method it is possible to use arbitrary message format also with older \fBrsyslogd\fR\[char46] When sending syslog messages over UDP socket extra precaution needs to be taken into account, for example, 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\[char46] +.IP \(bu +\fBnull\fR, to discard all messages logged to syslog\[char46] +.RE +.IP +The default is taken from the \fBOVS_SYSLOG_METHOD\fR environment variable; if it is unset, the default is \fBlibc\fR\[char46] +.SH "TABLE FORMATTING OPTIONS" +These options control the format of output from the \fBlist\fR and \fBfind\fR commands\[char46] +.RS +.TP +\fB\-f\fR \fIformat\fR +.TQ .5in +\fB\-\-format=\fR\fIformat\fR +Sets the type of table formatting\[char46] The following types of \fIformat\fR are available: +.RS +.TP +\fBtable\fR +2-D text tables with aligned columns\[char46] +.TP +\fBlist\fR (default) +A list with one column per line and rows separated by a blank line\[char46] +.TP +\fBhtml\fR +HTML tables\[char46] +.TP +\fBcsv\fR +Comma-separated values as defined in RFC 4180\[char46] +.TP +\fBjson\fR +JSON format as defined in RFC 4627\[char46] The output is a sequence of JSON objects, each of which corresponds to one table\[char46] Each JSON object has the following members with the noted values: +.RS +.TP +\fBcaption\fR +The table\(cqs caption\[char46] This member is omitted if the table has no caption\[char46] +.TP +\fBheadings\fR +An array with one element per table column\[char46] Each array element is a string giving the corresponding column\(cqs heading\[char46] +.TP +\fBdata\fR +An array with one element per table row\[char46] Each element is also an array with one element per table column\[char46] The elements of this second-level array are the cells that constitute the table\[char46] Cells that represent OVSDB data or data types are expressed in the format described in the OVSDB specification; other cells are simply expressed as text strings\[char46] +.RE +.RE +.TP +\fB\-d\fR \fIformat\fR +.TQ .5in +\fB\-\-data=\fR\fIformat\fR +Sets the formatting for cells within output tables unless the table format is set to \fBjson\fR, in which case \fBjson\fR formatting is always used when formatting cells\[char46] The following types of \fIformat\fR are available: +.RS +.TP +\fBstring\fR (default) +The simple format described in the \fBDatabase Values\fR section of \fBovs\-vsctl\fR(8)\[char46] +.TP +\fBbare\fR +The simple format with punctuation stripped off: \fB[]\fR and \fB{}\fR are omitted around sets, maps, and empty columns, items within sets and maps are space-separated, and strings are never quoted\[char46] This format may be easier for scripts to parse\[char46] +.TP +\fBjson\fR +The RFC 4627 JSON format as described above\[char46] +.RE +.TP +\fB\-\-no\-headings\fR +This option suppresses the heading row that otherwise appears in the first row of table output\[char46] +.TP +\fB\-\-pretty\fR +By default, JSON in output is printed as compactly as possible\[char46] This option causes JSON in output to be printed in a more readable fashion\[char46] Members of objects and elements of arrays are printed one per line, with indentation\[char46] +.IP +This option does not affect JSON in tables, which is always printed compactly\[char46] +.TP +\fB\-\-bare\fR +Equivalent to \fB\-\-format=list \-\-data=bare \-\-no\-headings\fR\[char46] +.RE +.SS "PKI Options" +.PP +.PP +PKI configuration is required to use SSL for the connection to the database\[char46] +.RS +.TP +\fB\-p\fR \fIprivkey\[char46]pem\fR +.TQ .5in +\fB\-\-private\-key=\fR\fIprivkey\[char46]pem\fR +Specifies a PEM file containing the private key used as identity for outgoing SSL connections\[char46] +.TP +\fB\-c\fR \fIcert\[char46]pem\fR +.TQ .5in +\fB\-\-certificate=\fR\fIcert\[char46]pem\fR +Specifies a PEM file containing a certificate that certifies the private key specified on \fB\-p\fR or \fB\-\-private\-key\fR to be trustworthy\[char46] The certificate must be signed by the certificate authority (CA) that the peer in SSL connections will use to verify it\[char46] +.TP +\fB\-C\fR \fIcacert\[char46]pem\fR +.TQ .5in +\fB\-\-ca\-cert=\fR\fIcacert\[char46]pem\fR +Specifies a PEM file containing the CA certificate for verifying certificates presented to this program by SSL peers\[char46] (This may be the same certificate that SSL peers use to verify the certificate specified on \fB\-c\fR or \fB\-\-certificate\fR, or it may be a different one, depending on the PKI design in use\[char46]) +.TP +\fB\-C none\fR +.TQ .5in +\fB\-\-ca\-cert=none\fR +Disables verification of certificates presented by SSL peers\[char46] This introduces a security risk, because it means that certificates cannot be verified to be those of known trusted hosts\[char46] +.RE +.RS +.TP +\fB\-\-bootstrap\-ca\-cert=\fR\fIcacert\[char46]pem\fR +When \fIcacert\[char46]pem\fR exists, this option has the same effect as \fB\-C\fR or \fB\-\-ca\-cert\fR\[char46] If it does not exist, then the executable will attempt to obtain the CA certificate from the SSL peer on its first SSL connection and save it to the named PEM file\[char46] 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\[char46] +.IP +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\[char46] +.IP +This option is only useful if the SSL peer sends its CA certificate as part of the SSL certificate chain\[char46] The SSL protocol does not require the server to send the CA certificate\[char46] +.IP +This option is mutually exclusive with \fB\-C\fR and \fB\-\-ca\-cert\fR\[char46] +.RE +.SS "Other Options" +.TP +\fB\-h\fR +.TQ .5in +\fB\-\-help\fR +Prints a brief help message to the console\[char46] +.TP +\fB\-V\fR +.TQ .5in +\fB\-\-version\fR +Prints version information to the console\[char46] diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic-sbctl.8.html b/src/static/support/dist-docs-branch-23.06/ovn-ic-sbctl.8.html new file mode 100644 index 00000000..c40a9946 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ic-sbctl.8.html @@ -0,0 +1,627 @@ +
+ovn-ic-sbctl(8)                   OVN Manual                   ovn-ic-sbctl(8)
+
+NAME
+       ovn-ic-sbctl  - Open Virtual Network interconnection southbound db manā€
+       agement utility
+
+SYNOPSIS
+       ovn-ic-sbctl [options] command [arg...]
+
+DESCRIPTION
+       This utility can be used to manage the OVN  interconnection  southbound
+       database.
+
+GENERAL COMMANDS
+       init   Initializes  the  database,  if it is empty. If the database has
+              already been initialized, this command has no effect.
+
+       show [availability_zone]
+              Prints a brief overview of the database contents. If  availabilā€
+              ity_zone  is provided, only records related to that availability
+              zone are shown.
+
+DATABASE COMMANDS
+       These commands query and modify the contents of ovsdb tables. They  are
+       a slight abstraction of the ovsdb interface and as such they operate at
+       a lower level than other ovn-ic-sbctl commands.
+
+       Identifying Tables, Records, and Columns
+
+       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
+       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
+       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,
+       e.g. g or gatew is sufficient to identify the Gateway table.
+
+       Database Values
+
+       Each column in the database accepts a fixed type of data. The currently
+       defined basic types, and their representations, are:
+
+              integer
+                     A decimal integer in the range -2**63 to 2**63-1,  incluā€
+                     sive.
+
+              real   A floating-point number.
+
+              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ā€
+                     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
+                     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
+                     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 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  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
+              [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
+                     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  igā€
+                     nores  any  record that does not exist, without producing
+                     any output.
+
+              [--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ā€
+                     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
+                            value, respectively.
+
+                            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
+                            pairs, first all the keys are compared, and values
+                            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
+                            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 the flood-vlans column is
+                            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
+                            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
+                            {=}.)
+
+                     {not-in}
+                            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
+                     not those that lack an mtu key.
+
+                     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
+                     key.
+
+                     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
+                     invocation will be wrong.
+
+              [--if-exists] [--id=@name] get table record [column[:key]]...
+                     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
+                     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 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
+                     both are omitted, then get has no effect except to verify
+                     that record exists in table.
+
+                     --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  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
+                     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  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
+                     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ā€
+                     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
+                     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.
+
+                     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
+                     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
+                     record does not exist.
+
+              [--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
+                     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
+                     references may precede or follow the create command.
+
+                     If a valid uuid is specified, then it is used as the UUID
+                     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 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
+                            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
+                            some examples that show how to do this.
+
+              [--if-exists] destroy table record...
+                     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
+                            for more information.
+
+              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
+                     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
+                     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ā€ā€
+                            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
+                            ovs-vsctl initially connects to the database.
+
+                     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ā€
+                     mand and its arguments.
+
+REMOTE CONNECTIVITY COMMANDS
+       get-connection
+              Prints the configured connection(s).
+
+       del-connection
+              Deletes the configured connection(s).
+
+       [--inactivity-probe=msecs] set-connection target...
+              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.
+
+SSL CONFIGURATION COMMANDS
+       get-ssl
+              Prints the SSL configuration.
+
+       del-ssl
+              Deletes the current SSL configuration.
+
+       [--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ā€
+              erwise, the default is unix:/ovn_ic_sb_db.sock, but this default
+              is  unlikely to be useful outside of single-machine OVN test enā€
+              vironments.
+
+       --leader-only
+       --no-leader-only
+            By default, or with --leader-only, when the database server  is  a
+            clustered database, ovn-ic-sbctl will avoid servers other than the
+            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
+            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
+            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
+                   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, 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
+                   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
+                   definition of each log level.
+
+            Case is not significant within spec.
+
+            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
+            word but has no effect.
+
+       -v
+       --verbose
+            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-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,
+            local4, local5, local6 or local7. If this option is not specified,
+            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
+            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.
+
+       --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ā€
+            name.
+
+       --syslog-method=method
+            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
+                   /dev/log UNIX domain socket.
+
+            ā€¢      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  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ā€
+       mands.
+
+              -f format
+              --format=format
+                   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
+                          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
+                          members with the noted values:
+
+                          caption
+                                 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
+                                 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-
+                                 level array are the cells that constitute the
+                                 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
+                   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:
+
+                   string (default)
+                          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
+                          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 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
+                   arrays are printed one per line, with indentation.
+
+                   This option does not affect JSON in tables, which is always
+                   printed compactly.
+
+              --bare
+                   Equivalent to --format=list --data=bare --no-headings.
+
+   PKI Options
+       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
+                   identity for outgoing SSL connections.
+
+              -c cert.pem
+              --certificate=cert.pem
+                   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
+                   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
+                   verify the certificate specified on -c or --certificate, or
+                   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
+                   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ā€
+                     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.
+
+                     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
+                     certificate as part of the SSL certificate chain. The SSL
+                     protocol does not require the server to send the CA  cerā€
+                     tificate.
+
+                     This option is mutually exclusive with -C and --ca-cert.
+
+   Other Options
+       -h
+       --help
+            Prints a brief help message to the console.
+
+       -V
+       --version
+            Prints version information to the console.
+
+OVN 23.06.3                      ovn-ic-sbctl                  ovn-ic-sbctl(8)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic-sbctl.8.pdf b/src/static/support/dist-docs-branch-23.06/ovn-ic-sbctl.8.pdf new file mode 100644 index 00000000..7b727f34 Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-ic-sbctl.8.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic-sbctl.8.txt b/src/static/support/dist-docs-branch-23.06/ovn-ic-sbctl.8.txt new file mode 100644 index 00000000..4c19f1a9 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ic-sbctl.8.txt @@ -0,0 +1,625 @@ +ovn-ic-sbctl(8) OVN Manual ovn-ic-sbctl(8) + +NAME + ovn-ic-sbctl - Open Virtual Network interconnection southbound db manā€ + agement utility + +SYNOPSIS + ovn-ic-sbctl [options] command [arg...] + +DESCRIPTION + This utility can be used to manage the OVN interconnection southbound + database. + +GENERAL COMMANDS + init Initializes the database, if it is empty. If the database has + already been initialized, this command has no effect. + + show [availability_zone] + Prints a brief overview of the database contents. If availabilā€ + ity_zone is provided, only records related to that availability + zone are shown. + +DATABASE COMMANDS + These commands query and modify the contents of ovsdb tables. They are + a slight abstraction of the ovsdb interface and as such they operate at + a lower level than other ovn-ic-sbctl commands. + + Identifying Tables, Records, and Columns + + 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 + 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 + 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, + e.g. g or gatew is sufficient to identify the Gateway table. + + Database Values + + Each column in the database accepts a fixed type of data. The currently + defined basic types, and their representations, are: + + integer + A decimal integer in the range -2**63 to 2**63-1, incluā€ + sive. + + real A floating-point number. + + 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ā€ + 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 + 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 + 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 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 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 + [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 + 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 igā€ + nores any record that does not exist, without producing + any output. + + [--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ā€ + 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 + value, respectively. + + 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 + pairs, first all the keys are compared, and values + 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 + 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 the flood-vlans column is + 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 + 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 + {<=}.) + + {not-in} + 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 + not those that lack an mtu key. + + 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 + key. + + 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 + invocation will be wrong. + + [--if-exists] [--id=@name] get table record [column[:key]]... + 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 + 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 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 + both are omitted, then get has no effect except to verify + that record exists in table. + + --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 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 + 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 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 + 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ā€ + 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 + 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. + + 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 + 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 + record does not exist. + + [--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 + 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 + references may precede or follow the create command. + + If a valid uuid is specified, then it is used as the UUID + 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 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 + 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 + some examples that show how to do this. + + [--if-exists] destroy table record... + 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 + for more information. + + 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 + 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 + 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ā€ā€ + 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 + ovs-vsctl initially connects to the database. + + 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ā€ + mand and its arguments. + +REMOTE CONNECTIVITY COMMANDS + get-connection + Prints the configured connection(s). + + del-connection + Deletes the configured connection(s). + + [--inactivity-probe=msecs] set-connection target... + 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. + +SSL CONFIGURATION COMMANDS + get-ssl + Prints the SSL configuration. + + del-ssl + Deletes the current SSL configuration. + + [--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ā€ + erwise, the default is unix:/ovn_ic_sb_db.sock, but this default + is unlikely to be useful outside of single-machine OVN test enā€ + vironments. + + --leader-only + --no-leader-only + By default, or with --leader-only, when the database server is a + clustered database, ovn-ic-sbctl will avoid servers other than the + 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 + 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 + 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 + 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, 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 + 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 + definition of each log level. + + Case is not significant within spec. + + 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 + word but has no effect. + + -v + --verbose + 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-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, + local4, local5, local6 or local7. If this option is not specified, + 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 + 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. + + --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ā€ + name. + + --syslog-method=method + 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 + /dev/log UNIX domain socket. + + ā€¢ 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 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ā€ + mands. + + -f format + --format=format + 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 + 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 + members with the noted values: + + caption + 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 + 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- + level array are the cells that constitute the + 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 + 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: + + string (default) + 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 + 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 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 + arrays are printed one per line, with indentation. + + This option does not affect JSON in tables, which is always + printed compactly. + + --bare + Equivalent to --format=list --data=bare --no-headings. + + PKI Options + 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 + identity for outgoing SSL connections. + + -c cert.pem + --certificate=cert.pem + 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 + 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 + verify the certificate specified on -c or --certificate, or + 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 + 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ā€ + 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. + + 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 + certificate as part of the SSL certificate chain. The SSL + protocol does not require the server to send the CA cerā€ + tificate. + + This option is mutually exclusive with -C and --ca-cert. + + Other Options + -h + --help + Prints a brief help message to the console. + + -V + --version + Prints version information to the console. + +OVN 23.06.3 ovn-ic-sbctl ovn-ic-sbctl(8) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic.8 b/src/static/support/dist-docs-branch-23.06/ovn-ic.8 new file mode 100644 index 00000000..c6725872 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ic.8 @@ -0,0 +1,211 @@ +'\" p +.\" -*- nroff -*- +.TH "ovn-ic" 8 "ovn-ic" "OVN 23\[char46]06\[char46]3" "OVN Manual" +.fp 5 L CR \\" Make fixed-width font available as \\fL. +.de TQ +. br +. ns +. TP "\\$1" +.. +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +.de SU +. PP +. I "\\$1" +.. +.PP +.SH "NAME" +.PP +.PP +ovn-ic \- Open Virtual Network interconnection controller +.SH "SYNOPSIS" +.PP +\fBovn\-ic\fR [\fIoptions\fR] +.SH "DESCRIPTION" +.PP +.PP +\fBovn\-ic\fR, OVN interconnection controller, is a centralized daemon which communicates with global interconnection databases IC_NB/IC_SB to configure and exchange data with local NB/SB for interconnecting with other OVN deployments\[char46] +.SH "OPTIONS" +.TP +\fB\-\-ovnnb\-db=\fIdatabase\fB\fR +The OVSDB database containing the OVN Northbound Database\[char46] If the \fBOVN_NB_DB\fR environment variable is set, its value is used as the default\[char46] Otherwise, the default is \fBunix:/ovnnb_db\[char46]sock\fR\[char46] +.TP +\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\-\-ic\-nb\-db=\fIdatabase\fB\fR +The OVSDB database containing the OVN Interconnection Northbound Database\[char46] If the \fBOVN_IC_NB_DB\fR environment variable is set, its value is used as the default\[char46] Otherwise, the default is \fBunix:/ovn_ic_nb_db\[char46]sock\fR\[char46] +.TP +\fB\-\-ic\-sb\-db=\fIdatabase\fB\fR +The OVSDB database containing the OVN Interconnection Southbound Database\[char46] If the \fBOVN_IC_SB_DB\fR environment variable is set, its value is used as the default\[char46] Otherwise, the default is \fBunix:/ovn_ic_sb_db\[char46]sock\fR\[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] +.SS "Daemon Options" +.TP +\fB\-\-pidfile\fR[\fB=\fR\fIpidfile\fR] +Causes a file (by default, \fB\fIprogram\fB\[char46]pid\fR) to be created indicating the PID of the running process\[char46] If the \fIpidfile\fR argument is not specified, or if it does not begin with \fB/\fR, then it is created in \fB\fR\[char46] +.IP +If \fB\-\-pidfile\fR is not specified, no pidfile is created\[char46] +.TP +\fB\-\-overwrite\-pidfile\fR +By default, when \fB\-\-pidfile\fR is specified and the specified pidfile already exists and is locked by a running process, the daemon refuses to start\[char46] Specify \fB\-\-overwrite\-pidfile\fR to cause it to instead overwrite the pidfile\[char46] +.IP +When \fB\-\-pidfile\fR is not specified, this option has no effect\[char46] +.TP +\fB\-\-detach\fR +Runs this program as a background process\[char46] 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 \fB\-\-no\-chdir\fR is specified)\[char46] After the child completes its initialization, the parent exits\[char46] +.TP +\fB\-\-monitor\fR +Creates an additional process to monitor this program\[char46] If it dies due to a signal that indicates a programming error (\fBSIGABRT\fR, \fBSIGALRM\fR, \fBSIGBUS\fR, \fBSIGFPE\fR, \fBSIGILL\fR, \fBSIGPIPE\fR, \fBSIGSEGV\fR, \fBSIGXCPU\fR, or \fBSIGXFSZ\fR) then the monitor process starts a new copy of it\[char46] If the daemon dies or exits for another reason, the monitor process exits\[char46] +.IP +This option is normally used with \fB\-\-detach\fR, but it also functions without it\[char46] +.TP +\fB\-\-no\-chdir\fR +By default, when \fB\-\-detach\fR is specified, the daemon changes its current working directory to the root directory after it detaches\[char46] Otherwise, invoking the daemon from a carelessly chosen directory would prevent the administrator from unmounting the file system that holds that directory\[char46] +.IP +Specifying \fB\-\-no\-chdir\fR suppresses this behavior, preventing the daemon from changing its current working directory\[char46] 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\[char46] +.IP +This option has no effect when \fB\-\-detach\fR is not specified\[char46] +.TP +\fB\-\-no\-self\-confinement\fR +By default this daemon will try to self-confine itself to work with files under well-known directories determined at build time\[char46] 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\[char46] Note that in contrast to other access control implementations that are typically enforced from kernel-space (e\[char46]g\[char46] 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 additional layer of security\[char46] +.TP +\fB\-\-user=\fR\fIuser\fR\fB:\fR\fIgroup\fR +Causes this program to run as a different user specified in \fIuser\fR\fB:\fR\fIgroup\fR, thus dropping most of the root privileges\[char46] Short forms \fIuser\fR and \fB:\fR\fIgroup\fR are also allowed, with current user or group assumed, respectively\[char46] Only daemons started by the root user accepts this argument\[char46] +.IP +On Linux, daemons will be granted \fBCAP_IPC_LOCK\fR and \fBCAP_NET_BIND_SERVICES\fR before dropping root privileges\[char46] Daemons that interact with a datapath, such as \fBovs\-vswitchd\fR, will be granted three additional capabilities, namely \fBCAP_NET_ADMIN\fR, \fBCAP_NET_BROADCAST\fR and \fBCAP_NET_RAW\fR\[char46] The capability change will apply even if the new user is root\[char46] +.IP +On Windows, this option is not currently supported\[char46] For security reasons, specifying this option will cause the daemon process not to start\[char46] +.SS "Logging Options" +.TP +\fB\-v\fR[\fIspec\fR] +.TQ .5in +\fB\-\-verbose=\fR[\fIspec\fR] +Sets logging levels\[char46] Without any \fIspec\fR, sets the log level for every module and destination to \fBdbg\fR\[char46] Otherwise, \fIspec\fR is a list of words separated by spaces or commas or colons, up to one from each category below: +.RS +.IP \(bu +A valid module name, as displayed by the \fBvlog/list\fR command on \fBovs\-appctl\fR(8), limits the log level change to the specified module\[char46] +.IP \(bu +\fBsyslog\fR, \fBconsole\fR, or \fBfile\fR, to limit the log level change to only to the system log, to the console, or to a file, respectively\[char46] (If \fB\-\-detach\fR is specified, the daemon closes its standard file descriptors, so logging to the console will have no effect\[char46]) +.IP +On Windows platform, \fBsyslog\fR is accepted as a word and is only useful along with the \fB\-\-syslog\-target\fR option (the word has no effect otherwise)\[char46] +.IP \(bu +\fBoff\fR, \fBemer\fR, \fBerr\fR, \fBwarn\fR, \fBinfo\fR, or \fBdbg\fR, to control the log level\[char46] Messages of the given severity or higher will be logged, and messages of lower severity will be filtered out\[char46] \fBoff\fR filters out all messages\[char46] See \fBovs\-appctl\fR(8) for a definition of each log level\[char46] +.RE +.IP +Case is not significant within \fIspec\fR\[char46] +.IP +Regardless of the log levels set for \fBfile\fR, logging to a file will not take place unless \fB\-\-log\-file\fR is also specified (see below)\[char46] +.IP +For compatibility with older versions of OVS, \fBany\fR is accepted as a word but has no effect\[char46] +.TP +\fB\-v\fR +.TQ .5in +\fB\-\-verbose\fR +Sets the maximum logging verbosity level, equivalent to \fB\-\-verbose=dbg\fR\[char46] +.TP +\fB\-vPATTERN:\fR\fIdestination\fR\fB:\fR\fIpattern\fR +.TQ .5in +\fB\-\-verbose=PATTERN:\fR\fIdestination\fR\fB:\fR\fIpattern\fR +Sets the log pattern for \fIdestination\fR to \fIpattern\fR\[char46] Refer to \fBovs\-appctl\fR(8) for a description of the valid syntax for \fIpattern\fR\[char46] +.TP +\fB\-vFACILITY:\fR\fIfacility\fR +.TQ .5in +\fB\-\-verbose=FACILITY:\fR\fIfacility\fR +Sets the RFC5424 facility of the log message\[char46] \fIfacility\fR can be one of \fBkern\fR, \fBuser\fR, \fBmail\fR, \fBdaemon\fR, \fBauth\fR, \fBsyslog\fR, \fBlpr\fR, \fBnews\fR, \fBuucp\fR, \fBclock\fR, \fBftp\fR, \fBntp\fR, \fBaudit\fR, \fBalert\fR, \fBclock2\fR, \fBlocal0\fR, \fBlocal1\fR, \fBlocal2\fR, \fBlocal3\fR, \fBlocal4\fR, \fBlocal5\fR, \fBlocal6\fR or \fBlocal7\fR\[char46] If this option is not specified, \fBdaemon\fR is used as the default for the local system syslog and \fBlocal0\fR is used while sending a message to the target provided via the \fB\-\-syslog\-target\fR option\[char46] +.TP +\fB\-\-log\-file\fR[\fB=\fR\fIfile\fR] +Enables logging to a file\[char46] If \fIfile\fR is specified, then it is used as the exact name for the log file\[char46] The default log file name used if \fIfile\fR is omitted is \fB/usr/local/var/log/ovn/\fIprogram\fB\[char46]log\fR\[char46] +.TP +\fB\-\-syslog\-target=\fR\fIhost\fR\fB:\fR\fIport\fR +Send syslog messages to UDP \fIport\fR on \fIhost\fR, in addition to the system syslog\[char46] The \fIhost\fR must be a numerical IP address, not a hostname\[char46] +.TP +\fB\-\-syslog\-method=\fR\fImethod\fR +Specify \fImethod\fR as how syslog messages should be sent to syslog daemon\[char46] The following forms are supported: +.RS +.IP \(bu +\fBlibc\fR, to use the libc \fBsyslog()\fR function\[char46] Downside of using this options is that libc adds fixed prefix to every message before it is actually sent to the syslog daemon over \fB/dev/log\fR UNIX domain socket\[char46] +.IP \(bu +\fBunix:\fIfile\fB\fR, to use a UNIX domain socket directly\[char46] It is possible to specify arbitrary message format with this option\[char46] However, \fBrsyslogd 8\[char46]9\fR and older versions use hard coded parser function anyway that limits UNIX domain socket use\[char46] If you want to use arbitrary message format with older \fBrsyslogd\fR versions, then use UDP socket to localhost IP address instead\[char46] +.IP \(bu +\fBudp:\fIip\fB:\fIport\fB\fR, to use a UDP socket\[char46] With this method it is possible to use arbitrary message format also with older \fBrsyslogd\fR\[char46] When sending syslog messages over UDP socket extra precaution needs to be taken into account, for example, 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\[char46] +.IP \(bu +\fBnull\fR, to discard all messages logged to syslog\[char46] +.RE +.IP +The default is taken from the \fBOVS_SYSLOG_METHOD\fR environment variable; if it is unset, the default is \fBlibc\fR\[char46] +.SS "PKI Options" +.PP +.PP +PKI configuration is required in order to use SSL for the connections to the Northbound and Southbound databases\[char46] +.RS +.TP +\fB\-p\fR \fIprivkey\[char46]pem\fR +.TQ .5in +\fB\-\-private\-key=\fR\fIprivkey\[char46]pem\fR +Specifies a PEM file containing the private key used as identity for outgoing SSL connections\[char46] +.TP +\fB\-c\fR \fIcert\[char46]pem\fR +.TQ .5in +\fB\-\-certificate=\fR\fIcert\[char46]pem\fR +Specifies a PEM file containing a certificate that certifies the private key specified on \fB\-p\fR or \fB\-\-private\-key\fR to be trustworthy\[char46] The certificate must be signed by the certificate authority (CA) that the peer in SSL connections will use to verify it\[char46] +.TP +\fB\-C\fR \fIcacert\[char46]pem\fR +.TQ .5in +\fB\-\-ca\-cert=\fR\fIcacert\[char46]pem\fR +Specifies a PEM file containing the CA certificate for verifying certificates presented to this program by SSL peers\[char46] (This may be the same certificate that SSL peers use to verify the certificate specified on \fB\-c\fR or \fB\-\-certificate\fR, or it may be a different one, depending on the PKI design in use\[char46]) +.TP +\fB\-C none\fR +.TQ .5in +\fB\-\-ca\-cert=none\fR +Disables verification of certificates presented by SSL peers\[char46] This introduces a security risk, because it means that certificates cannot be verified to be those of known trusted hosts\[char46] +.RE +.SS "Other Options" +.TP +\fB\-\-unixctl=\fIsocket\fB\fR +Sets the name of the control socket on which \fB\fIprogram\fB\fR listens for runtime management commands (see \fIRUNTIME MANAGEMENT COMMANDS,\fR below)\[char46] If \fIsocket\fR does not begin with \fB/\fR, it is interpreted as relative to \fB\fR\[char46] If \fB\-\-unixctl\fR is not used at all, the default socket is \fB/\fIprogram\fB\[char46]\fR\fIpid\fR\fB\[char46]ctl\fR, where \fIpid\fR is \fB\fIprogram\fB\fR\(cqs process ID\[char46] +.IP +On Windows a local named pipe is used to listen for runtime management commands\[char46] A file is created in the absolute path as pointed by \fIsocket\fR or if \fB\-\-unixctl\fR is not used at all, a file is created as \fB\fIprogram\fB\fR in the configured \fIOVS_RUNDIR\fR directory\[char46] The file exists just to mimic the behavior of a Unix domain socket\[char46] +.IP +Specifying \fBnone\fR for \fIsocket\fR disables the control socket feature\[char46] +.ST "" +.TP +\fB\-h\fR +.TQ .5in +\fB\-\-help\fR +Prints a brief help message to the console\[char46] +.TP +\fB\-V\fR +.TQ .5in +\fB\-\-version\fR +Prints version information to the console\[char46] +.SH "RUNTIME MANAGEMENT COMMANDS" +.PP +.PP +\fBovs\-appctl\fR can send commands to a running \fBovn\-ic\fR process\[char46] The currently supported commands are described below\[char46] +.RS +.TP +\fBexit\fR +Causes \fBovn\-ic\fR to gracefully terminate\[char46] +.TP +\fBpause\fR +Pauses the ovn-ic operation from processing any database changes\[char46] This will also instruct ovn-ic to drop any lock on SB DB\[char46] +.TP +\fBresume\fR +Resumes the ovn-ic operation to process database contents\[char46] This will also instruct ovn-northd to aspire for the lock on SB DB\[char46] +.TP +\fBis\-paused\fR +Returns \(dqtrue\(dq if ovn-ic is currently paused, \(dqfalse\(dq otherwise\[char46] +.TP +\fBstatus\fR +Prints this server\(cqs status\[char46] Status will be \(dqactive\(dq if ovn-ic has acquired OVSDB lock on SB DB, \(dqstandby\(dq if it has not or \(dqpaused\(dq if this instance is paused\[char46] +.RE +.SH "ACTIVE-STANDBY FOR HIGH AVAILABILITY" +.PP +.PP +You may run \fBovn\-ic\fR more than once in an OVN deployment\[char46] When connected to a standalone or clustered DB setup, OVN will automatically ensure that only one of them is active at a time\[char46] If multiple instances of \fBovn\-ic\fR are running and the active \fBovn\-ic\fR fails, one of the hot standby instances of \fBovn\-ic\fR will automatically take over\[char46] diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic.8.html b/src/static/support/dist-docs-branch-23.06/ovn-ic.8.html new file mode 100644 index 00000000..8d78730c --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ic.8.html @@ -0,0 +1,310 @@ +
+ovn-ic(8)                         OVN Manual                         ovn-ic(8)
+
+NAME
+       ovn-ic - Open Virtual Network interconnection controller
+
+SYNOPSIS
+       ovn-ic [options]
+
+DESCRIPTION
+       ovn-ic,  OVN  interconnection controller, is a centralized daemon which
+       communicates with global interconnection databases IC_NB/IC_SB to  conā€
+       figure  and  exchange  data  with  local NB/SB for interconnecting with
+       other OVN deployments.
+
+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 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 default. Otherwise, the default is unix:/ovnsb_db.sock.
+
+       --ic-nb-db=database
+              The OVSDB database containing the OVN Interconnection Northbound
+              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.
+
+       --ic-sb-db=database
+              The OVSDB database containing the OVN Interconnection Southbound
+              Database. If the OVN_IC_SB_DB environment variable is  set,  its
+              value  is  used  as  the  default.  Otherwise,  the  default  is
+              unix:/ovn_ic_sb_db.sock.
+
+       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
+              specified, or if it does not begin with /, then it is created in
+              .
+
+              If --pidfile is not specified, no pidfile is created.
+
+       --overwrite-pidfile
+              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.
+
+              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
+              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
+              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ā€ā€
+              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ā€
+              tions without it.
+
+       --no-chdir
+              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.
+
+              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-
+              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.
+
+       --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
+              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
+              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
+              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
+            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
+                   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,  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
+                   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
+                   definition of each log level.
+
+            Case is not significant within spec.
+
+            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
+            word but has no effect.
+
+       -v
+       --verbose
+            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-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,
+            local4, local5, local6 or local7. If this option is not specified,
+            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
+            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.
+
+       --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ā€
+            name.
+
+       --syslog-method=method
+            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
+                   /dev/log UNIX domain socket.
+
+            ā€¢      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 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
+       to the Northbound and Southbound databases.
+
+              -p privkey.pem
+              --private-key=privkey.pem
+                   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ā€
+                   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
+                   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
+                   verify the certificate specified on -c or --certificate, or
+                   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
+                   trusted hosts.
+
+   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
+              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ā€
+              agement  commands.  A  file  is  created in the absolute path as
+              pointed by socket or if --unixctl is not used at all, a file  is
+              created  as  program in the configured OVS_RUNDIR directory. The
+              file exists just to mimic the behavior of a Unix domain socket.
+
+              Specifying none for socket disables the control socket feature.
+
+
+
+       -h
+       --help
+            Prints a brief help message to the console.
+
+       -V
+       --version
+            Prints version information to the console.
+
+RUNTIME MANAGEMENT COMMANDS
+       ovs-appctl can send commands to a running ovn-ic process. The currently
+       supported commands are described below.
+
+              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
+                     on SB DB.
+
+              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"
+                     otherwise.
+
+              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
+       instances of ovn-ic will automatically take over.
+
+OVN 23.06.3                         ovn-ic                           ovn-ic(8)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic.8.pdf b/src/static/support/dist-docs-branch-23.06/ovn-ic.8.pdf new file mode 100644 index 00000000..a134eb57 Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-ic.8.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-ic.8.txt b/src/static/support/dist-docs-branch-23.06/ovn-ic.8.txt new file mode 100644 index 00000000..e8e0176c --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-ic.8.txt @@ -0,0 +1,308 @@ +ovn-ic(8) OVN Manual ovn-ic(8) + +NAME + ovn-ic - Open Virtual Network interconnection controller + +SYNOPSIS + ovn-ic [options] + +DESCRIPTION + ovn-ic, OVN interconnection controller, is a centralized daemon which + communicates with global interconnection databases IC_NB/IC_SB to conā€ + figure and exchange data with local NB/SB for interconnecting with + other OVN deployments. + +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 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 default. Otherwise, the default is unix:/ovnsb_db.sock. + + --ic-nb-db=database + The OVSDB database containing the OVN Interconnection Northbound + 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. + + --ic-sb-db=database + The OVSDB database containing the OVN Interconnection Southbound + Database. If the OVN_IC_SB_DB environment variable is set, its + value is used as the default. Otherwise, the default is + unix:/ovn_ic_sb_db.sock. + + 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 + specified, or if it does not begin with /, then it is created in + . + + If --pidfile is not specified, no pidfile is created. + + --overwrite-pidfile + 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. + + 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 + 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 + 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ā€ā€ + 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ā€ + tions without it. + + --no-chdir + 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. + + 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- + 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. + + --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 + 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 + 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 + 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 + 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 + 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, 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 + 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 + definition of each log level. + + Case is not significant within spec. + + 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 + word but has no effect. + + -v + --verbose + 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-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, + local4, local5, local6 or local7. If this option is not specified, + 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 + 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. + + --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ā€ + name. + + --syslog-method=method + 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 + /dev/log UNIX domain socket. + + ā€¢ 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 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 + to the Northbound and Southbound databases. + + -p privkey.pem + --private-key=privkey.pem + 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ā€ + 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 + 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 + verify the certificate specified on -c or --certificate, or + 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 + trusted hosts. + + 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 + 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ā€ + agement commands. A file is created in the absolute path as + pointed by socket or if --unixctl is not used at all, a file is + created as program in the configured OVS_RUNDIR directory. The + file exists just to mimic the behavior of a Unix domain socket. + + Specifying none for socket disables the control socket feature. + + + + -h + --help + Prints a brief help message to the console. + + -V + --version + Prints version information to the console. + +RUNTIME MANAGEMENT COMMANDS + ovs-appctl can send commands to a running ovn-ic process. The currently + supported commands are described below. + + 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 + on SB DB. + + 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" + otherwise. + + 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 + instances of ovn-ic will automatically take over. + +OVN 23.06.3 ovn-ic ovn-ic(8) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-nb.5 b/src/static/support/dist-docs-branch-23.06/ovn-nb.5 new file mode 100644 index 00000000..c098c2f9 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-nb.5 @@ -0,0 +1,3665 @@ +'\" p +.\" -*- nroff -*- +.TH "ovn-nb" 5 " DB Schema 7.0.4" "Open vSwitch 23.06.3" "Open vSwitch Manual" +.fp 5 L CR \\" Make fixed-width font available as \\fL. +.de TQ +. br +. ns +. TP "\\$1" +.. +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +.SH NAME +ovn-nb \- OVN_Northbound database schema +.PP +.PP +.PP +.PP +This database is the interface between OVN and the cloud management system (CMS), such as OpenStack, running above it\[char46] The CMS produces almost all of the contents of the database\[char46] The \fBovn\-northd\fR program monitors the database contents, transforms it, and stores it into the \fBOVN_Southbound\fR database\[char46] +.PP +.PP +We generally speak of ``the\(cq\(cq CMS, but one can imagine scenarios in which multiple CMSes manage different parts of an OVN deployment\[char46] +.SS "External IDs" +.PP +.PP +Each of the tables in this database contains a special column, named \fBexternal_ids\fR\[char46] This column has the same form and purpose each place it appears\[char46] +.RS +.TP +\fBexternal_ids\fR: map of string-string pairs +Key-value pairs for use by the CMS\[char46] The CMS might use certain pairs, for example, to identify entities in its own configuration that correspond to those in this database\[char46] +.RE +.SH "TABLE SUMMARY" +.PP +The following list summarizes the purpose of each of the tables in the +\fBOVN_Northbound\fR database. Each table is described in more detail on a later +page. +.IP "Table" 1in +Purpose +.TQ 1in +\fBNB_Global\fR +Northbound configuration +.TQ 1in +\fBCopp\fR +Control plane protection +.TQ 1in +\fBLogical_Switch\fR +L2 logical switch +.TQ 1in +\fBLogical_Switch_Port\fR +L2 logical switch port +.TQ 1in +\fBForwarding_Group\fR +forwarding group +.TQ 1in +\fBAddress_Set\fR +Address Sets +.TQ 1in +\fBPort_Group\fR +Port Groups +.TQ 1in +\fBLoad_Balancer\fR +load balancer +.TQ 1in +\fBLoad_Balancer_Group\fR +load balancer group +.TQ 1in +\fBLoad_Balancer_Health_Check\fR +load balancer +.TQ 1in +\fBACL\fR +Access Control List (ACL) rule +.TQ 1in +\fBLogical_Router\fR +L3 logical router +.TQ 1in +\fBQoS\fR +QoS rule +.TQ 1in +\fBMirror\fR +Mirror Entry +.TQ 1in +\fBMeter\fR +Meter entry +.TQ 1in +\fBMeter_Band\fR +Band for meter entries +.TQ 1in +\fBLogical_Router_Port\fR +L3 logical router port +.TQ 1in +\fBLogical_Router_Static_Route\fR +Logical router static routes +.TQ 1in +\fBLogical_Router_Policy\fR +Logical router policies +.TQ 1in +\fBNAT\fR +NAT rules +.TQ 1in +\fBDHCP_Options\fR +DHCP options +.TQ 1in +\fBConnection\fR +OVSDB client connections\[char46] +.TQ 1in +\fBDNS\fR +Native DNS resolution +.TQ 1in +\fBSSL\fR +SSL configuration\[char46] +.TQ 1in +\fBGateway_Chassis\fR +Gateway_Chassis configuration\[char46] +.TQ 1in +\fBHA_Chassis_Group\fR +HA_Chassis_Group configuration\[char46] +.TQ 1in +\fBHA_Chassis\fR +HA_Chassis configuration\[char46] +.TQ 1in +\fBBFD\fR +BFD configuration\[char46] +.TQ 1in +\fBStatic_MAC_Binding\fR +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.297039,0.190275 wid 0.330865 height 0.152220 "NB_Global" +box at 0.297039,0.190275 wid 0.275310 height 0.096664 +linethick = 1.000000; +box at 1.636365,0.304440 wid 0.330865 height 0.152220 "Connection" +linethick = 1.000000; +box at 1.636365,0.076110 wid 0.228330 height 0.152220 "SSL" +linethick = 0.500000; +box at 1.636365,2.131080 wid 0.228330 height 0.152220 "Copp" +box at 1.636365,2.131080 wid 0.172774 height 0.096664 +linethick = 0.500000; +box at 0.297039,1.357285 wid 0.432335 height 0.152220 "Logical_Switch" +box at 0.297039,1.357285 wid 0.376780 height 0.096664 +linethick = 1.000000; +box at 1.636365,0.549697 wid 0.559195 height 0.152220 "Logical_Switch_Port" +linethick = 1.000000; +box at 1.636365,0.778027 wid 0.228330 height 0.152220 "ACL" +linethick = 1.000000; +box at 1.636365,1.234687 wid 0.228330 height 0.152220 "QoS" +linethick = 0.500000; +box at 2.880550,2.570813 wid 0.419671 height 0.152220 "Load_Balancer" +box at 2.880550,2.570813 wid 0.364115 height 0.096664 +linethick = 0.500000; +box at 1.636365,2.570813 wid 0.594084 height 0.152220 "Load_Balancer_Group" +box at 1.636365,2.570813 wid 0.538529 height 0.096664 +linethick = 0.500000; +box at 1.636365,1.006357 wid 0.228330 height 0.152220 "DNS" +box at 1.636365,1.006357 wid 0.172774 height 0.096664 +linethick = 1.000000; +box at 1.636365,1.463017 wid 0.511642 height 0.152220 "Forwarding_Group" +linethick = 0.500000; +box at 2.880550,0.663862 wid 0.429169 height 0.152220 "DHCP_Options" +box at 2.880550,0.663862 wid 0.373614 height 0.096664 +linethick = 0.500000; +box at 2.880550,0.393245 wid 0.228330 height 0.152220 "Mirror" +box at 2.880550,0.393245 wid 0.172774 height 0.096664 +linethick = 0.500000; +box at 4.132773,1.446090 wid 0.530669 height 0.152220 "HA_Chassis_Group" +box at 4.132773,1.446090 wid 0.475114 height 0.096664 +linethick = 0.500000; +box at 2.880550,1.577182 wid 0.356225 height 0.152220 "Address_Set" +box at 2.880550,1.577182 wid 0.300670 height 0.096664 +linethick = 0.500000; +box at 0.297039,0.617343 wid 0.340394 height 0.152220 "Port_Group" +box at 0.297039,0.617343 wid 0.284839 height 0.096664 +linethick = 1.000000; +box at 4.132773,2.570813 wid 0.774830 height 0.152220 "Load_Balancer_Health_Check" +linethick = 0.500000; +box at 0.297039,3.467267 wid 0.228330 height 0.152220 "Meter" +box at 0.297039,3.467267 wid 0.172774 height 0.096664 +linethick = 1.000000; +box at 1.636365,3.467267 wid 0.356225 height 0.152220 "Meter_Band" +linethick = 0.500000; +box at 0.297039,2.570813 wid 0.429169 height 0.152220 "Logical_Router" +box at 0.297039,2.570813 wid 0.373614 height 0.096664 +linethick = 1.000000; +box at 2.880550,1.847768 wid 0.556029 height 0.152220 "Logical_Router_Port" +linethick = 1.000000; +box at 1.636365,3.238937 wid 0.752637 height 0.152220 "Logical_Router_Static_Route" +linethick = 1.000000; +box at 1.636365,3.010577 wid 0.603583 height 0.152220 "Logical_Router_Policy" +linethick = 1.000000; +box at 1.636365,1.691347 wid 0.228330 height 0.152220 "NAT" +linethick = 1.000000; +box at 4.132773,1.847768 wid 0.473587 height 0.152220 "Gateway_Chassis" +linethick = 0.500000; +box at 2.880550,3.238937 wid 0.228330 height 0.152220 "BFD" +box at 2.880550,3.238937 wid 0.172774 height 0.096664 +linethick = 1.000000; +box at 5.123116,1.446090 wid 0.356225 height 0.152220 "HA_Chassis" +linethick = 0.500000; +box at 0.297039,3.695597 wid 0.568724 height 0.152220 "Static_MAC_Binding" +box at 0.297039,3.695597 wid 0.513169 height 0.096664 +linethick = 0.500000; +box at 0.297039,3.923927 wid 0.594084 height 0.152220 "Chassis_Template_Var" +box at 0.297039,3.923927 wid 0.538529 height 0.096664 +linethick = 1.000000; +spline -> from 0.464454,0.204273 to 0.464454,0.204273 to 0.720579,0.226245 to 1.214046,0.268574 to 1.469684,0.290506 +"connections*" at 0.927050,0.296512 +linethick = 1.000000; +spline -> from 0.464545,0.169546 to 0.464545,0.169546 to 0.528599,0.161819 to 0.602791,0.153374 to 0.670194,0.146935 to 0.977740,0.117560 to 1.341637,0.093740 to 1.520921,0.082725 +"ssl?" at 0.927050,0.178119 +linethick = 0.500000; +spline -> from 0.358539,1.434552 to 0.358539,1.434552 to 0.424237,1.517146 to 0.539772,1.645285 to 0.670194,1.712475 to 0.876696,1.818877 to 1.004013,1.661755 to 1.183937,1.808678 to 1.253471,1.865456 to 1.195384,1.933498 to 1.260047,1.995787 to 1.331347,2.064438 to 1.440153,2.098657 to 1.521743,2.115462 +"copp?" at 0.927050,1.835621 +linethick = 1.000000; +spline -> from 0.336924,1.279166 to 0.336924,1.279166 to 0.423354,1.090535 to 0.639233,0.624132 to 0.670194,0.603583 to 0.778727,0.531583 to 1.111267,0.527229 to 1.355062,0.534871 +"ports*" at 0.927050,0.634788 +linethick = 1.000000; +spline -> from 0.357352,1.280322 to 0.357352,1.280322 to 0.422806,1.196297 to 0.538950,1.064231 to 0.670194,0.992596 to 0.951071,0.839311 to 1.334878,0.795471 to 1.521378,0.782959 +"acls*" at 0.927050,1.019570 +linethick = 1.000000; +spline -> from 0.513712,1.328059 to 0.513712,1.328059 to 0.564888,1.321513 to 0.619444,1.314968 to 0.670194,1.309731 to 0.977618,1.277948 to 1.341576,1.252984 to 1.520891,1.241537 +"qos_rules*" at 0.927050,1.336674 +linethick = 0.500000; +spline -> from 0.500804,1.435374 to 0.500804,1.435374 to 0.742499,1.530724 to 1.124814,1.684406 to 1.183937,1.725170 to 1.224427,1.753087 to 1.216999,1.781674 to 1.260047,1.805512 to 1.558581,1.970671 to 1.699536,1.821221 to 2.012683,1.956666 to 2.330153,2.093969 to 2.647106,2.360810 to 2.793085,2.492907 +"load_balancer*" at 1.636365,1.983609 +linethick = 1.000000; +spline -> from 0.320332,1.435161 to 0.320332,1.435161 to 0.359513,1.577486 to 0.463358,1.878425 to 0.670194,2.025378 to 0.859008,2.159515 to 1.015094,1.954535 to 1.183937,2.113118 to 1.291252,2.213918 to 1.162200,2.325495 to 1.260047,2.435520 to 1.281966,2.460180 to 1.308757,2.480334 to 1.337801,2.496834 +"load_balancer_group*" at 0.927050,2.140061 +linethick = 0.500000; +spline -> from 0.448714,1.279135 to 0.448714,1.279135 to 0.514899,1.246712 to 0.594937,1.211123 to 0.670194,1.187103 to 0.969672,1.091509 to 1.338653,1.039693 to 1.520312,1.018291 +"dns_records*" at 0.927050,1.214046 +linethick = 1.000000; +spline -> from 0.515082,1.374273 to 0.515082,1.374273 to 0.750597,1.392996 to 1.128955,1.423044 to 1.379052,1.442893 +"forwarding_groups*" at 0.927050,1.455071 +linethick = 0.500000; +spline -> from 1.917637,0.529269 to 1.917637,0.529269 to 2.093147,0.521567 to 2.324339,0.521201 to 2.526426,0.552863 to 2.572396,0.560048 to 2.620589,0.572165 to 2.666012,0.585834 +"dhcpv4_options?" at 2.307625,0.584038 +linethick = 0.500000; +spline -> from 1.917546,0.592227 to 1.917546,0.592227 to 1.974111,0.599990 to 2.033294,0.607388 to 2.088793,0.613112 to 2.283696,0.633144 to 2.506576,0.646631 to 2.665372,0.654637 +"dhcpv6_options?" at 2.307625,0.677075 +linethick = 0.500000; +spline -> from 1.918002,0.482416 to 1.918002,0.482416 to 1.974263,0.470573 to 2.033233,0.459491 to 2.088793,0.451363 to 2.328235,0.416443 to 2.611852,0.402043 to 2.764924,0.396472 +"mirror_rules*" at 2.307625,0.482568 +linethick = 1.000000; +spline -> from 1.917424,0.622214 to 1.917424,0.622214 to 1.950243,0.634423 to 1.982696,0.648275 to 2.012683,0.663862 to 2.050708,0.683620 to 2.051195,0.702465 to 2.088793,0.723045 to 2.688571,1.051384 to 3.466354,1.278313 to 3.866084,1.382066 +"ha_chassis_group?" at 2.880550,1.197149 +linethick = 1.000000; +spline -> from 3.091588,2.570813 to 3.091588,2.570813 to 3.268772,2.570813 to 3.528460,2.570813 to 3.744003,2.570813 +"health_check*" at 3.452045,2.600953 +linethick = 0.500000; +spline -> from 1.935021,2.570813 to 1.935021,2.570813 to 2.161311,2.570813 to 2.468217,2.570813 to 2.669178,2.570813 +"load_balancer*" at 2.307625,2.600953 +linethick = 1.000000; +spline -> from 4.400071,1.446090 to 4.400071,1.446090 to 4.572080,1.446090 to 4.792494,1.446090 to 4.943497,1.446090 +"ha_chassis*" at 4.732520,1.476230 +linethick = 0.500000; +spline -> from 0.451363,0.539194 to 0.451363,0.539194 to 0.516726,0.509389 to 0.595363,0.478975 to 0.670194,0.464058 to 0.898737,0.418483 to 1.162687,0.447618 to 1.356219,0.483816 +"ports*" at 0.927050,0.495233 +linethick = 1.000000; +spline -> from 0.468016,0.648518 to 0.468016,0.648518 to 0.531187,0.659691 to 0.603857,0.671716 to 0.670194,0.680758 to 0.977039,0.722588 to 1.341241,0.754646 to 1.520739,0.769289 +"acls*" at 0.927050,0.765849 +linethick = 1.000000; +spline -> from 0.412455,3.467267 to 0.412455,3.467267 to 0.643921,3.467267 to 1.179066,3.467267 to 1.457202,3.467267 +"bands+" at 0.927050,3.497407 +linethick = 0.500000; +spline -> from 0.373974,2.493729 to 0.373974,2.493729 to 0.443265,2.425321 to 0.554020,2.328692 to 0.670194,2.278003 to 0.747218,2.244423 to 1.285772,2.174280 to 1.521774,2.144688 +"copp?" at 0.927050,2.304976 +linethick = 0.500000; +spline -> from 0.513042,2.619767 to 0.513042,2.619767 to 0.564249,2.630148 to 0.618987,2.640043 to 0.670194,2.646923 to 1.487798,2.757100 to 1.709979,2.765381 to 2.526426,2.646923 to 2.573188,2.640165 to 2.623025,2.630696 to 2.669969,2.620741 +"load_balancer*" at 1.636365,2.761636 +linethick = 1.000000; +spline -> from 0.513621,2.570813 to 0.513621,2.570813 to 0.736349,2.570813 to 1.088038,2.570813 to 1.337557,2.570813 +"load_balancer_group*" at 0.927050,2.600953 +linethick = 1.000000; +spline -> from 0.512342,2.532088 to 0.512342,2.532088 to 0.954115,2.450803 to 1.941292,2.268078 to 2.012683,2.245245 to 2.277577,2.160489 to 2.567921,2.015119 to 2.735454,1.925644 +"ports*" at 1.636365,2.419141 +linethick = 1.000000; +spline -> from 0.336376,2.648171 to 0.336376,2.648171 to 0.390962,2.758896 to 0.507106,2.960375 to 0.670194,3.061449 to 0.845278,3.169829 to 1.070320,3.215191 to 1.258677,3.233153 +"static_routes*" at 0.927050,3.252028 +linethick = 1.000000; +spline -> from 0.377018,2.648993 to 0.377018,2.648993 to 0.446705,2.715848 to 0.556212,2.808885 to 0.670194,2.858357 to 0.880349,2.949567 to 1.137540,2.986861 to 1.333082,3.001778 +"policies*" at 0.927050,3.015326 +linethick = 1.000000; +spline -> from 0.325203,2.493150 to 0.325203,2.493150 to 0.370047,2.361663 to 0.479706,2.096678 to 0.670194,1.965130 to 0.861322,1.833094 to 0.965410,1.947716 to 1.183937,1.868927 to 1.220348,1.855805 to 1.224823,1.842684 to 1.260047,1.826640 to 1.345716,1.787550 to 1.446273,1.751565 to 1.521226,1.726540 +"nat*" at 0.927050,1.992073 +linethick = 1.000000; +spline -> from 3.125990,1.769862 to 3.125990,1.769862 to 3.345491,1.699019 to 3.667284,1.595022 to 3.886785,1.524148 +"ha_chassis_group?" at 3.452045,1.755279 +linethick = 1.000000; +spline -> from 3.159174,1.847768 to 3.159174,1.847768 to 3.379588,1.847768 to 3.685551,1.847768 to 3.894396,1.847768 +"gateway_chassis*" at 3.452045,1.877908 +linethick = 0.500000; +spline -> from 2.014693,3.238937 to 2.014693,3.238937 to 2.272584,3.238937 to 2.597878,3.238937 to 2.765411,3.238937 +"bfd?" at 2.307625,3.269077 +linethick = 1.000000; +spline -> from 1.751474,1.662851 to 1.751474,1.662851 to 1.826396,1.642271 to 1.926923,1.612040 to 2.012683,1.577182 to 2.047907,1.562843 to 2.051834,1.547012 to 2.088793,1.538061 to 2.277851,1.492334 to 2.332224,1.527223 to 2.526426,1.538061 to 2.583173,1.541227 to 2.644883,1.547255 to 2.700444,1.553649 +"allowed_ext_ips?" at 2.307625,1.565004 +linethick = 1.000000; +spline -> from 1.752448,1.680996 to 1.752448,1.680996 to 1.968113,1.661086 to 2.442887,1.617216 to 2.700961,1.593378 +"exempted_ext_ips?" at 2.307625,1.674938 +linethick = 0.500000; +spline -> from 1.752448,1.705503 to 1.752448,1.705503 to 1.942540,1.729554 to 2.334050,1.779117 to 2.600922,1.812910 +"gateway_port?" at 2.307625,1.831389 +.ps +3 +.PE +.RE\} +.bp +.SH "NB_Global TABLE" +.PP +.PP +.PP +Northbound configuration for an OVN system\[char46] This table must have exactly one row\[char46] +.SS "Summary: +.TQ .25in +\fIIdentity:\fR +.RS .25in +.TQ 2.75in +\fBname\fR +string +.RE +.TQ .25in +\fIStatus:\fR +.RS .25in +.TQ 2.75in +\fBnb_cfg\fR +integer +.TQ 2.75in +\fBnb_cfg_timestamp\fR +integer +.TQ 2.75in +\fBsb_cfg\fR +integer +.TQ 2.75in +\fBsb_cfg_timestamp\fR +integer +.TQ 2.75in +\fBhv_cfg\fR +integer +.TQ 2.75in +\fBhv_cfg_timestamp\fR +integer +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.TQ .25in +\fICommon options:\fR +.RS .25in +.TQ 2.75in +\fBoptions\fR +map of string-string pairs +.TQ .25in +\fIOptions for configuring OVS BFD:\fR +.RS .25in +.TQ 2.50in +\fBoptions : bfd-min-rx\fR +optional string +.TQ 2.50in +\fBoptions : bfd-decay-min-rx\fR +optional string +.TQ 2.50in +\fBoptions : bfd-min-tx\fR +optional string +.TQ 2.50in +\fBoptions : bfd-mult\fR +optional string +.RE +.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 : 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 +\fBoptions : use_parallel_build\fR +optional string +.TQ 2.75in +\fBoptions : ignore_lsp_down\fR +optional string +.TQ 2.75in +\fBoptions : use_ct_inv_match\fR +optional string +.TQ 2.75in +\fBoptions : default_acl_drop\fR +optional string +.TQ 2.75in +\fBoptions : debug_drop_domain_id\fR +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 .25in +\fIOptions for configuring interconnection route advertisement:\fR +.RS .25in +.TQ 2.50in +\fBoptions : ic-route-adv\fR +optional string +.TQ 2.50in +\fBoptions : ic-route-learn\fR +optional string +.TQ 2.50in +\fBoptions : ic-route-adv-default\fR +optional string +.TQ 2.50in +\fBoptions : ic-route-learn-default\fR +optional string +.TQ 2.50in +\fBoptions : ic-route-blacklist\fR +optional string +.RE +.RE +.TQ .25in +\fIConnection Options:\fR +.RS .25in +.TQ 2.75in +\fBconnections\fR +set of \fBConnection\fRs +.TQ 2.75in +\fBssl\fR +optional \fBSSL\fR +.RE +.TQ .25in +\fISecurity Configurations:\fR +.RS .25in +.TQ 2.75in +\fBipsec\fR +boolean +.RE +.TQ .25in +\fIRead-only Options:\fR +.RS .25in +.TQ 2.75in +\fBoptions : max_tunid\fR +optional string +.RE +.SS "Details: +.ST "Identity:" +.PP +.IP "\fBname\fR: string" +The name of the OVN cluster, which uniquely identifies the OVN cluster throughout all OVN clusters supposed to interconnect with each other\[char46] +.ST "Status:" +.PP +These columns allow a client to track the overall configuration state of the system\[char46] +.IP "\fBnb_cfg\fR: integer" +Sequence number for client to increment\[char46] When a client modifies any part of the northbound database configuration and wishes to wait for \fBovn\-northd\fR and possibly all of the hypervisors to finish applying the changes, it may increment this sequence number\[char46] +.IP "\fBnb_cfg_timestamp\fR: integer" +The timestamp, in milliseconds since the epoch, when \fBovn\-northd\fR sees the latest \fBnb_cfg\fR and starts processing\[char46] +.IP +To print the timestamp as a human-readable date: +.IP +.nf +\fB +.br +\fB date \-d \(dq@$(ovn\-nbctl get NB_Global \[char46] nb_cfg_timestamp | sed \(cqs/\[char46]\[char46]\[char46]$//\(cq)\(dq +.br +\fB \fR +.fi +.IP "\fBsb_cfg\fR: integer" +Sequence number that \fBovn\-northd\fR sets to the value of \fBnb_cfg\fR after it finishes applying the corresponding configuration changes to the \fBOVN_Southbound\fR database\[char46] +.IP "\fBsb_cfg_timestamp\fR: integer" +The timestamp, in milliseconds since the epoch, when \fBovn\-northd\fR finishes applying the corresponding configuration changes to the \fBOVN_Southbound\fR database successfully\[char46] +.IP "\fBhv_cfg\fR: integer" +Sequence number that \fBovn\-northd\fR sets to the smallest sequence number of all the chassis in the system, as reported in the \fBChassis_Private\fR table in the southbound database\[char46] Thus, \fBhv_cfg\fR equals \fBnb_cfg\fR if all chassis are caught up with the northbound configuration (which may never happen, if any chassis is down)\[char46] This value can regress, if a chassis was removed from the system and rejoins before catching up\[char46] +.IP +If there are no chassis, then \fBovn\-northd\fR copies \fBnb_cfg\fR to \fBhv_cfg\fR\[char46] Thus, in this case, the (nonexistent) hypervisors are always considered to be caught up\[char46] This means that hypervisors can be \(dqcaught up\(dq even in cases where \fBsb_cfg\fR would show that the southbound database is not\[char46] To detect when both the hypervisors and the southbound database are caught up, a client should take the smaller of \fBsb_cfg\fR and \fBhv_cfg\fR\[char46] +.IP "\fBhv_cfg_timestamp\fR: integer" +The largest timestamp, in milliseconds since the epoch, of the smallest sequence number of all the chassis in the system, as reported in the \fBChassis_Private\fR table in the southbound database\[char46] In other words, this timestamp reflects the time when the slowest chassis catches up with the northbound configuration, which is useful for end-to-end control plane latency measurement\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.ST "Common options:" +.PP +.IP "\fBoptions\fR: map of string-string pairs" +This column provides general key/value settings\[char46] The supported options are described individually below\[char46] +.ST "Options for configuring OVS BFD:" +.PP +.PP +.PP +These options apply when \fBovn\-controller\fR configures OVS BFD on tunnels interfaces\[char46] Please note these parameters refer to legacy OVS BFD implementation and not to OVN BFD one\[char46] +.IP "\fBoptions : bfd-min-rx\fR: optional string" +BFD option \fBmin\-rx\fR value to use when configuring BFD on tunnel interfaces\[char46] +.IP "\fBoptions : bfd-decay-min-rx\fR: optional string" +BFD option \fBdecay\-min\-rx\fR value to use when configuring BFD on tunnel interfaces\[char46] +.IP "\fBoptions : bfd-min-tx\fR: optional string" +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 : 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 : 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 +.IP \(bu +empty_lb_backends: event-elb +.RE +.IP "\fBoptions : northd_probe_interval\fR: optional string" +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 +\fBovn\-northd\fR combines logical flows that differs only by logical datapath into a single logical flow with logical datapath group attached\[char46] +.IP "\fBoptions : use_parallel_build\fR: optional string" +If set to \fBtrue\fR, \fBovn\-northd\fR will attempt to compute logical flows in parallel\[char46] +.IP +Parallel computation is enabled only if the system has 4 or more cores/threads available to be used by ovn-northd\[char46] +.IP +The default value is \fBfalse\fR\[char46] +.IP "\fBoptions : ignore_lsp_down\fR: optional string" +If set to false, ARP/ND reply flows for logical switch ports will be installed only if the port is up, i\[char46]e\[char46] claimed by a Chassis\[char46] 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/container is running\[char46] For environments where this is not an issue, setting it to \fBtrue\fR can reduce the load and latency of the control plane\[char46] The default value is \fBtrue\fR\[char46] +.IP "\fBoptions : use_ct_inv_match\fR: optional string" +If set to false, \fBovn\-northd\fR will not use the \fBct\[char46]inv\fR field in any of the logical flow matches\[char46] The default value is true\[char46] If the NIC supports offloading OVS datapath flows but doesn\(cqt support offloading ct_state \fBinv\fR flag, then the datapath flows matching on this flag (either \fB+inv\fR or \fB\-inv\fR) will not be offloaded\[char46] CMS should consider setting \fBuse_ct_inv_match\fR to \fBfalse\fR in such cases\[char46] This results in a side effect of the invalid packets getting delivered to the destination VIF, which otherwise would have been dropped by \fBOVN\fR\[char46] +.IP "\fBoptions : default_acl_drop\fR: optional string" +If set to \fBtrue\fR\[char46], \fBovn\-northd\fR will generate a logical flow to drop all traffic in the ACL stages\[char46] By default this option is set to \fBfalse\fR\[char46] +.IP "\fBoptions : debug_drop_domain_id\fR: optional string" +If set to a 8-bit number and if \fBdebug_drop_collector_set\fR is also configured, \fBovn\-northd\fR will add a \fBsample\fR action to every logical flow that contains a \(cqdrop\(cq action\[char46] The 8 most significant bits of the observation_domain_id field will be those specified in the \fB debug_drop_domain_id\fR\[char46] The 24 least significant bits of the observation_domain_id field will be the datapath\(cqs key\[char46] +.IP +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] +.ST "Options for configuring interconnection route advertisement:" +.PP +.PP +.PP +These options control how routes are advertised between OVN deployments for interconnection\[char46] If enabled, \fBovn\-ic\fR from different OVN deployments exchanges routes between each other through the global \fBOVN_IC_Southbound\fR database\[char46] Only routers with ports connected to interconnection transit switches participate in route advertisement\[char46] For each of these routers, there are two types of routes to be advertised: +.PP +.PP +Firstly, the static routes configured in the router are advertised\[char46] +.PP +.PP +Secondly, the \fBnetworks\fR configured in the logical router ports that are not on the transit switches are advertised\[char46] These are considered as directly connected subnets on the router\[char46] +.PP +.PP +Link local prefixes (IPv4 169\[char46]254\[char46]0\[char46]0/16 and IPv6 FE80::/10) are never advertised\[char46] +.PP +.PP +The learned routes are added to the \fBstatic_routes\fR column of the \fBLogical_Router\fR table, with \fBexternal_ids:ic\-learned\-route\fR set to the uuid of the row in \fBRoute\fR table of the \fBOVN_IC_Southbound\fR database\[char46] +.IP "\fBoptions : ic-route-adv\fR: optional string" +A boolean value that enables route advertisement to the global \fBOVN_IC_Southbound\fR database\[char46] Default is \fBfalse\fR\[char46] +.IP "\fBoptions : ic-route-learn\fR: optional string" +A boolean value that enables route learning from the global \fBOVN_IC_Southbound\fR database\[char46] Default is \fBfalse\fR\[char46] +.IP "\fBoptions : ic-route-adv-default\fR: optional string" +A boolean value that enables advertising default route to the global \fBOVN_IC_Southbound\fR database\[char46] Default is \fBfalse\fR\[char46] This option takes effect only when option \fBic\-route\-adv\fR is \fBtrue\fR\[char46] +.IP "\fBoptions : ic-route-learn-default\fR: optional string" +A boolean value that enables learning default route from the global \fBOVN_IC_Southbound\fR database\[char46] Default is \fBfalse\fR\[char46] This option takes effect only when option \fBic\-route\-learn\fR is \fBtrue\fR\[char46] +.IP "\fBoptions : ic-route-blacklist\fR: optional string" +A string value contains a list of CIDRs delimited by \(dq,\(dq\[char46] A route will not be advertised or learned if the route\(cqs prefix belongs to any of the CIDRs listed\[char46] +.ST "Connection Options:" +.PP +.IP "\fBconnections\fR: set of \fBConnection\fRs" +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\[char46] See the \fBConnection\fR table for more information\[char46] +.IP "\fBssl\fR: optional \fBSSL\fR" +Global SSL configuration\[char46] +.ST "Security Configurations:" +.PP +.IP "\fBipsec\fR: boolean" +Tunnel encryption configuration\[char46] If this column is set to be true, all OVN tunnels will be encrypted with IPsec\[char46] +.ST "Read-only Options:" +.PP +.IP "\fBoptions : max_tunid\fR: optional string" +The maximum supported tunnel ID\[char46] Depends on types of encapsulation enabled in the cluster\[char46] +.bp +.SH "Copp TABLE" +.PP +.PP +.PP +This table is used to define control plane protection policies, i\[char46]e\[char46], associate entries from table \fBMeter\fR to control protocol names\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBmeters : arp\fR +optional string +.TQ 3.00in +\fBmeters : arp-resolve\fR +optional string +.TQ 3.00in +\fBmeters : dhcpv4-opts\fR +optional string +.TQ 3.00in +\fBmeters : dhcpv6-opts\fR +optional string +.TQ 3.00in +\fBmeters : dns\fR +optional string +.TQ 3.00in +\fBmeters : event-elb\fR +optional string +.TQ 3.00in +\fBmeters : icmp4-error\fR +optional string +.TQ 3.00in +\fBmeters : icmp6-error\fR +optional string +.TQ 3.00in +\fBmeters : igmp\fR +optional string +.TQ 3.00in +\fBmeters : nd-na\fR +optional string +.TQ 3.00in +\fBmeters : nd-ns\fR +optional string +.TQ 3.00in +\fBmeters : nd-ns-resolve\fR +optional string +.TQ 3.00in +\fBmeters : nd-ra-opts\fR +optional string +.TQ 3.00in +\fBmeters : tcp-reset\fR +optional string +.TQ 3.00in +\fBmeters : bfd\fR +optional string +.TQ 3.00in +\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: +.IP "\fBname\fR: string (must be unique within table)" +CoPP name\[char46] +.IP "\fBmeters : arp\fR: optional string" +Rate limiting meter for ARP packets (request/reply) used for learning neighbors\[char46] +.IP "\fBmeters : arp-resolve\fR: optional string" +Rate limiting meter for packets that require resolving the next-hop (through ARP)\[char46] +.IP "\fBmeters : dhcpv4-opts\fR: optional string" +Rate limiting meter for packets that require adding DHCPv4 options\[char46] +.IP "\fBmeters : dhcpv6-opts\fR: optional string" +Rate limiting meter for packets that require adding DHCPv6 options\[char46] +.IP "\fBmeters : dns\fR: optional string" +Rate limiting meter for DNS query packets that need to be replied to\[char46] +.IP "\fBmeters : event-elb\fR: optional string" +Rate limiting meter for empty load balancer events\[char46] +.IP "\fBmeters : icmp4-error\fR: optional string" +Rate limiting meter for packets that require replying with an ICMP error\[char46] +.IP "\fBmeters : icmp6-error\fR: optional string" +Rate limiting meter for packets that require replying with an ICMPv6 error\[char46] +.IP "\fBmeters : igmp\fR: optional string" +Rate limiting meter for IGMP packets\[char46] +.IP "\fBmeters : nd-na\fR: optional string" +Rate limiting meter for ND neighbor advertisement packets used for learning neighbors\[char46] +.IP "\fBmeters : nd-ns\fR: optional string" +Rate limiting meter for ND neighbor solicitation packets used for learning neighbors\[char46] +.IP "\fBmeters : nd-ns-resolve\fR: optional string" +Rate limiting meter for packets that require resolving the next-hop (through ND)\[char46] +.IP "\fBmeters : nd-ra-opts\fR: optional string" +Rate limiting meter for packets that require adding ND router advertisement options\[char46] +.IP "\fBmeters : tcp-reset\fR: optional string" +Rate limiting meter for packets that require replying with TCP RST packet\[char46] +.IP "\fBmeters : bfd\fR: optional string" +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 +.SH "Logical_Switch TABLE" +.PP +.PP +.PP +Each row represents one L2 logical switch\[char46] +.PP +.PP +There are two kinds of logical switches, that is, ones that fully virtualize the network (overlay logical switches) and ones that provide simple connectivity to physical networks (bridged logical switches)\[char46] They work in the same way when providing connectivity between logical ports on same chassis, but differently when connecting remote logical ports\[char46] Overlay logical switches connect remote logical ports by tunnels, while bridged logical switches provide connectivity to remote ports by bridging the packets to directly connected physical L2 segments with the help of \fBlocalnet\fR ports\[char46] Each bridged logical switch has one or more \fBlocalnet\fR ports, which have only one special address \fBunknown\fR\[char46] +.SS "Summary: +.TQ 3.00in +\fBports\fR +set of \fBLogical_Switch_Port\fRs +.TQ 3.00in +\fBload_balancer\fR +set of weak reference to \fBLoad_Balancer\fRs +.TQ 3.00in +\fBload_balancer_group\fR +set of \fBLoad_Balancer_Group\fRs +.TQ 3.00in +\fBacls\fR +set of \fBACL\fRs +.TQ 3.00in +\fBqos_rules\fR +set of \fBQoS\fRes +.TQ 3.00in +\fBdns_records\fR +set of weak reference to \fBDNS\fRes +.TQ 3.00in +\fBforwarding_groups\fR +set of \fBForwarding_Group\fRs +.TQ .25in +\fINaming:\fR +.RS .25in +.TQ 2.75in +\fBname\fR +string +.TQ 2.75in +\fBexternal_ids : neutron:network_name\fR +optional string +.RE +.TQ .25in +\fIIP Address Assignment:\fR +.RS .25in +.TQ 2.75in +\fBother_config : subnet\fR +optional string +.TQ 2.75in +\fBother_config : exclude_ips\fR +optional string +.TQ 2.75in +\fBother_config : ipv6_prefix\fR +optional string +.TQ 2.75in +\fBother_config : mac_only\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.RE +.TQ .25in +\fIIP Multicast Snooping Options:\fR +.RS .25in +.TQ 2.75in +\fBother_config : mcast_snoop\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.TQ 2.75in +\fBother_config : mcast_querier\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.TQ 2.75in +\fBother_config : mcast_flood_unregistered\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.TQ 2.75in +\fBother_config : mcast_table_size\fR +optional string, containing an integer, in range 1 to 32,766 +.TQ 2.75in +\fBother_config : mcast_idle_timeout\fR +optional string, containing an integer, in range 15 to 3,600 +.TQ 2.75in +\fBother_config : mcast_query_interval\fR +optional string, containing an integer, in range 1 to 3,600 +.TQ 2.75in +\fBother_config : mcast_query_max_response\fR +optional string, containing an integer, in range 1 to 10 +.TQ 2.75in +\fBother_config : mcast_eth_src\fR +optional string +.TQ 2.75in +\fBother_config : mcast_ip4_src\fR +optional string +.TQ 2.75in +\fBother_config : mcast_ip6_src\fR +optional string +.RE +.TQ .25in +\fIInterconnection:\fR +.RS .25in +.TQ 2.75in +\fBother_config : interconn-ts\fR +optional string +.RE +.TQ .25in +\fITunnel Key:\fR +.RS .25in +.TQ 2.75in +\fBother_config : requested-tnl-key\fR +optional string, containing an integer, in range 1 to 16,777,215 +.RE +.TQ 3.00in +\fBcopp\fR +optional weak reference to \fBCopp\fR +.TQ .25in +\fIOther options:\fR +.RS .25in +.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 +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBports\fR: set of \fBLogical_Switch_Port\fRs" +The logical ports connected to the logical switch\[char46] +.IP +It is an error for multiple logical switches to include the same logical port\[char46] +.IP "\fBload_balancer\fR: set of weak reference to \fBLoad_Balancer\fRs" +Set of load balancers associated to this logical switch\[char46] +.IP "\fBload_balancer_group\fR: set of \fBLoad_Balancer_Group\fRs" +Set of load balancers groups associated to this logical switch\[char46] +.IP "\fBacls\fR: set of \fBACL\fRs" +Access control rules that apply to packets within the logical switch\[char46] +.IP "\fBqos_rules\fR: set of \fBQoS\fRes" +QoS marking and metering rules that apply to packets within the logical switch\[char46] +.IP "\fBdns_records\fR: set of weak reference to \fBDNS\fRes" +This column defines the DNS records to be used for resolving internal DNS queries within the logical switch by the native DNS resolver\[char46] Please see the \fBDNS\fR table\[char46] +.IP "\fBforwarding_groups\fR: set of \fBForwarding_Group\fRs" +Groups a set of logical port endpoints for traffic going out of the logical switch\[char46] +.ST "Naming:" +.PP +.PP +.PP +These columns provide names for the logical switch\[char46] From OVN\(cqs perspective, these names have no special meaning or purpose other than to provide convenience for human interaction with the database\[char46] There is no requirement for the name to be unique\[char46] (For a unique identifier for a logical switch, use its row UUID\[char46]) +.PP +.PP +(Originally, \fBname\fR 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 \fBneutron\-\fIuuid\fB\fR\[char46] Later on, Neutron started propagating the friendly name of a switch as \fBexternal_ids:neutron:network_name\fR\[char46] Perhaps this can be cleaned up someday\[char46]) +.IP "\fBname\fR: string" +A name for the logical switch\[char46] +.IP "\fBexternal_ids : neutron:network_name\fR: optional string" +Another name for the logical switch\[char46] +.ST "IP Address Assignment:" +.PP +.PP +.PP +These options control automatic IP address management (IPAM) for ports attached to the logical switch\[char46] To enable IPAM for IPv4, set \fBother_config:subnet\fR and optionally \fBother_config:exclude_ips\fR\[char46] To enable IPAM for IPv6, set \fBother_config:ipv6_prefix\fR\[char46] IPv4 and IPv6 may be enabled together or separately\[char46] +.PP +.PP +To request dynamic address assignment for a particular port, use the \fBdynamic\fR keyword in the \fBaddresses\fR column of the port\(cqs \fBLogical_Switch_Port\fR row\[char46] This requests both an IPv4 and an IPv6 address, if IPAM for IPv4 and IPv6 are both enabled\[char46] +.IP "\fBother_config : subnet\fR: optional string" +Set this to an IPv4 subnet, e\[char46]g\[char46] \fB192\[char46]168\[char46]0\[char46]0/24\fR, to enable \fBovn\-northd\fR to automatically assign IP addresses within that subnet\[char46] +.IP "\fBother_config : exclude_ips\fR: optional string" +To exclude some addresses from automatic IP address management, set this to a list of the IPv4 addresses or \fB\[char46]\[char46]\fR-delimited ranges to exclude\[char46] The addresses or ranges should be a subset of those in \fBother_config:subnet\fR\[char46] +.IP +Whether listed or not, \fBovn\-northd\fR will never allocate the first or last address in a subnet, such as 192\[char46]168\[char46]0\[char46]0 or 192\[char46]168\[char46]0\[char46]255 in 192\[char46]168\[char46]0\[char46]0/24\[char46] +.IP +Examples: +.RS +.IP \(bu +\fB192\[char46]168\[char46]0\[char46]2 192\[char46]168\[char46]0\[char46]10\fR +.IP \(bu +\fB192\[char46]168\[char46]0\[char46]4 192\[char46]168\[char46]0\[char46]30\[char46]\[char46]192\[char46]168\[char46]0\[char46]60 192\[char46]168\[char46]0\[char46]110\[char46]\[char46]192\[char46]168\[char46]0\[char46]120\fR +.IP \(bu +\fB192\[char46]168\[char46]0\[char46]110\[char46]\[char46]192\[char46]168\[char46]0\[char46]120 192\[char46]168\[char46]0\[char46]25\[char46]\[char46]192\[char46]168\[char46]0\[char46]30 192\[char46]168\[char46]0\[char46]144\fR +.RE +.IP "\fBother_config : ipv6_prefix\fR: optional string" +Set this to an IPv6 prefix to enable \fBovn\-northd\fR to automatically assign IPv6 addresses using this prefix\[char46] The assigned IPv6 address will be generated using the IPv6 prefix and the MAC address (converted to an IEEE EUI64 identifier) of the port\[char46] The IPv6 prefix defined here should be a valid IPv6 address ending with \fB::\fR\[char46] +.IP +Examples: +.RS +.IP \(bu +\fBaef0::\fR +.IP \(bu +\fBbef0:1234:a890:5678::\fR +.IP \(bu +\fB8230:5678::\fR +.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 +.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_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] 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] 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" +Number of multicast groups to be stored\[char46] Default: 2048\[char46] +.IP "\fBother_config : mcast_idle_timeout\fR: optional string, containing an integer, in range 15 to 3,600" +Configures the IP Multicast Snooping group idle timeout (in seconds)\[char46] Default: 300 seconds\[char46] +.IP "\fBother_config : mcast_query_interval\fR: optional string, containing an integer, in range 1 to 3,600" +Configures the IP Multicast Querier interval between queries (in seconds)\[char46] Default: \fBother_config:mcast_idle_timeout\fR / 2\[char46] +.IP "\fBother_config : mcast_query_max_response\fR: optional string, containing an integer, in range 1 to 10" +Configures the value of the \(dqmax-response\(dq field in the multicast queries originated by the logical switch\[char46] Default: 1 second\[char46] +.IP "\fBother_config : mcast_eth_src\fR: optional string" +Configures the source Ethernet address for queries originated by the logical switch\[char46] +.IP "\fBother_config : mcast_ip4_src\fR: optional string" +Configures the source IPv4 address for queries originated by the logical switch\[char46] +.IP "\fBother_config : mcast_ip6_src\fR: optional string" +Configures the source IPv6 address for queries originated by the logical switch\[char46] +.ST "Interconnection:" +.PP +.IP "\fBother_config : interconn-ts\fR: optional string" +The \fBname\fR of corresponding transit switch in \fBOVN_IC_Northbound\fR database\[char46] This kind of logical switch is created and controlled by \fBovn\-ic\fR\[char46] +.ST "Tunnel Key:" +.PP +.IP "\fBother_config : requested-tnl-key\fR: optional string, containing an integer, in range 1 to 16,777,215" +Configures the datapath tunnel key for the logical switch\[char46] Usually 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] The typical use case is for interconnection: the tunnel keys for transit switches need to be unique globally, so they are maintained in the global \fBOVN_IC_Southbound\fR database, and \fBovn\-ic\fR simply syncs the value from \fBOVN_IC_Southbound\fR through this config\[char46] +.IP "\fBcopp\fR: optional weak reference to \fBCopp\fR" +The control plane protection policy from table \fBCopp\fR used for metering packets sent to \fBovn\-controller\fR from ports of this logical switch\[char46] +.ST "Other options:" +.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" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "Logical_Switch_Port TABLE" +.PP +.PP +.PP +A port within an L2 logical switch\[char46] +.SS "Summary: +.TQ .25in +\fICore Features:\fR +.RS .25in +.TQ 2.75in +\fBname\fR +string (must be unique within table) +.TQ 2.75in +\fBtype\fR +string +.RE +.TQ .25in +\fIOptions:\fR +.RS .25in +.TQ 2.75in +\fBoptions\fR +map of string-string pairs +.TQ .25in +\fIOptions for router ports:\fR +.RS .25in +.TQ 2.50in +\fBoptions : router-port\fR +optional string +.TQ 2.50in +\fBoptions : nat-addresses\fR +optional string +.TQ 2.50in +\fBoptions : exclude-lb-vips-from-garp\fR +optional string +.TQ 2.50in +\fBoptions : arp_proxy\fR +optional string +.RE +.TQ .25in +\fIOptions for localnet ports:\fR +.RS .25in +.TQ 2.50in +\fBoptions : network_name\fR +optional string +.TQ 2.50in +\fBoptions : ethtype\fR +optional string +.TQ 2.50in +\fBoptions : localnet_learn_fdb\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.RE +.TQ .25in +\fIOptions for l2gateway ports:\fR +.RS .25in +.TQ 2.50in +\fBoptions : network_name\fR +optional string +.TQ 2.50in +\fBoptions : l2gateway-chassis\fR +optional string +.RE +.TQ .25in +\fIOptions for vtep ports:\fR +.RS .25in +.TQ 2.50in +\fBoptions : vtep-physical-switch\fR +optional string +.TQ 2.50in +\fBoptions : vtep-logical-switch\fR +optional string +.RE +.TQ .25in +\fIVMI (or VIF) Options:\fR +.RS .25in +.TQ 2.50in +\fBoptions : requested-chassis\fR +optional string +.TQ 2.50in +\fBoptions : activation-strategy\fR +optional string +.TQ 2.50in +\fBoptions : iface-id-ver\fR +optional string +.TQ 2.50in +\fBoptions : qos_min_rate\fR +optional string +.TQ 2.50in +\fBoptions : qos_max_rate\fR +optional string +.TQ 2.50in +\fBoptions : qos_burst\fR +optional string +.TQ 2.50in +\fBoptions : hostname\fR +optional string +.TQ .25in +\fIVIF Plugging Options:\fR +.RS .25in +.TQ 2.25in +\fBoptions : vif-plug-type\fR +optional string +.TQ 2.25in +\fBoptions : vif-plug-mtu-request\fR +optional string +.RE +.RE +.TQ .25in +\fIVirtual port Options:\fR +.RS .25in +.TQ 2.50in +\fBoptions : virtual-ip\fR +optional string +.TQ 2.50in +\fBoptions : virtual-parents\fR +optional string +.RE +.TQ .25in +\fIIP Multicast Snooping Options:\fR +.RS .25in +.TQ 2.50in +\fBoptions : mcast_flood\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.TQ 2.50in +\fBoptions : mcast_flood_reports\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.RE +.RE +.TQ .25in +\fIContainers:\fR +.RS .25in +.TQ 2.75in +\fBparent_name\fR +optional string +.TQ 2.75in +\fBtag_request\fR +optional integer, in range 0 to 4,095 +.TQ 2.75in +\fBtag\fR +optional integer, in range 1 to 4,095 +.RE +.TQ .25in +\fIPort State:\fR +.RS .25in +.TQ 2.75in +\fBup\fR +optional boolean +.TQ 2.75in +\fBenabled\fR +optional boolean +.RE +.TQ .25in +\fIAddressing:\fR +.RS .25in +.TQ 2.75in +\fBaddresses\fR +set of strings +.TQ 2.75in +\fBdynamic_addresses\fR +optional string +.TQ 2.75in +\fBport_security\fR +set of strings +.RE +.TQ .25in +\fIDHCP:\fR +.RS .25in +.TQ 2.75in +\fBdhcpv4_options\fR +optional weak reference to \fBDHCP_Options\fR +.TQ 2.75in +\fBdhcpv6_options\fR +optional weak reference to \fBDHCP_Options\fR +.RE +.TQ 3.00in +\fBmirror_rules\fR +set of weak reference to \fBMirror\fRs +.TQ 3.00in +\fBha_chassis_group\fR +optional \fBHA_Chassis_Group\fR +.TQ .25in +\fINaming:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids : neutron:port_name\fR +optional string +.RE +.TQ .25in +\fITunnel Key:\fR +.RS .25in +.TQ 2.75in +\fBoptions : requested-tnl-key\fR +optional string, containing an integer, in range 1 to 32,767 +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.ST "Core Features:" +.PP +.IP "\fBname\fR: string (must be unique within table)" +The logical port name\[char46] +.IP +For entities (VMs or containers) that are spawned in the hypervisor, the name used here must match those used in the \fBexternal_ids:iface-id\fR in the \fBOpen_vSwitch\fR database\(cqs \fBInterface\fR table, because hypervisors use \fBexternal_ids:iface-id\fR as a lookup key to identify the network interface of that entity\[char46] +.IP +For containers that share a VIF within a VM, the name can be any unique identifier\[char46] See \fBContainers\fR, below, for more information\[char46] +.IP +A logical switch port may not have the same name as a logical router port, but the database schema cannot enforce this\[char46] +.IP "\fBtype\fR: string" +Specify a type for this logical port\[char46] Logical ports can be used to model other types of connectivity into an OVN logical switch\[char46] The following types are defined: +.RS +.TP +(empty string) +A VM (or VIF) interface\[char46] +.TP +\fBrouter\fR +A connection to a logical router\[char46] The value of \fBoptions:router-port\fR specifies the \fBname\fR of the \fBLogical_Router_Port\fR to which this logical switch port is connected\[char46] +.TP +\fBlocalnet\fR +A connection to a locally accessible network from \fBovn\-controller\fR instances that have a corresponding bridge mapping\[char46] A logical switch can have multiple \fBlocalnet\fR ports attached\[char46] This type is used to model direct connectivity to existing networks\[char46] In this case, each chassis should have a mapping for one of the physical networks only\[char46] Note: nothing said above implies that a chassis cannot be plugged to multiple physical networks as long as they belong to different switches\[char46] +.TP +\fBlocalport\fR +A connection to a local VIF\[char46] Traffic that arrives on a \fBlocalport\fR is never forwarded over a tunnel to another chassis\[char46] These ports are present on every chassis and have the same address in all of them\[char46] This is used to model connectivity to local services that run on every hypervisor\[char46] +.TP +\fBl2gateway\fR +A connection to a physical network\[char46] +.TP +\fBvtep\fR +A port to a logical switch on a VTEP gateway\[char46] +.TP +\fBexternal\fR +Represents a logical port which is external and not having an OVS port in the integration bridge\[char46] \fBOVN\fR will never receive any traffic from this port or send any traffic to this port\[char46] \fBOVN\fR can support native services like DHCPv4/DHCPv6/DNS for this port\[char46] If \fBha_chassis_group\fR is defined, \fBovn\-controller\fR running in the master chassis of the HA chassis group will bind this port to provide these native services\[char46] It is expected that this port belong to a bridged logical switch (with a \fBlocalnet\fR port)\[char46] +.IP +It is recommended to use the same HA chassis group for all the external ports of a logical switch\[char46] Otherwise, the physical switch might see MAC flap issue when different chassis provide the native services\[char46] For example when supporting native DHCPv4 service, DHCPv4 server mac (configured in \fBoptions:server_mac\fR column in table \fBDHCP_Options\fR) originating from different ports can cause MAC flap issue\[char46] 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\[char46] +.IP +Below are some of the use cases where \fBexternal\fR ports can be used\[char46] +.RS +.IP \(bu +VMs connected to SR-IOV nics - Traffic from these VMs by passes the kernel stack and local \fBovn\-controller\fR do not bind these ports and cannot serve the native services\[char46] +.IP \(bu +When CMS supports provisioning baremetal servers\[char46] +.RE +.TP +\fBvirtual\fR +Represents a logical port which does not have an OVS port in the integration bridge and has a virtual ip configured in the \fBoptions:virtual-ip\fR column\[char46] This virtual ip can move around between the logical ports configured in the \fBoptions:virtual-parents\fR column\[char46] +.IP +One of the use case where \fBvirtual\fR ports can be used is\[char46] +.RS +.IP \(bu +The \fBvirtual ip\fR represents a load balancer vip and the \fBvirtual parents\fR provide load balancer service in an active-standby setup with the active virtual parent owning the \fBvirtual ip\fR\[char46] +.RE +.TP +\fBremote\fR +A remote port is to model a port that resides remotely on another OVN, which is on the other side of a transit logical switch for OVN interconnection\[char46] This type of ports are created by \fBovn\-ic\fR instead of by CMS\[char46] Any change to the port will be automatically overwritten by \fBovn\-ic\fR\[char46] +.RE +.ST "Options:" +.PP +.IP "\fBoptions\fR: map of string-string pairs" +This column provides key/value settings specific to the logical port \fBtype\fR\[char46] The type-specific options are described individually below\[char46] +.ST "Options for router ports:" +.PP +.PP +.PP +These options apply when \fBtype\fR is \fBrouter\fR\[char46] +.IP "\fBoptions : router-port\fR: optional string" +Required\[char46] The \fBname\fR of the \fBLogical_Router_Port\fR to which this logical switch port is connected\[char46] +.IP "\fBoptions : nat-addresses\fR: optional string" +This is used to send gratuitous ARPs for SNAT and DNAT IP addresses via the \fBlocalnet\fR port that is attached to the same logical switch as this type \fBrouter\fR port\[char46] 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\[char46] +.IP +This must take one of the following forms: +.RS +.TP +\fBrouter\fR +Gratuitous ARPs will be sent for all SNAT and DNAT external IP addresses and for all load balancer IP addresses defined on the \fBoptions:router-port\fR\(cqs logical router, using the \fBoptions:router-port\fR\(cqs MAC address\[char46] +.IP +This form of \fBoptions:nat-addresses\fR is valid for logical switch ports where \fBoptions:router-port\fR is the name of a port on a gateway router, or the name of a distributed gateway port\[char46] +.IP +Supported only in OVN 2\[char46]8 and later\[char46] Earlier versions required NAT addresses to be manually synchronized\[char46] +.TP +\fBEthernet address followed by one or more IPv4 addresses\fR +Example: \fB80:fa:5b:06:72:b7 158\[char46]36\[char46]44\[char46]22 +158\[char46]36\[char46]44\[char46]24\fR\[char46] This would result in generation of gratuitous ARPs for IP addresses 158\[char46]36\[char46]44\[char46]22 and 158\[char46]36\[char46]44\[char46]24 with a MAC address of 80:fa:5b:06:72:b7\[char46] +.IP +This form of \fBoptions:nat-addresses\fR is only valid for logical switch ports where \fBoptions:router-port\fR is the name of a port on a gateway router\[char46] +.RE +.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 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] +.ST "Options for localnet ports:" +.PP +.PP +.PP +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]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:" +.PP +.PP +.PP +These options apply when \fBtype\fR is \fBl2gateway\fR\[char46] +.IP "\fBoptions : network_name\fR: optional string" +Required\[char46] The name of the network to which the \fBl2gateway\fR port is connected\[char46] The L2 gateway, via \fBovn\-controller\fR, uses its local configuration to determine exactly how to connect to this network\[char46] +.IP "\fBoptions : l2gateway-chassis\fR: optional string" +Required\[char46] The chassis on which the \fBl2gateway\fR logical port should be bound to\[char46] \fBovn\-controller\fR running on the defined chassis will connect this logical port to the physical network\[char46] +.ST "Options for vtep ports:" +.PP +.PP +.PP +These options apply when \fBtype\fR is \fBvtep\fR\[char46] +.IP "\fBoptions : vtep-physical-switch\fR: optional string" +Required\[char46] The name of the VTEP gateway\[char46] +.IP "\fBoptions : vtep-logical-switch\fR: optional string" +Required\[char46] A logical switch name connected by the VTEP gateway\[char46] +.ST "VMI (or VIF) Options:" +.PP +.PP +.PP +These options apply to logical ports with \fBtype\fR having (empty string) +.IP "\fBoptions : requested-chassis\fR: optional string" +If set, identifies a specific chassis (by name or hostname) that is allowed to bind this port\[char46] Using this option will prevent thrashing between two chassis trying to bind the same port during a live migration\[char46] It can also prevent similar thrashing due to a mis-configuration, if a port is accidentally created on more than one chassis\[char46] +.IP +If set to a comma separated list, the first entry identifies the main chassis and the rest are one or more additional chassis that are allowed to bind the same port\[char46] +.IP +When multiple chassis are set for the port, and the logical switch is connected to an external network through a \fBlocalnet\fR port, tunneling is enforced for the port to guarantee delivery of packets directed to the port to all its locations\[char46] This has MTU implications because the network used for tunneling must have MTU larger than \fBlocalnet\fR for stable connectivity\[char46] +.IP +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\[char46] It is advised that chassis names - and not host names - are used for this option\[char46] +.IP "\fBoptions : activation-strategy\fR: optional string" +If used with multiple chassis set in \fBrequested-chassis\fR, specifies an activation strategy for all additional chassis\[char46] By default, no activation strategy is used, meaning additional port locations are immediately available for use\[char46] When set to \(dqrarp\(dq, the port is blocked for ingress and egress communication until a RARP packet is sent from a new location\[char46] The \(dqrarp\(dq strategy is useful in live migration scenarios for virtual machines\[char46] +.IP "\fBoptions : iface-id-ver\fR: optional string" +If set, this port will be bound by \fBovn\-controller\fR only if this same key and value is configured in the \fBexternal_ids\fR column in the Open_vSwitch database\(cqs \fBInterface\fR table\[char46] +.IP "\fBoptions : qos_min_rate\fR: optional string" +If set, indicates the minimum guaranteed rate available for data sent from this interface, in bit/s\[char46] +.IP "\fBoptions : qos_max_rate\fR: optional string" +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 : hostname\fR: optional string" +If set, indicates the DHCPv4 option \(dqHostname\(dq (option code 12) associated for this Logical Switch Port\[char46] If DHCPv4 is enabled for this Logical Switch Port, hostname dhcp option will be included in DHCP reply\[char46] +.ST "VIF Plugging Options:" +.PP +.IP "\fBoptions : vif-plug-type\fR: optional string" +If set, OVN will attempt to perform plugging of this VIF\[char46] In order to get this port plugged by the OVN controller, OVN must be built with support for VIF plugging\[char46] The default behavior is for the CMS to do the VIF plugging\[char46] Each VIF plug provider have their own options namespaced by name, for example \(dqvif-plug:representor:key\(dq\[char46] Please refer to the VIF plug provider documentation located in Documentation/topics/vif-plug-providers/ for more information\[char46] +.IP "\fBoptions : vif-plug-mtu-request\fR: optional string" +Requested MTU for plugged interfaces\[char46] When set the OVN controller will fill the \fBmtu_request\fR column of the Open vSwitch database\(cqs \fBInterface\fR table\[char46] This in turn will make OVS vswitchd update the MTU of the linked interface\[char46] +.ST "Virtual port Options:" +.PP +.PP +.PP +These options apply when \fBtype\fR is \fBvirtual\fR\[char46] +.IP "\fBoptions : virtual-ip\fR: optional string" +This option represents the virtual IPv4 address\[char46] +.IP "\fBoptions : virtual-parents\fR: optional string" +This options represents a set of logical port names (with in the same logical switch) which can own the \fBvirtual ip\fR configured in the \fBoptions:virtual-ip\fR\[char46] All these virtual parents should add the \fBvirtual ip\fR in the \fBport_security\fR if port security addressed are enabled\[char46] +.ST "IP Multicast Snooping Options:" +.PP +.PP +.PP +These options apply when the port is part of a logical switch which has \fBother_config\fR :mcast_snoop set to \fBtrue\fR\[char46] +.IP "\fBoptions : mcast_flood\fR: optional string, either \fBtrue\fR or \fBfalse\fR" +If set to \fBtrue\fR, multicast packets (except reports) are unconditionally forwarded to the specific port\[char46] Default: \fBfalse\fR\[char46] +.IP "\fBoptions : mcast_flood_reports\fR: optional string, either \fBtrue\fR or \fBfalse\fR" +If set to \fBtrue\fR, multicast reports are unconditionally forwarded to the specific port\[char46] Default: \fBfalse\fR\[char46] +.ST "Containers:" +.PP +.PP +.PP +When a large number of containers are nested within a VM, it may be too expensive to dedicate a VIF to each container\[char46] OVN can use VLAN tags to support such cases\[char46] Each container is assigned a VLAN ID and each packet that passes between the hypervisor and the VM is tagged with the appropriate ID for the container\[char46] Such VLAN IDs never appear on a physical wire, even inside a tunnel, so they need not be unique except relative to a single VM on a hypervisor\[char46] +.PP +.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] +.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 +When \fBtype\fR is set to \fBlocalnet\fR or \fBl2gateway\fR, this can be set to indicate that the port represents a connection to a specific VLAN on a locally accessible network\[char46] The VLAN ID is used to match incoming traffic and is also added to outgoing traffic\[char46] +.IP "\fBtag\fR: optional integer, in range 1 to 4,095" +The VLAN tag allocated by \fBovn\-northd\fR based on the contents of the \fBtag_request\fR column\[char46] +.ST "Port State:" +.PP +.IP "\fBup\fR: optional boolean" +This column is populated by \fBovn\-northd\fR, rather than by the CMS plugin as is most of this database\[char46] When a logical port is bound to a physical location in the OVN Southbound database \fBBinding\fR table, \fBovn\-northd\fR sets this column to \fBtrue\fR; otherwise, or if the port becomes unbound later, it sets it to \fBfalse\fR\[char46] If this column is empty, the port is not considered up\[char46] This allows the CMS to wait for a VM\(cqs (or container\(cqs) networking to become active before it allows the VM (or container) to start\[char46] +.IP +Logical ports of router type are an exception to this rule\[char46] They are considered to be always up, that is this column is always set to \fBtrue\fR\[char46] +.IP "\fBenabled\fR: optional boolean" +This column is used to administratively set port state\[char46] If this column is empty or is set to \fBtrue\fR, the port is enabled\[char46] If this column is set to \fBfalse\fR, the port is disabled\[char46] A disabled port has all ingress and egress traffic dropped\[char46] +.ST "Addressing:" +.PP +.IP "\fBaddresses\fR: set of strings" +Addresses owned by the logical port\[char46] +.IP +Each element in the set must take one of the following forms: +.RS +.TP +\fBEthernet address followed by zero or more IPv4 or IPv6 addresses (or both)\fR +An Ethernet address defined is owned by the logical port\[char46] Like a physical Ethernet NIC, a logical port ordinarily has a single fixed Ethernet address\[char46] +.IP +When a OVN logical switch processes a unicast Ethernet frame whose destination MAC address is in a logical port\(cqs \fBaddresses\fR column, it delivers it only to that port, as if a MAC learning process had learned that MAC address on the port\[char46] +.IP +If IPv4 or IPv6 address(es) (or both) are defined, it indicates that the logical port owns the given IP addresses\[char46] +.IP +If IPv4 address(es) are defined, the OVN logical switch uses this information to synthesize responses to ARP requests without traversing the physical network\[char46] The OVN logical router connected to the logical switch, if any, uses this information to avoid issuing ARP requests for logical switch ports\[char46] +.IP +Note that the order here is important\[char46] The Ethernet address must be listed before the IP address(es) if defined\[char46] +.IP +Examples: +.RS +.TP +\fB80:fa:5b:06:72:b7\fR +This indicates that the logical port owns the above mac address\[char46] +.TP +\fB80:fa:5b:06:72:b7 10\[char46]0\[char46]0\[char46]4 20\[char46]0\[char46]0\[char46]4\fR +This indicates that the logical port owns the mac address and two IPv4 addresses\[char46] +.TP +\fB80:fa:5b:06:72:b7 fdaa:15f2:72cf:0:f816:3eff:fe20:3f41\fR +This indicates that the logical port owns the mac address and 1 IPv6 address\[char46] +.TP +\fB80:fa:5b:06:72:b7 10\[char46]0\[char46]0\[char46]4 fdaa:15f2:72cf:0:f816:3eff:fe20:3f41\fR +This indicates that the logical port owns the mac address and 1 IPv4 address and 1 IPv6 address\[char46] +.RE +.TP +\fBunknown\fR +This indicates that the logical port has an unknown set of Ethernet addresses\[char46] When an OVN logical switch processes a unicast Ethernet frame whose destination MAC address is not in any logical port\(cqs \fBaddresses\fR column, it delivers it to the port (or ports) whose \fBaddresses\fR columns include \fBunknown\fR\[char46] +.TP +\fBdynamic\fR +Use \fBdynamic\fR to make \fBovn\-northd\fR generate a globally unique MAC address, choose an unused IPv4 address with the logical port\(cqs subnet (if \fBother_config:subnet\fR is set in the port\(cqs \fBLogical_Switch\fR), and generate an IPv6 address from the MAC address (if \fBother_config:ipv6_prefix\fR is set in the port\(cqs \fBLogical_Switch\fR) and store them in the port\(cqs \fBdynamic_addresses\fR column\[char46] +.IP +Only one element containing \fBdynamic\fR may appear in \fBaddresses\fR\[char46] +.TP +\fBdynamic\fR \fIip\fR +.TQ .5in +\fBdynamic\fR \fIipv6\fR +.TQ .5in +\fBdynamic\fR \fIip\fR \fIipv6\fR +These act like \fBdynamic\fR alone but specify particular IPv4 or IPv6 addresses to use\[char46] OVN IPAM will still automatically allocate the other address if configured appropriately\[char46] Example: \fBdynamic 192\[char46]168\[char46]0\[char46]1 2001::1\fR\[char46] +.TP +\fImac\fR \fBdynamic\fR +This acts like \fBdynamic\fR alone but specifies a particular MAC address to use\[char46] OVN IPAM will still automatically allocate IPv4 or IPv6 addresses, or both, if configured appropriately\[char46] Example: \fB80:fa:5b:06:72:b7 dynamic\fR +.TP +\fBrouter\fR +Accepted only when \fBtype\fR is \fBrouter\fR\[char46] 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 \fBrouter\-port\fR in \fBoptions\fR\[char46] +.IP +The resulting addresses are used to populate the logical switch\(cqs destination lookup, and also for the logical switch to generate ARP and ND replies\[char46] +.IP +If the connected logical router port has a distributed gateway port specified and the logical router has rules specified in \fBnat\fR with \fBexternal_mac\fR, then those addresses are also used to populate the switch\(cqs destination lookup\[char46] +.IP +Supported only in OVN 2\[char46]7 and later\[char46] Earlier versions required router addresses to be manually synchronized\[char46] +.RE +.IP "\fBdynamic_addresses\fR: optional string" +Addresses assigned to the logical port by \fBovn\-northd\fR, if \fBdynamic\fR is specified in \fBaddresses\fR\[char46] Addresses will be of the same format as those that populate the \fBaddresses\fR column\[char46] Note that dynamically assigned addresses are constructed and managed locally in ovn-northd, so they cannot be reconstructed in the event that the database is lost\[char46] +.IP "\fBport_security\fR: set of strings" +This column controls the addresses from which the host attached to the logical port (``the host\(cq\(cq) is allowed to send packets and to which it is allowed to receive packets\[char46] If this column is empty, all addresses are permitted\[char46] +.IP +Each element in the set must begin with one Ethernet address\[char46] This would restrict the host to sending packets from and receiving packets to the ethernet addresses defined in the logical port\(cqs \fBport_security\fR column\[char46] It also restricts the inner source MAC addresses that the host may send in ARP and IPv6 Neighbor Discovery packets\[char46] The host is always allowed to receive packets to multicast and broadcast Ethernet addresses\[char46] +.IP +Each element in the set may additionally contain one or more IPv4 or IPv6 addresses (or both), with optional masks\[char46] If a mask is given, it must be a CIDR mask\[char46] In addition to the restrictions 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\[char46] 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\[char46] In addition: +.RS +.IP \(bu +If any IPv4 address is given, the host is also allowed to receive packets to the IPv4 local broadcast address 255\[char46]255\[char46]255\[char46]255 and to IPv4 multicast addresses (224\[char46]0\[char46]0\[char46]0/4)\[char46] If an IPv4 address with a mask is given, the host is also allowed to receive packets to the broadcast address in that specified subnet\[char46] +.IP +If any IPv4 address is given, the host is additionally restricted to sending ARP packets with the specified source IPv4 address\[char46] (RARP is not restricted\[char46]) +.IP \(bu +If any IPv6 address is given, the host is also allowed to receive packets to IPv6 multicast addresses (ff00::/8)\[char46] +.IP +If any IPv6 address is given, the host is additionally restricted to sending IPv6 Neighbor Discovery Solicitation or Advertisement packets with the specified source address or, for solicitations, the unspecified address\[char46] +.RE +.IP +If an element includes an IPv4 address, but no IPv6 addresses, then IPv6 traffic is not allowed\[char46] If an element includes an IPv6 address, but no IPv4 address, then IPv4 and ARP traffic is not allowed\[char46] +.IP +This column uses the same lexical syntax as the \fBmatch\fR column in the OVN Southbound database\(cqs \fBPipeline\fR table\[char46] Multiple addresses within an element may be space or comma separated\[char46] +.IP +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 \fBACL\fR table\[char46] +.IP +Examples: +.RS +.TP +\fB80:fa:5b:06:72:b7\fR +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\[char46] The host may not send ARP or IPv6 Neighbor Discovery packets with inner source Ethernet addresses other than the one specified\[char46] +.TP +\fB80:fa:5b:06:72:b7 192\[char46]168\[char46]1\[char46]10/24\fR +This adds further restrictions to the first example\[char46] The host may send IPv4 packets from or receive IPv4 packets to only 192\[char46]168\[char46]1\[char46]10, except that it may also receive IPv4 packets to 192\[char46]168\[char46]1\[char46]255 (based on the subnet mask), 255\[char46]255\[char46]255\[char46]255, and any address in 224\[char46]0\[char46]0\[char46]0/4\[char46] 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\[char46]168\[char46]1\[char46]10\[char46] The host may not send or receive any IPv6 (including IPv6 Neighbor Discovery) traffic\[char46] +.TP +\fB\(dq80:fa:5b:12:42:ba\(dq, \(dq80:fa:5b:06:72:b7 192\[char46]168\[char46]1\[char46]10/24\(dq\fR +The host may send traffic from and receive traffic to the specified MAC addresses, and to receive traffic to Ethernet multicast and broadcast addresses, but not otherwise\[char46] With MAC 80:fa:5b:12:42:ba, the host may send traffic from and receive traffic to any L3 address\[char46] With MAC 80:fa:5b:06:72:b7, the host may send IPv4 packets from or receive IPv4 packets to only 192\[char46]168\[char46]1\[char46]10, except that it may also receive IPv4 packets to 192\[char46]168\[char46]1\[char46]255 (based on the subnet mask), 255\[char46]255\[char46]255\[char46]255, and any address in 224\[char46]0\[char46]0\[char46]0/4\[char46] The host may not send or receive any IPv6 (including IPv6 Neighbor Discovery) traffic\[char46] +.RE +.ST "DHCP:" +.PP +.IP "\fBdhcpv4_options\fR: optional weak reference to \fBDHCP_Options\fR" +This column defines the DHCPv4 Options to be included by the \fBovn\-controller\fR when it replies to the DHCPv4 requests\[char46] Please see the \fBDHCP_Options\fR table\[char46] +.IP "\fBdhcpv6_options\fR: optional weak reference to \fBDHCP_Options\fR" +This column defines the DHCPv6 Options to be included by the \fBovn\-controller\fR when it replies to the DHCPv6 requests\[char46] Please see the \fBDHCP_Options\fR table\[char46] +.IP "\fBmirror_rules\fR: set of weak reference to \fBMirror\fRs" +Mirror rules that apply to logical switch port which is the source\[char46] Please see the \fBMirror\fR table\[char46] +.IP "\fBha_chassis_group\fR: optional \fBHA_Chassis_Group\fR" +References a row in the OVN Northbound database\(cqs \fBHA_Chassis_Group\fR table\[char46] It indicates the HA chassis group to use if the \fBtype\fR is set to \fBexternal\fR\[char46] If \fBtype\fR is not \fBexternal\fR, this column is ignored\[char46] +.ST "Naming:" +.PP +.IP "\fBexternal_ids : neutron:port_name\fR: optional string" +This column gives an optional human-friendly name for the port\[char46] This name has no special meaning or purpose other than to provide convenience for human interaction with the northbound database\[char46] +.IP +Neutron copies this from its own port object\(cqs name\[char46] (Neutron ports do are not assigned human-friendly names by default, so it will often be empty\[char46]) +.ST "Tunnel Key:" +.PP +.IP "\fBoptions : requested-tnl-key\fR: optional string, containing an integer, in range 1 to 32,767" +Configures the port binding tunnel key for the port\[char46] Usually this is not needed because \fBovn\-northd\fR will assign an unique key for each port by itself\[char46] However, if it is configured, \fBovn\-northd\fR honors the configured value\[char46] 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 \fBOVN_IC_Southbound\fR database, and \fBovn\-ic\fR simply syncs the value from \fBOVN_IC_Southbound\fR through this config\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +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] +.bp +.SH "Forwarding_Group TABLE" +.PP +.PP +.PP +Each row represents one forwarding group\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string +.TQ 3.00in +\fBvip\fR +string +.TQ 3.00in +\fBvmac\fR +string +.TQ 3.00in +\fBliveness\fR +boolean +.TQ 3.00in +\fBchild_port\fR +set of 1 or more strings +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBname\fR: string" +A name for the forwarding group\[char46] This name has no special meaning or purpose other than to provide convenience for human interaction with the ovn-nb database\[char46] +.IP "\fBvip\fR: string" +The virtual IP address assigned to the forwarding group\[char46] It will respond with vmac when an ARP request is sent for vip\[char46] +.IP "\fBvmac\fR: string" +The virtual MAC address assigned to the forwarding group\[char46] +.IP "\fBliveness\fR: boolean" +If set to \fBtrue\fR, liveness is enabled for child ports otherwise it is disabled\[char46] +.IP "\fBchild_port\fR: set of 1 or more strings" +List of child ports in the forwarding group\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "Address_Set TABLE" +.PP +.PP +.PP +Each row in this table represents a named set of addresses\[char46] An address set may contain Ethernet, IPv4, or IPv6 addresses with optional bitwise or CIDR masks\[char46] Address set may ultimately be used in ACLs to compare against fields such as \fBip4\[char46]src\fR or \fBip6\[char46]src\fR\[char46] A single address set must contain addresses of the same type\[char46] As an example, the following would create an address set with three IP addresses: +.PP +.nf +\fB +.br +\fB ovn\-nbctl create Address_Set name=set1 addresses=\(cq10\[char46]0\[char46]0\[char46]1 10\[char46]0\[char46]0\[char46]2 10\[char46]0\[char46]0\[char46]3\(cq +.br +\fB \fR +.fi +.PP +.PP +Address sets may be used in the \fBmatch\fR column of the \fBACL\fR table\[char46] For syntax information, see the details of the expression language used for the \fBmatch\fR column in the \fBLogical_Flow\fR table of the \fBOVN_Southbound\fR database\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBaddresses\fR +set of strings +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBname\fR: string (must be unique within table)" +A name for the address set\[char46] Names are ASCII and must match \fB[a\-zA\-Z_\[char46]][a\-zA\-Z_\[char46]0\-9]*\fR\[char46] +.IP "\fBaddresses\fR: set of strings" +The set of addresses in string form\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "Port_Group TABLE" +.PP +.PP +.PP +Each row in this table represents a named group of logical switch ports\[char46] +.PP +.PP +Port groups may be used in the \fBmatch\fR column of the \fBACL\fR table\[char46] For syntax information, see the details of the expression language used for the \fBmatch\fR column in the \fBLogical_Flow\fR table of the \fBOVN_Southbound\fR database\[char46] +.PP +.PP +For each port group, there are two address sets generated to the \fBAddress_Set\fR table of the \fBOVN_Southbound\fR database, containing the IP addresses of the group of ports, one for IPv4, and the other for IPv6, with \fBname\fR being the \fBname\fR of the \fBPort_Group\fR followed by a suffix \fB_ip4\fR for IPv4 and \fB_ip6\fR for IPv6\[char46] The generated address sets can be used in the same way as regular address sets in the \fBmatch\fR column of the \fBACL\fR table\[char46] For syntax information, see the details of the expression language used for the \fBmatch\fR column in the \fBLogical_Flow\fR table of the \fBOVN_Southbound\fR database\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBports\fR +set of weak reference to \fBLogical_Switch_Port\fRs +.TQ 3.00in +\fBacls\fR +set of \fBACL\fRs +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBname\fR: string (must be unique within table)" +A name for the port group\[char46] Names are ASCII and must match \fB[a\-zA\-Z_\[char46]][a\-zA\-Z_\[char46]0\-9]*\fR\[char46] +.IP "\fBports\fR: set of weak reference to \fBLogical_Switch_Port\fRs" +The logical switch ports belonging to the group in uuids\[char46] +.IP "\fBacls\fR: set of \fBACL\fRs" +Access control rules that apply to the port group\[char46] Applying an ACL to a port group has the same effect as applying the ACL to all logical lswitches that the ports of the port group belong to\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "Load_Balancer TABLE" +.PP +.PP +.PP +Each row represents one load balancer\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string +.TQ 3.00in +\fBvips\fR +map of string-string pairs +.TQ 3.00in +\fBprotocol\fR +optional string, one of \fBsctp\fR, \fBtcp\fR, or \fBudp\fR +.TQ .25in +\fIHealth Checks:\fR +.RS .25in +.TQ 2.75in +\fBhealth_check\fR +set of \fBLoad_Balancer_Health_Check\fRs +.TQ 2.75in +\fBip_port_mappings\fR +map of string-string pairs +.RE +.TQ 3.00in +\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 +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.TQ .25in +\fILoad_Balancer options:\fR +.RS .25in +.TQ 2.75in +\fBoptions : reject\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.TQ 2.75in +\fBoptions : hairpin_snat_ip\fR +optional string +.TQ 2.75in +\fBoptions : skip_snat\fR +optional string +.TQ 2.75in +\fBoptions : add_route\fR +optional string +.TQ 2.75in +\fBoptions : neighbor_responder\fR +optional string +.TQ 2.75in +\fBoptions : template\fR +optional string +.TQ 2.75in +\fBoptions : address-family\fR +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" +A name for the load balancer\[char46] This name has no special meaning or purpose other than to provide convenience for human interaction with the ovn-nb database\[char46] +.IP "\fBvips\fR: map of string-string pairs" +A map of virtual IP addresses (and an optional port number with \fB:\fR as a separator) associated with this load balancer and their corresponding endpoint IP addresses (and optional port numbers with \fB:\fR as separators) separated by commas\[char46] 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\[char46] 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\[char46] If specifying an IPv6 address with a port, the address portion must be enclosed in square brackets\[char46] Examples for keys are \(dq192\[char46]168\[char46]1\[char46]4\(dq and \(dq[fd0f::1]:8800\(dq\[char46] Examples for value are \(dq10\[char46]0\[char46]0\[char46]1, 10\[char46]0\[char46]0\[char46]2\(dq and \(dq20\[char46]0\[char46]0\[char46]10:8800, 20\[char46]0\[char46]0\[char46]11:8800\(dq\[char46] +.IP +When the \fBLoad_Balancer\fR is added to the \fBlogical_switch\fR, the VIP has to be in a different subnet than the one used for the \fBlogical_switch\fR\[char46] Since VIP is in a different subnet, you should connect your logical switch to either a OVN logical router or a real router (this is because the client can now send a packet with VIP as the destination IP address and router\(cqs mac address as the destination MAC address)\[char46] +.IP "\fBprotocol\fR: optional string, one of \fBsctp\fR, \fBtcp\fR, or \fBudp\fR" +Valid protocols are \fBtcp\fR, \fBudp\fR, or \fBsctp\fR\[char46] This column is useful when a port number is provided as part of the \fBvips\fR column\[char46] If this column is empty and a port number is provided as part of \fBvips\fR column, OVN assumes the protocol to be \fBtcp\fR\[char46] +.ST "Health Checks:" +.PP +.PP +.PP +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] 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 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] +.IP +CMS can choose the \fBhash\fR selection method by setting the selection fields in this column\[char46] \fBovs\-vswitchd\fR uses the specified fields in generating the hash\[char46] +.IP +\fBdp_hash\fR selection method uses the assistance of datapath to calculate the hash and it is expected to be faster than \fBhash\fR selection method\[char46] So CMS should take this into consideration before using the \fBhash\fR method\[char46] Please consult the OVS documentation and OVS sources for the implementation details\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.ST "Load_Balancer options:" +.PP +.IP "\fBoptions : reject\fR: optional string, either \fBtrue\fR or \fBfalse\fR" +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 "\fBoptions : hairpin_snat_ip\fR: optional string" +IP to be used as source IP for packets that have been hair-pinned after load balancing\[char46] The default behavior when the option is not set is to use the load balancer VIP as source IP\[char46] This option may have exactly one IPv4 and/or one IPv6 address on it, separated by a space character\[char46] +.IP "\fBoptions : skip_snat\fR: optional string" +If the load balancing rule is configured with \fBskip_snat\fR option, the option lb_force_snat_ip configured for the logical router that references this load balancer will not be applied for this load balancer\[char46] +.IP "\fBoptions : add_route\fR: optional string" +If set to \fBtrue\fR, then neighbor routers will have logical flows added that will allow for routing to the VIP IP\[char46] It also will have ARP resolution logical flows added\[char46] By setting this option, it means there is no reason to create a \fBLogical_Router_Static_Route\fR from neighbor routers to this NAT address\[char46] It also means that no ARP request is required for neighbor routers to learn the IP-MAC mapping for this VIP IP\[char46] For more information about what flows are added for IP routes, please see the \fBovn\-northd\fR manpage section on IP Routing\[char46] +.IP "\fBoptions : neighbor_responder\fR: optional string" +If set to \fBall\fR, then routers on which the load balancer is applied reply to ARP/neighbor discovery requests for all VIPs of the load balancer\[char46] If set to \fBreachable\fR, then routers on which the load balancer is applied reply to ARP/neighbor discovery requests only for VIPs that are part of a router\(cqs subnet\[char46] If set to \fBnone\fR, then routers on which the load balancer is applied never reply to ARP/neighbor discovery requests for any of the load balancer VIPs\[char46] Load balancers with \fBoptions:template=true\fR do not support \fBreachable\fR as a valid mode\[char46] The default value of this option, if not specified, is \fBreachable\fR for regular load balancers and \fBnone\fR for template load balancers\[char46] +.IP "\fBoptions : template\fR: optional string" +Option to be set to \fBtrue\fR, if the load balancer is a template\[char46] The load balancer VIPs and backends must be using \fBChassis_Template_Var\fR in their definitions\[char46] +.IP +Load balancer template VIP supported formats are: +.IP +.nf +\fB +.br +\fB^VIP_VAR[:^PORT_VAR|:port] +.br +\fB \fR +.fi +.IP +where \fBVIP_VAR\fR and \fBPORT_VAR\fR are keys of the \fBChassis_Template_Var\fR \fBvariables\fR records\[char46] +.IP +Note: The VIP and PORT cannot be combined into a single template variable\[char46] For example, a \fBChassis_Template_Var\fR variable expanding to \fB10\[char46]0\[char46]0\[char46]1:8080\fR is not valid if used as VIP\[char46] +.IP +Load balancer template backend supported formats are: +.IP +.nf +\fB +.br +\fB^BACKEND_VAR1[:^PORT_VAR1|:port],^BACKEND_VAR2[:^PORT_VAR2|:port] +.br +\fB +.br +\fBor +.br +\fB +.br +\fB^BACKENDS_VAR1,^BACKENDS_VAR2 +.br +\fB \fR +.fi +.IP +where \fBBACKEND_VAR1\fR, \fBPORT_VAR1\fR, \fBBACKEND_VAR2\fR, \fBPORT_VAR2\fR, \fBBACKENDS_VAR1\fR and \fBBACKENDS_VAR2\fR are keys of the \fBChassis_Template_Var\fR \fBvariables\fR records\[char46] +.IP "\fBoptions : address-family\fR: optional string" +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 +.PP +.PP +Each row represents a logical grouping of load balancers\[char46] It is up to the CMS to decide the criteria on which load balancers are grouped together\[char46] 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\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBload_balancer\fR +set of weak reference to \fBLoad_Balancer\fRs +.SS "Details: +.IP "\fBname\fR: string (must be unique within table)" +A name for the load balancer group\[char46] This name has no special meaning or purpose other than to provide convenience for human interaction with the ovn-nb database\[char46] +.IP "\fBload_balancer\fR: set of weak reference to \fBLoad_Balancer\fRs" +A set of load balancers\[char46] +.bp +.SH "Load_Balancer_Health_Check TABLE" +.PP +.PP +.PP +Each row represents one load balancer health check\[char46] +.SS "Summary: +.TQ 3.00in +\fBvip\fR +string +.TQ .25in +\fIHealth check options:\fR +.RS .25in +.TQ 2.75in +\fBoptions : interval\fR +optional string, containing an integer +.TQ 2.75in +\fBoptions : timeout\fR +optional string, containing an integer +.TQ 2.75in +\fBoptions : success_count\fR +optional string, containing an integer +.TQ 2.75in +\fBoptions : failure_count\fR +optional string, containing an integer +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBvip\fR: string" +\fBvip\fR whose endpoints should be monitored for health check\[char46] +.ST "Health check options:" +.PP +.IP "\fBoptions : interval\fR: optional string, containing an integer" +The interval, in seconds, between health checks\[char46] +.IP "\fBoptions : timeout\fR: optional string, containing an integer" +The time, in seconds, after which a health check times out\[char46] +.IP "\fBoptions : success_count\fR: optional string, containing an integer" +The number of successful checks after which the endpoint is considered online\[char46] +.IP "\fBoptions : failure_count\fR: optional string, containing an integer" +The number of failure checks after which the endpoint is considered offline\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "ACL TABLE" +.PP +.PP +.PP +Each row in this table represents one ACL rule for a logical switch or a port group that points to it through its \fBacls\fR column\[char46] The \fBaction\fR column for the highest-\fBpriority\fR matching row in this table determines a packet\(cqs treatment\[char46] If no row matches, packets are allowed by default\[char46] (Default-deny treatment is possible: add a rule with \fBpriority\fR 0, \fB1\fR as \fBmatch\fR, and \fBdeny\fR as \fBaction\fR\[char46]) +.SS "Summary: +.TQ 3.00in +\fBlabel\fR +integer, in range 0 to 4,294,967,295 +.TQ 3.00in +\fBpriority\fR +integer, in range 0 to 32,767 +.TQ 3.00in +\fBdirection\fR +string, either \fBfrom\-lport\fR or \fBto\-lport\fR +.TQ 3.00in +\fBmatch\fR +string +.TQ 3.00in +\fBaction\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 +.TQ 2.75in +\fBoptions : apply-after-lb\fR +optional string +.RE +.TQ .25in +\fILogging:\fR +.RS .25in +.TQ 2.75in +\fBlog\fR +boolean +.TQ 2.75in +\fBname\fR +optional string, at most 63 characters long +.TQ 2.75in +\fBseverity\fR +optional string, one of \fBalert\fR, \fBdebug\fR, \fBinfo\fR, \fBnotice\fR, or \fBwarning\fR +.TQ 2.75in +\fBmeter\fR +optional string +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBoptions\fR +map of string-string pairs +.TQ .25in +\fIACL configuration options:\fR +.RS .25in +.TQ 2.50in +\fBoptions : log-related\fR +optional string +.RE +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBlabel\fR: integer, in range 0 to 4,294,967,295" +Associates an identifier with the ACL\[char46] The same value will be written to corresponding connection tracker entry\[char46] The value should be a valid 32-bit unsigned integer\[char46] This value can help in debugging from connection tracker side\[char46] For example, through this \(dqlabel\(dq we can backtrack to the ACL rule which is causing a \(dqleaked\(dq connection\[char46] Connection tracker entries are created only for allowed connections so the label is valid only for allow and allow-related actions\[char46] +.IP "\fBpriority\fR: integer, in range 0 to 32,767" +The ACL rule\(cqs priority\[char46] Rules with numerically higher priority take precedence over those with lower\[char46] If two ACL rules with the same priority both match, then the one actually applied to a packet is undefined\[char46] +.IP +Return traffic from an \fBallow\-related\fR flow is always allowed and cannot be changed through an ACL\[char46] +.IP +\fBallow\-stateless\fR flows always take precedence before stateful ACLs, regardless of their priority\[char46] (Both \fBallow\fR and \fBallow\-related\fR ACLs can be stateful\[char46]) +.IP "\fBdirection\fR: string, either \fBfrom\-lport\fR or \fBto\-lport\fR" +Direction of the traffic to which this rule should apply: +.RS +.IP \(bu +\fBfrom\-lport\fR: Used to implement filters on traffic arriving from a logical port\[char46] These rules are applied to the logical switch\(cqs ingress pipeline\[char46] +.IP \(bu +\fBto\-lport\fR: Used to implement filters on traffic forwarded to a logical port\[char46] These rules are applied to the logical switch\(cqs egress pipeline\[char46] +.RE +.IP "\fBmatch\fR: string" +The packets that the ACL 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 +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, \fBpass\fR, or \fBreject\fR" +The action to take when the ACL rule matches: +.RS +.IP \(bu +\fBallow\-stateless\fR: Always forward the packet in stateless manner, omitting connection tracking mechanism, regardless of other rules defined for the switch\[char46] May require defining additional rules for inbound replies\[char46] For example, 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\[char46] In addition, traffic that matches stateless ACLs will bypass load-balancer DNAT/un-DNAT processing\[char46] Stateful ACLs should be used instead if the traffic is supposed to be load-balanced\[char46] +.IP \(bu +\fBallow\fR: Forward the packet\[char46] It will also send the packets through connection tracking when \fBallow\-related\fR rules exist on the logical switch\[char46] Otherwise, it\(cqs equivalent to \fBallow\-stateless\fR\[char46] +.IP \(bu +\fBallow\-related\fR: Forward the packet and related traffic (e\[char46]g\[char46] inbound replies to an outbound connection)\[char46] +.IP \(bu +\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 +.PP +ACLs options\[char46] +.IP "\fBoptions : apply-after-lb\fR: optional string" +If set to true, the ACL will be applied after load balancing stage\[char46] Supported only for \fBfrom\-lport\fR direction\[char46] +.IP +The main use case of this option is to support ACLs matching on the destination IP address of the packet for the backend IPs of load balancers\[char46] +.IP +\fBOVN\fR will apply the \fBfrom\-lport\fR ACLs in two stages\[char46] ACLs without this option \fBapply\-after\-lb\fR set, will be applied before the load balancer stage and ACLs with this option set will be applied after the load balancer stage\[char46] The priorities are indepedent between these stages and may not be obvious to the CMS\[char46] 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\[char46] +.ST "Logging:" +.PP +.PP +.PP +These columns control whether and how OVN logs packets that match an ACL\[char46] +.IP "\fBlog\fR: boolean" +If set to \fBtrue\fR, packets that match the ACL will trigger a log message on the transport node or nodes that perform ACL processing\[char46] Logging may be combined with any \fBaction\fR\[char46] +.IP +If set to \fBfalse\fR, the remaining columns in this group have no significance\[char46] +.IP "\fBname\fR: optional string, at most 63 characters long" +This name, if it is provided, is included in log records\[char46] It provides the administrator and the cloud management system a way to associate a log record with a particular ACL\[char46] +.IP "\fBseverity\fR: optional string, one of \fBalert\fR, \fBdebug\fR, \fBinfo\fR, \fBnotice\fR, or \fBwarning\fR" +The severity of the ACL\[char46] The severity levels match those of syslog, in decreasing level of severity: \fBalert\fR, \fBwarning\fR, \fBnotice\fR, \fBinfo\fR, or \fBdebug\fR\[char46] When the column is empty, the default is \fBinfo\fR\[char46] +.IP "\fBmeter\fR: optional string" +The name of a meter to rate-limit log messages for the ACL\[char46] The string must match the \fBname\fR column of a row in the \fBMeter\fR table\[char46] By default, log messages are not rate-limited\[char46] In order to ensure that the same \fBMeter\fR rate limits multiple ACL logs separately, set the \fBfair\fR column\[char46] +.ST "Common Columns:" +.PP +.IP "\fBoptions\fR: map of string-string pairs" +This column provides general key/value settings\[char46] The supported options are described individually below\[char46] +.ST "ACL configuration options:" +.PP +.IP "\fBoptions : log-related\fR: optional string" +If set to \fBtrue\fR, then log when reply or related traffic is admitted from a stateful ACL\[char46] In order for this option to function, the \fBlog\fR option must be set to \fBtrue\fR and a \fBlabel\fR must be set, and it must be unique to the ACL\[char46] The label is necessary as it is the only means to associate the reply traffic with the ACL to which it belongs\[char46] It must be unique, because otherwise it is ambiguous which ACL will be matched\[char46] Note: If this option is enabled, an extra flow is installed in order to log the related traffic\[char46] Therefore, if this is enabled on all ACLs, then the total number of flows necessary to log the ACL traffic is doubled, compared to if this option is not enabled\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "Logical_Router TABLE" +.PP +.PP +.PP +Each row represents one L3 logical router\[char46] +.SS "Summary: +.TQ 3.00in +\fBports\fR +set of \fBLogical_Router_Port\fRs +.TQ 3.00in +\fBstatic_routes\fR +set of \fBLogical_Router_Static_Route\fRs +.TQ 3.00in +\fBpolicies\fR +set of \fBLogical_Router_Policy\fRs +.TQ 3.00in +\fBenabled\fR +optional boolean +.TQ 3.00in +\fBnat\fR +set of \fBNAT\fRs +.TQ 3.00in +\fBload_balancer\fR +set of weak reference to \fBLoad_Balancer\fRs +.TQ 3.00in +\fBload_balancer_group\fR +set of \fBLoad_Balancer_Group\fRs +.TQ .25in +\fINaming:\fR +.RS .25in +.TQ 2.75in +\fBname\fR +string +.TQ 2.75in +\fBexternal_ids : neutron:router_name\fR +optional string +.RE +.TQ 3.00in +\fBcopp\fR +optional weak reference to \fBCopp\fR +.TQ .25in +\fIOptions:\fR +.RS .25in +.TQ 2.75in +\fBoptions : chassis\fR +optional string +.TQ 2.75in +\fBoptions : dnat_force_snat_ip\fR +optional string +.TQ 2.75in +\fBoptions : lb_force_snat_ip\fR +optional string +.TQ 2.75in +\fBoptions : mcast_relay\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.TQ 2.75in +\fBoptions : dynamic_neigh_routers\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.TQ 2.75in +\fBoptions : always_learn_from_arp_request\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.TQ 2.75in +\fBoptions : requested-tnl-key\fR +optional string, containing an integer, in range 1 to 16,777,215 +.TQ 2.75in +\fBoptions : snat-ct-zone\fR +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 +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBports\fR: set of \fBLogical_Router_Port\fRs" +The router\(cqs ports\[char46] +.IP "\fBstatic_routes\fR: set of \fBLogical_Router_Static_Route\fRs" +Zero or more static routes for the router\[char46] +.IP "\fBpolicies\fR: set of \fBLogical_Router_Policy\fRs" +Zero or more routing policies for the router\[char46] +.IP "\fBenabled\fR: optional boolean" +This column is used to administratively set router state\[char46] If this column is empty or is set to \fBtrue\fR, the router is enabled\[char46] If this column is set to \fBfalse\fR, the router is disabled\[char46] A disabled router has all ingress and egress traffic dropped\[char46] +.IP "\fBnat\fR: set of \fBNAT\fRs" +One or more NAT rules for the router\[char46] NAT rules only work on Gateway routers, and on distributed routers with one and only one distributed gateway port\[char46] +.IP "\fBload_balancer\fR: set of weak reference to \fBLoad_Balancer\fRs" +Set of load balancers associated to this logical router\[char46] Load balancer Load balancer rules only work on the Gateway routers or routers with one and only one distributed gateway port\[char46] +.IP "\fBload_balancer_group\fR: set of \fBLoad_Balancer_Group\fRs" +Set of load balancers groups associated to this logical router\[char46] +.ST "Naming:" +.PP +.PP +.PP +These columns provide names for the logical router\[char46] From OVN\(cqs perspective, these names have no special meaning or purpose other than to provide convenience for human interaction with the northbound database\[char46] There is no requirement for the name to be unique\[char46] (For a unique identifier for a logical router, use its row UUID\[char46]) +.PP +.PP +(Originally, \fBname\fR 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 \fBneutron\-\fIuuid\fB\fR\[char46] Later on, Neutron started propagating the friendly name of a router as \fBexternal_ids:neutron:router_name\fR\[char46] Perhaps this can be cleaned up someday\[char46]) +.IP "\fBname\fR: string" +A name for the logical router\[char46] +.IP "\fBexternal_ids : neutron:router_name\fR: optional string" +Another name for the logical router\[char46] +.IP "\fBcopp\fR: optional weak reference to \fBCopp\fR" +The control plane protection policy from table \fBCopp\fR used for metering packets sent to \fBovn\-controller\fR from logical ports of this router\[char46] +.ST "Options:" +.PP +.PP +.PP +Additional options for the logical router\[char46] +.IP "\fBoptions : chassis\fR: optional string" +If set, indicates that the logical router in question is a Gateway router (which is centralized) and resides in the set chassis\[char46] The same value is also used by \fBovn\-controller\fR to uniquely identify the chassis in the OVN deployment and comes from \fBexternal_ids:system\-id\fR in the \fBOpen_vSwitch\fR table of Open_vSwitch database\[char46] +.IP +The Gateway router can only be connected to a distributed router via a switch if SNAT and DNAT are to be configured in the Gateway router\[char46] +.IP "\fBoptions : dnat_force_snat_ip\fR: 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\[char46] When multiple gateway routers are configured, a packet can potentially enter any of the gateway router, get DNATted and eventually reach the logical switch port\[char46] For the return traffic to go back to the same gateway router (for unDNATing), the packet needs a SNAT in the first place\[char46] This can be achieved by setting the above option with a gateway specific set of IP addresses\[char46] This option may have exactly one IPv4 and/or one IPv6 address on it, separated by a a space\[char46] +.IP "\fBoptions : lb_force_snat_ip\fR: optional string" +If set, this option can take two possible type of values\[char46] Either a set of IP addresses or the string value - \fBrouter_ip\fR\[char46] +.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\[char46] 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\[char46] For the return traffic to go back to the same gateway router (for unDNATing), the packet needs a SNAT in the first place\[char46] This can be achieved by setting the above option with a gateway specific set of IP addresses\[char46] This option may have exactly one IPv4 and/or one IPv6 address on it, separated by a space character\[char46] +.IP +If it is configured with the value \fBrouter_ip\fR, then the load balanced packet is SNATed with the IP of router port (attached to the gateway router) selected as the destination after taking the routing decision\[char46] +.IP "\fBoptions : mcast_relay\fR: optional string, either \fBtrue\fR or \fBfalse\fR" +Enables/disables IP multicast relay between logical switches connected to the logical router\[char46] Default: False\[char46] +.IP "\fBoptions : dynamic_neigh_routers\fR: optional string, either \fBtrue\fR or \fBfalse\fR" +If set to \fBtrue\fR, the router will resolve neighbor routers\(cq MAC addresses only by dynamic ARP/ND, instead of prepopulating static mappings for all neighbor routers in the ARP/ND Resolution stage\[char46] This reduces number of flows, but requires ARP/ND messages to resolve the IP-MAC bindings when needed\[char46] It is \fBfalse\fR by default\[char46] It is recommended to set to \fBtrue\fR 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\[char46] By default, ovn-northd does not create mappings to NAT and load balancer addresess\[char46] However, for NAT and load balancer addresses that have the \fBadd_route\fR option added, ovn-northd will create logical flows that map NAT and load balancer IP addresses to the appropriate MAC address\[char46] Setting \fIdynamic_neigh_routers\fR to \fBtrue\fR will prevent the automatic creation of these logical flows\[char46] +.IP "\fBoptions : always_learn_from_arp_request\fR: optional string, either \fBtrue\fR or \fBfalse\fR" +This option controls the behavior when handling IPv4 ARP requests or IPv6 ND-NS packets - whether a dynamic neighbor (MAC binding) entry is added/updated\[char46] +.IP +\fBtrue\fR - Always learn the MAC-IP binding, and add/update the MAC binding entry\[char46] +.IP +\fBfalse\fR - If there is a MAC binding for that IP and the MAC is different, or, if TPA of ARP request belongs to any router port on this router, then update/add that MAC-IP binding\[char46] Otherwise, don\(cqt update/add entries\[char46] +.IP +It is \fBtrue\fR by default\[char46] It is recommended to set to \fBfalse\fR 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, to reduce the size of the MAC binding table\[char46] +.IP "\fBoptions : requested-tnl-key\fR: optional string, containing an integer, in range 1 to 16,777,215" +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] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "QoS TABLE" +.PP +.PP +.PP +Each row in this table represents one QoS rule for a logical switch that points to it through its \fBqos_rules\fR column\[char46] Two types of QoS are supported: DSCP marking and metering\[char46] A \fBmatch\fR with the highest-\fBpriority\fR will have QoS applied to it\[char46] If the \fBaction\fR column is specified, then matching packets will have DSCP marking applied\[char46] If the \fBbandwidth\fR column is specified, then matching packets will have metering applied\[char46] \fBaction\fR and \fBbandwidth\fR are not exclusive, so both marking and metering by defined for the same QoS entry\[char46] If no row matches, packets will not have any QoS applied\[char46] +.SS "Summary: +.TQ 3.00in +\fBpriority\fR +integer, in range 0 to 32,767 +.TQ 3.00in +\fBdirection\fR +string, either \fBfrom\-lport\fR or \fBto\-lport\fR +.TQ 3.00in +\fBmatch\fR +string +.TQ 3.00in +\fBaction\fR +map of string-integer pairs, key must be \fBdscp\fR, value in range 0 to 63 +.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 +.TQ 3.00in +\fBexternal_ids\fR +map of string-string pairs +.SS "Details: +.IP "\fBpriority\fR: integer, in range 0 to 32,767" +The QoS rule\(cqs priority\[char46] Rules with numerically higher priority take precedence over those with lower\[char46] If two QoS rules with the same priority both match, then the one actually applied to a packet is undefined\[char46] +.IP "\fBdirection\fR: string, either \fBfrom\-lport\fR or \fBto\-lport\fR" +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] +.RS +.IP \(bu +\fBdscp\fR: The value of this action should be in the range of 0 to 63 (inclusive)\[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] +.RS +.IP \(bu +\fBrate\fR: The value of rate limit in kbps\[char46] +.IP \(bu +\fBburst\fR: The value of burst rate limit in kilobits\[char46] This is optional and needs to specify the \fBrate\fR\[char46] +.RE +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "Mirror TABLE" +.PP +.PP +.PP +Each row in this table represents a mirror that can be used for port mirroring\[char46] These mirrors are referenced by the \fBmirror_rules\fR column in the \fBLogical_Switch_Port\fR table\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBfilter\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, one of \fBerspan\fR, \fBgre\fR, or \fBlocal\fR +.TQ 3.00in +\fBindex\fR +integer +.TQ 3.00in +\fBexternal_ids\fR +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, 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] 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] 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 +.SH "Meter TABLE" +.PP +.PP +.PP +Each row in this table represents a meter that can be used for QoS or rate-limiting\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBunit\fR +string, either \fBkbps\fR or \fBpktps\fR +.TQ 3.00in +\fBbands\fR +set of 1 or more \fBMeter_Band\fRs +.TQ 3.00in +\fBfair\fR +optional boolean +.TQ 3.00in +\fBexternal_ids\fR +map of string-string pairs +.SS "Details: +.IP "\fBname\fR: string (must be unique within table)" +A name for this meter\[char46] +.IP +Names that begin with \(dq__\(dq (two underscores) are reserved for OVN internal use and should not be added manually\[char46] +.IP "\fBunit\fR: string, either \fBkbps\fR or \fBpktps\fR" +The unit for \fBrate\fR and \fBburst_rate\fR parameters in the \fBbands\fR entry\[char46] \fBkbps\fR specifies kilobits per second, and \fBpktps\fR specifies packets per second\[char46] +.IP "\fBbands\fR: set of 1 or more \fBMeter_Band\fRs" +The bands associated with this meter\[char46] Each band specifies a rate above which the band is to take the action \fBaction\fR\[char46] If multiple bands\(cq rates are exceeded, then the band with the highest rate among the exceeded bands is selected\[char46] +.IP "\fBfair\fR: optional boolean" +This column is used to further describe the desired behavior of the meter when there are multiple references to it\[char46] If this column is empty or is set to \fBfalse\fR, the rate will be shared across all rows that refer to the same Meter \fBname\fR\[char46] Conversely, when this column is set to \fBtrue\fR, each user of the same Meter will be rate-limited on its own\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "Meter_Band TABLE" +.PP +.PP +.PP +Each row in this table represents a meter band which specifies the rate above which the configured action should be applied\[char46] These bands are referenced by the \fBbands\fR column in the \fBMeter\fR table\[char46] +.SS "Summary: +.TQ 3.00in +\fBaction\fR +string, must be \fBdrop\fR +.TQ 3.00in +\fBrate\fR +integer, in range 1 to 4,294,967,295 +.TQ 3.00in +\fBburst_size\fR +integer, in range 0 to 4,294,967,295 +.TQ 3.00in +\fBexternal_ids\fR +map of string-string pairs +.SS "Details: +.IP "\fBaction\fR: string, must be \fBdrop\fR" +The action to execute when this band matches\[char46] The only supported action is \fBdrop\fR\[char46] +.IP "\fBrate\fR: 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 \fBMeter\fR entry\(cqs \fBunit\fR column specified \fBkbps\fR or \fBpktps\fR\[char46] +.IP "\fBburst_size\fR: integer, in range 0 to 4,294,967,295" +The maximum burst allowed for the band in kilobits or packets, depending on whether \fBkbps\fR or \fBpktps\fR was selected in the parent \fBMeter\fR entry\(cqs \fBunit\fR column\[char46] If the size is zero, the switch is free to select some reasonable value depending on its configuration\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "Logical_Router_Port TABLE" +.PP +.PP +.PP +A port within an L3 logical router\[char46] +.PP +.PP +Exactly one \fBLogical_Router\fR row must reference a given logical router port\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBnetworks\fR +set of 1 or more strings +.TQ 3.00in +\fBmac\fR +string +.TQ 3.00in +\fBenabled\fR +optional boolean +.TQ .25in +\fIDistributed Gateway Ports:\fR +.RS .25in +.TQ 2.75in +\fBha_chassis_group\fR +optional \fBHA_Chassis_Group\fR +.TQ 2.75in +\fBgateway_chassis\fR +set of \fBGateway_Chassis\fRes +.TQ .25in +\fIOptions for Physical VLAN MTU Issues:\fR +.RS .25in +.TQ 2.50in +\fBoptions : reside-on-redirect-chassis\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.TQ 2.50in +\fBoptions : redirect-type\fR +optional string, either \fBbridged\fR or \fBoverlay\fR +.RE +.RE +.TQ 3.00in +\fBipv6_prefix\fR +set of strings +.TQ .25in +\fIipv6_ra_configs:\fR +.RS .25in +.TQ 2.75in +\fBipv6_ra_configs : address_mode\fR +optional string +.TQ 2.75in +\fBipv6_ra_configs : router_preference\fR +optional string +.TQ 2.75in +\fBipv6_ra_configs : route_info\fR +optional string +.TQ 2.75in +\fBipv6_ra_configs : mtu\fR +optional string +.TQ 2.75in +\fBipv6_ra_configs : send_periodic\fR +optional string +.TQ 2.75in +\fBipv6_ra_configs : max_interval\fR +optional string +.TQ 2.75in +\fBipv6_ra_configs : min_interval\fR +optional string +.TQ 2.75in +\fBipv6_ra_configs : rdnss\fR +optional string +.TQ 2.75in +\fBipv6_ra_configs : dnssl\fR +optional string +.RE +.TQ .25in +\fIOptions:\fR +.RS .25in +.TQ 2.75in +\fBoptions : mcast_flood\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.TQ 2.75in +\fBoptions : requested-tnl-key\fR +optional string, containing an integer, in range 1 to 32,767 +.TQ 2.75in +\fBoptions : prefix_delegation\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.TQ 2.75in +\fBoptions : prefix\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.TQ 2.75in +\fBoptions : route_table\fR +optional string +.TQ 2.75in +\fBoptions : gateway_mtu\fR +optional string, containing an integer, in range 68 to 65,535 +.TQ 2.75in +\fBoptions : gateway_mtu_bypass\fR +optional string +.RE +.TQ .25in +\fIAttachment:\fR +.RS .25in +.TQ 2.75in +\fBpeer\fR +optional string +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBname\fR: string (must be unique within table)" +A name for the logical router port\[char46] +.IP +In addition to provide convenience for human interaction with the northbound database, this column is used as reference by its patch port in \fBLogical_Switch_Port\fR or another logical router port in \fBLogical_Router_Port\fR\[char46] +.IP +A logical router port may not have the same name as a logical switch port, but the database schema cannot enforce this\[char46] +.IP "\fBnetworks\fR: set of 1 or more strings" +The IP addresses and netmasks of the router\[char46] For example, \fB192\[char46]168\[char46]0\[char46]1/24\fR indicates that the router\(cqs IP address is 192\[char46]168\[char46]0\[char46]1 and that packets destined to 192\[char46]168\[char46]0\[char46]\fIx\fR should be routed to this port\[char46] +.IP +A logical router port always adds a link-local IPv6 address (fe80::/64) automatically generated from the interface\(cqs MAC address using the modified EUI\-64 format\[char46] +.IP "\fBmac\fR: string" +The Ethernet address that belongs to this router port\[char46] +.IP "\fBenabled\fR: optional boolean" +This column is used to administratively set port state\[char46] If this column is empty or is set to \fBtrue\fR, the port is enabled\[char46] If this column is set to \fBfalse\fR, the port is disabled\[char46] A disabled port has all ingress and egress traffic dropped\[char46] +.ST "Distributed Gateway Ports:" +.PP +.PP +.PP +Gateways, as documented under \fBGateways\fR in the OVN architecture guide, provide limited connectivity between logical networks and physical ones\[char46] OVN support multiple kinds of gateways\[char46] The \fBLogical_Router_Port\fR table can be used two different ways to configure \fIdistributed gateway ports\fR, which are one kind of gateway\[char46] These two forms of configuration exist for historical reasons\[char46] Both of them produce the same kind of OVN southbound records and the same behavior in practice\[char46] +.PP +.PP +If either of these are set, this logical router port represents a distributed gateway port that connects this router to a logical switch with a \fBlocalnet\fR port or a connection to another OVN deployment\[char46] +.PP +.PP +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\[char46] +.PP +.PP +The preferred way to configure a gateway is \fBha_chassis_group\fR, but \fBgateway_chassis\fR is also supported for backward compatibility\[char46] Only one of these should be set at a time on a given LRP, since they configure the same features\[char46] +.PP +.PP +Even when a gateway is configured, the logical router port still effectively resides on each chassis\[char46] However, due to the implications of the use of L2 learning in the physical network, as well as the need to support advanced features such as one-to-many NAT (aka IP masquerading), a subset of the logical router processing is handled in a centralized manner on the gateway chassis\[char46] +.PP +.PP +There can be more than one distributed gateway ports configured on each logical router, each connecting to different L2 segments\[char46] Load-balancing is not yet supported on logical routers with more than one distributed gateway ports\[char46] +.PP +.PP +For each distributed gateway port, it may have more than one gateway chassises\[char46] When more than one gateway chassis is specified, OVN only uses one at a time\[char46] OVN can rely on OVS BFD implementation to monitor gateway connectivity, preferring the highest-priority gateway that is online\[char46] Priorities are specified in the \fBpriority\fR column of \fBGateway_Chassis\fR or \fBHA_Chassis\fR\[char46] +.PP +.PP +\fBovn\-northd\fR programs the \fBexternal_mac\fR rules specified in the LRP\(cqs LR into the peer logical switch\(cqs destination lookup on the chassis where the \fBlogical_port\fR resides\[char46] In addition, the logical router\(cqs MAC address is automatically programmed in the peer logical switch\(cqs destination lookup flow on the gateway chasssis\[char46] If it is desired to generate gratuitous ARPs for NAT addresses, then set the peer LSP\(cqs \fBoptions:nat-addresses\fR to \fBrouter\fR\[char46] +.PP +.PP +OVN 20\[char46]03 and earlier supported a third way to configure distributed gateway ports using \fBoptions:redirect\-chassis\fR to specify the gateway chassis\[char46] This method is no longer supported\[char46] Any remaining users should switch to one of the newer methods instead\[char46] A \fBgateway_chassis\fR may be easily configured from the command line, e\[char46]g\[char46] \fBovn\-nbctl lrp\-set\-gateway\-chassis +\fIlrp\fB \fIchassis\fB\fR\[char46] +.IP "\fBha_chassis_group\fR: optional \fBHA_Chassis_Group\fR" +Designates an \fBHA_Chassis_Group\fR to provide gateway high availability\[char46] +.IP "\fBgateway_chassis\fR: set of \fBGateway_Chassis\fRes" +Designates one or more \fBGateway_Chassis\fR for the logical router port\[char46] +.ST "Options for Physical VLAN MTU Issues:" +.PP +.PP +.PP +MTU issues arise in mixing tunnels with logical networks that are bridged to a physical VLAN\[char46] For an explanation of the MTU issues, see \fBPhysical VLAN MTU Issues\fR in the OVN architecture document\[char46] The following options, which are alternatives, provide solutions\[char46] Both of them cause packets to be sent over \fBlocalnet\fR instead of tunnels, but they differ in whether some or all packets are sent this way\[char46] The most prominent tradeoff between these options is that \fBreside\-on\-redirect\-chassis\fR is easier to configure and that \fBredirect\-type\fR performs better for east-west traffic\[char46] +.IP "\fBoptions : reside-on-redirect-chassis\fR: optional string, either \fBtrue\fR or \fBfalse\fR" +If set to \fBtrue\fR, this option forces all traffic across the logical router port to pass through the gateway chassis using a hop across a \fBlocalnet\fR port\[char46] This changes behavior in two ways: +.RS +.IP \(bu +Without this option, east-west traffic passes directly between source and destination chassis (or even within a single chassis, for co-located VMs)\[char46] With this option, all east-west traffic passes through the gateway chassis\[char46] +.IP \(bu +Without this option, traffic between the gateway chassis and other chassis is encapsulated in tunnels\[char46] With this option, traffic passes over a \fBlocalnet\fR interface\[char46] +.RE +.IP +This option may usefully be set only on logical router ports that connect a distributed logical router to a logical switch with VIFs\[char46] It should not be set on a distributed gateway port\[char46] +.IP +OVN honors this option only if the logical router has one and only one distributed gateway port and if the LRP\(cqs peer switch has a \fBlocalnet\fR port\[char46] +.IP "\fBoptions : redirect-type\fR: optional string, either \fBbridged\fR or \fBoverlay\fR" +If set to \fBbridged\fR on a distributed gateway port, this option causes OVN to redirect packets to the gateway chassis over a \fBlocalnet\fR port instead of a tunnel\[char46] The relevant chassis must share a \fBlocalnet\fR port\[char46] +.IP +This feature requires the administrator or the CMS to configure each participating chassis with a unique Ethernet address for the logical router by setting \fBovn\-chassis\-mac\-mappings\fR in the Open vSwitch database, for use by \fBovn\-controller\fR\[char46] +.IP +Setting this option to \fBoverlay\fR or leaving it unset has no effect\[char46] 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\[char46] It is otherwise ignored\[char46] +.IP "\fBipv6_prefix\fR: set of strings" +This column contains IPv6 prefix obtained by prefix delegation router according to RFC 3633 +.ST "ipv6_ra_configs:" +.PP +.PP +.PP +This column defines the IPv6 ND RA address mode and ND MTU Option to be included by \fBovn\-controller\fR when it replies to the IPv6 Router solicitation requests\[char46] +.IP "\fBipv6_ra_configs : address_mode\fR: optional string" +The address mode to be used for IPv6 address configuration\[char46] The supported values are: +.RS +.IP \(bu +\fBslaac\fR: Address configuration using Router Advertisement (RA) packet\[char46] The IPv6 prefixes defined in the \fBLogical_Router_Port\fR table\(cqs \fBnetworks\fR column will be included in the RA\(cqs ICMPv6 option - Prefix information\[char46] +.IP \(bu +\fBdhcpv6_stateful\fR: Address configuration using DHCPv6\[char46] +.IP \(bu +\fBdhcpv6_stateless\fR: Address configuration using Router Advertisement (RA) packet\[char46] Other IPv6 options are provided by DHCPv6\[char46] +.RE +.IP "\fBipv6_ra_configs : router_preference\fR: optional string" +Default Router Preference (PRF) indicates whether to prefer this router over other default routers (RFC 4191)\[char46] Possible values are: +.RS +.IP \(bu +HIGH: mapped to 0x01 in RA PRF field +.IP \(bu +MEDIUM: mapped to 0x00 in RA PRF field +.IP \(bu +LOW: mapped to 0x11 in RA PRF field +.RE +.IP "\fBipv6_ra_configs : route_info\fR: optional string" +Route Info is used to configure Route Info Option sent in Router Advertisement according to RFC 4191\[char46] Route Info is a comma separated string where each field provides PRF and prefix for a given route (e\[char46]g: HIGH-aef1::11/48,LOW-aef2::11/96) Possible PRF values are: +.RS +.IP \(bu +HIGH: mapped to 0x01 in RA PRF field +.IP \(bu +MEDIUM: mapped to 0x00 in RA PRF field +.IP \(bu +LOW: mapped to 0x11 in RA PRF field +.RE +.IP "\fBipv6_ra_configs : mtu\fR: optional string" +The recommended MTU for the link\[char46] Default is 0, which means no MTU Option will be included in RA packet replied by ovn-controller\[char46] 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\[char46] +.IP "\fBipv6_ra_configs : send_periodic\fR: optional string" +If set to true, then this router interface will send router advertisements periodically\[char46] The default is false\[char46] +.IP "\fBipv6_ra_configs : max_interval\fR: optional string" +The maximum number of seconds to wait between sending periodic router advertisements\[char46] This option has no effect if \fBipv6_ra_configs:send_periodic\fR is false\[char46] The default is 600\[char46] +.IP "\fBipv6_ra_configs : min_interval\fR: optional string" +The minimum number of seconds to wait between sending periodic router advertisements\[char46] This option has no effect if \fBipv6_ra_configs:send_periodic\fR is false\[char46] The default is one-third of \fBipv6_ra_configs:max_interval\fR, i\[char46]e\[char46] 200 seconds if that key is unset\[char46] +.IP "\fBipv6_ra_configs : rdnss\fR: optional string" +IPv6 address of RDNSS server announced in RA packets\[char46] At the moment OVN supports just one RDNSS server\[char46] +.IP "\fBipv6_ra_configs : dnssl\fR: optional string" +DNS Search List announced in RA packets\[char46] Multiple DNS Search List must be \(cqcomma\(cq separated (e\[char46]g\[char46] \(dqa\[char46]b\[char46]c, d\[char46]e\[char46]f\(dq) +.ST "Options:" +.PP +.PP +.PP +Additional options for the logical router port\[char46] +.IP "\fBoptions : mcast_flood\fR: optional string, either \fBtrue\fR or \fBfalse\fR" +If set to \fBtrue\fR, multicast traffic (including reports) are unconditionally forwarded to the specific port\[char46] +.IP +This option applies when the port is part of a logical router which has \fBoptions\fR:mcast_relay set to \fBtrue\fR\[char46] +.IP +Default: \fBfalse\fR\[char46] +.IP "\fBoptions : requested-tnl-key\fR: optional string, containing an integer, in range 1 to 32,767" +Configures the port binding tunnel key for the port\[char46] Usually this is not needed because \fBovn\-northd\fR will assign an unique key for each port by itself\[char46] However, if it is configured, \fBovn\-northd\fR honors the configured value\[char46] +.IP "\fBoptions : prefix_delegation\fR: optional string, either \fBtrue\fR or \fBfalse\fR" +If set to \fBtrue\fR, enable IPv6 prefix delegation state machine on this logical router port (RFC3633)\[char46] IPv6 prefix delegation is available just on a gateway router or on a gateway router port\[char46] +.IP "\fBoptions : prefix\fR: optional string, either \fBtrue\fR or \fBfalse\fR" +If set to \fBtrue\fR, this interface will receive an IPv6 prefix according to RFC3663 +.IP "\fBoptions : route_table\fR: optional string" +Designates lookup Logical_Router_Static_Routes with specified \fBroute_table\fR value\[char46] Routes to directly connected networks from same Logical Router and routes without \fBroute_table\fR option set have higher priority than routes with \fBroute_table\fR option set\[char46] +.IP "\fBoptions : gateway_mtu\fR: optional string, containing an integer, in range 68 to 65,535" +If set, logical flows will be added to router pipeline to check packet length\[char46] If packet length is greater than the value set, ICMPv4 type 3 (Destination Unreachable) code 4 (Fragmentation Needed and Don\(cqt Fragment was Set) or ICMPv6 type 2 (Packet Too Big) code 0 (no route to destination) packets will be generated\[char46] This allows for Path MTU Discovery\[char46] +.IP "\fBoptions : gateway_mtu_bypass\fR: optional string" +When configured, represents a match expression, in the same expression language used for the \fBmatch\fR column in the OVN Southbound database\(cqs \fBLogical_Flow\fR table\[char46] Packets matching this expression will bypass the length check configured through the \fBoptions:gateway_mtu\fR option\[char46] +.ST "Attachment:" +.PP +.PP +.PP +A given router port serves one of two purposes: +.RS +.IP \(bu +To attach a logical switch to a logical router\[char46] A logical router port of this type is referenced by exactly one \fBLogical_Switch_Port\fR of type \fBrouter\fR\[char46] The value of \fBname\fR is set as \fBrouter\-port\fR in column \fBoptions\fR of \fBLogical_Switch_Port\fR\[char46] In this case \fBpeer\fR column is empty\[char46] +.IP \(bu +To connect one logical router to another\[char46] This requires a pair of logical router ports, each connected to a different router\[char46] Each router port in the pair specifies the other in its \fBpeer\fR column\[char46] No \fBLogical_Switch\fR refers to the router port\[char46] +.RE +.IP "\fBpeer\fR: optional string" +For a router port used to connect two logical routers, this identifies the other router port in the pair by \fBname\fR\[char46] +.IP +For a router port attached to a logical switch, this column is empty\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +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] +.bp +.SH "Logical_Router_Static_Route TABLE" +.PP +.PP +.PP +Each record represents a static route\[char46] +.PP +.PP +When multiple routes match a packet, the longest-prefix match is chosen\[char46] For a given prefix length, a \fBdst\-ip\fR route is preferred over a \fBsrc\-ip\fR route\[char46] +.PP +.PP +When there are ECMP routes, i\[char46]e\[char46] multiple routes with same prefix and policy, one of them will be selected based on the 5-tuple hashing of the packet header\[char46] +.SS "Summary: +.TQ 3.00in +\fBip_prefix\fR +string +.TQ 3.00in +\fBpolicy\fR +optional string, either \fBdst\-ip\fR or \fBsrc\-ip\fR +.TQ 3.00in +\fBnexthop\fR +string +.TQ 3.00in +\fBoutput_port\fR +optional string +.TQ 3.00in +\fBbfd\fR +optional weak reference to \fBBFD\fR +.TQ 3.00in +\fBroute_table\fR +string +.TQ 3.00in +\fBexternal_ids : ic-learned-route\fR +optional string +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.TQ .25in +\fICommon options:\fR +.RS .25in +.TQ 2.75in +\fBoptions\fR +map of string-string pairs +.TQ 2.75in +\fBoptions : ecmp_symmetric_reply\fR +optional string +.TQ 2.75in +\fBoptions : origin\fR +optional string +.RE +.SS "Details: +.IP "\fBip_prefix\fR: string" +IP prefix of this route (e\[char46]g\[char46] 192\[char46]168\[char46]100\[char46]0/24)\[char46] +.IP "\fBpolicy\fR: optional string, either \fBdst\-ip\fR or \fBsrc\-ip\fR" +If it is specified, this setting describes the policy used to make routing decisions\[char46] This setting must be one of the following strings: +.RS +.IP \(bu +\fBsrc\-ip\fR: This policy sends the packet to the \fBnexthop\fR when the packet\(cqs source IP address matches \fBip_prefix\fR\[char46] +.IP \(bu +\fBdst\-ip\fR: This policy sends the packet to the \fBnexthop\fR when the packet\(cqs destination IP address matches \fBip_prefix\fR\[char46] +.RE +.IP +If not specified, the default is \fBdst\-ip\fR\[char46] +.IP "\fBnexthop\fR: string" +Nexthop IP address for this route\[char46] Nexthop IP address should be the IP address of a connected router port or the IP address of a logical port or can be set to \fBdiscard\fR for dropping packets which match the given route\[char46] +.IP "\fBoutput_port\fR: optional string" +The name of the \fBLogical_Router_Port\fR via which the packet needs to be sent out\[char46] This is optional and when not specified, OVN will automatically figure this out based on the \fBnexthop\fR\[char46] When this is specified and there are multiple IP addresses on the router port and none of them are in the same subnet of \fBnexthop\fR, OVN chooses the first IP address as the one via which the \fBnexthop\fR is reachable\[char46] +.IP "\fBbfd\fR: optional weak reference to \fBBFD\fR" +Reference to \fBBFD\fR row if the route has associated a BFD session +.IP "\fBroute_table\fR: string" +Any string to place route to separate routing table\[char46] If Logical Router Port has configured value in \fBoptions:route_table\fR other than empty string, OVN performs route lookup for all packets entering Logical Router ingress pipeline from this port in the following manner: +.RS +.IP \(bu +1\[char46] First lookup among \(dqglobal\(dq routes: routes without \fBroute_table\fR value set and routes to directly connected networks\[char46] +.IP \(bu +2\[char46] Next lookup among routes with same \fBroute_table\fR value as specified in LRP\(cqs options:route_table field\[char46] +.RE +.IP "\fBexternal_ids : ic-learned-route\fR: optional string" +\fBovn\-ic\fR populates this key if the route is learned from the global \fBOVN_IC_Southbound\fR database\[char46] In this case the value will be set to the uuid of the row in \fBRoute\fR table of the \fBOVN_IC_Southbound\fR database\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.ST "Common options:" +.PP +.IP "\fBoptions\fR: map of string-string pairs" +This column provides general key/value settings\[char46] The supported options are described individually below\[char46] +.IP "\fBoptions : ecmp_symmetric_reply\fR: optional string" +If true, then new traffic that arrives over this route will have its reply traffic bypass ECMP route selection and will be sent out this route instead\[char46] Note that this option overrides any rules set in the \fBLogical_Router_policy\fR table\[char46] This option only works on gateway routers (routers that have \fBoptions:chassis\fR set)\[char46] +.IP "\fBoptions : origin\fR: optional string" +In case ovn-interconnection has been learned this route, it will have its origin set: either \(dqconnected\(dq or \(dqstatic\(dq\[char46] This key is supposed to be written only by \fBovn\-ic\fR daemon\[char46] ovn-northd then checks this value when generating Logical Flows\[char46] \fBLogical_Router_Static_Route\fR records with same \fBip_prefix\fR within same Logical Router will have next lookup order based on \fBorigin\fR key value: +.RS +.IP 1. .4in +connected +.IP 2. .4in +static +.RE +.bp +.SH "Logical_Router_Policy TABLE" +.PP +.PP +.PP +Each row in this table represents one routing policy for a logical router that points to it through its \fBpolicies\fR column\[char46] The \fBaction\fR column for the highest-\fBpriority\fR matching row in this table determines a packet\(cqs treatment\[char46] If no row matches, packets are allowed by default\[char46] (Default-deny treatment is possible: add a rule with \fBpriority\fR 0, \fB1\fR as \fBmatch\fR, and \fBdrop\fR as \fBaction\fR\[char46]) +.SS "Summary: +.TQ 3.00in +\fBpriority\fR +integer, in range 0 to 32,767 +.TQ 3.00in +\fBmatch\fR +string +.TQ 3.00in +\fBaction\fR +string, one of \fBallow\fR, \fBdrop\fR, or \fBreroute\fR +.TQ 3.00in +\fBnexthop\fR +optional string +.TQ 3.00in +\fBnexthops\fR +set of strings +.TQ 3.00in +\fBoptions : pkt_mark\fR +optional string +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBpriority\fR: integer, in range 0 to 32,767" +The routing policy\(cqs priority\[char46] Rules with numerically higher priority take precedence over those with lower\[char46] A rule is uniquely identified by the priority and match string\[char46] +.IP "\fBmatch\fR: string" +The packets that the routing policy should match, in the same expression language used for the \fBmatch\fR column in the OVN Southbound database\(cqs \fBLogical_Flow\fR table\[char46] +.IP +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 "\fBaction\fR: string, one of \fBallow\fR, \fBdrop\fR, or \fBreroute\fR" +The action to take when the routing policy matches: +.RS +.IP \(bu +\fBallow\fR: Forward the packet\[char46] +.IP \(bu +\fBdrop\fR: Silently drop the packet\[char46] +.IP \(bu +\fBreroute\fR: Reroute packet to \fBnexthop\fR or \fBnexthops\fR\[char46] +.RE +.IP "\fBnexthop\fR: optional string" +Note: This column is deprecated in favor of \fBnexthops\fR\[char46] +.IP +Next-hop IP address for this route, which should be the IP address of a connected router port or the IP address of a logical port\[char46] +.IP "\fBnexthops\fR: set of strings" +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 "\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:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "NAT TABLE" +.PP +.PP +.PP +Each record represents a NAT rule\[char46] +.SS "Summary: +.TQ 3.00in +\fBtype\fR +string, one of \fBdnat\fR, \fBdnat_and_snat\fR, or \fBsnat\fR +.TQ 3.00in +\fBexternal_ip\fR +string +.TQ 3.00in +\fBexternal_mac\fR +optional string +.TQ 3.00in +\fBexternal_port_range\fR +string +.TQ 3.00in +\fBlogical_ip\fR +string +.TQ 3.00in +\fBlogical_port\fR +optional string +.TQ 3.00in +\fBallowed_ext_ips\fR +optional \fBAddress_Set\fR +.TQ 3.00in +\fBexempted_ext_ips\fR +optional \fBAddress_Set\fR +.TQ 3.00in +\fBgateway_port\fR +optional weak reference to \fBLogical_Router_Port\fR +.TQ 3.00in +\fBoptions : stateless\fR +optional string +.TQ 3.00in +\fBoptions : add_route\fR +optional string +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBtype\fR: string, one of \fBdnat\fR, \fBdnat_and_snat\fR, or \fBsnat\fR" +Type of the NAT rule\[char46] +.RS +.IP \(bu +When \fBtype\fR is \fBdnat\fR, the externally visible IP address \fBexternal_ip\fR is DNATted to the IP address \fBlogical_ip\fR in the logical space\[char46] +.IP \(bu +When \fBtype\fR is \fBsnat\fR, IP packets with their source IP address that either matches the IP address in \fBlogical_ip\fR or is in the network provided by \fBlogical_ip\fR is SNATed into the IP address in \fBexternal_ip\fR\[char46] +.IP \(bu +When \fBtype\fR is \fBdnat_and_snat\fR, the externally visible IP address \fBexternal_ip\fR is DNATted to the IP address \fBlogical_ip\fR in the logical space\[char46] In addition, IP packets with the source IP address that matches \fBlogical_ip\fR is SNATed into the IP address in \fBexternal_ip\fR\[char46] +.RE +.IP "\fBexternal_ip\fR: string" +An IPv4 address\[char46] +.IP "\fBexternal_mac\fR: optional string" +A MAC address\[char46] +.IP +This is only used on the gateway port on distributed routers\[char46] This must be specified in order for the NAT rule to be processed in a distributed manner on all chassis\[char46] 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\[char46] +.IP +This MAC address must be unique on the logical switch that the gateway port is attached to\[char46] If the MAC address used on the \fBlogical_port\fR is globally unique, then that MAC address can be specified as this \fBexternal_mac\fR\[char46] +.IP "\fBexternal_port_range\fR: string" +L4 source port range +.IP +Range of ports, from which a port number will be picked that will replace the source port of to be NATed packet\[char46] This is basically PAT (port address translation)\[char46] +.IP +Value of the column is in the format, port_lo-port_hi\[char46] For example: external_port_range : \(dq1\-30000\(dq +.IP +Valid range of ports is 1\-65535\[char46] +.IP "\fBlogical_ip\fR: string" +An IPv4 network (e\[char46]g 192\[char46]168\[char46]1\[char46]0/24) or an IPv4 address\[char46] +.IP "\fBlogical_port\fR: optional string" +The name of the logical port where the \fBlogical_ip\fR resides\[char46] +.IP +This is only used on distributed routers\[char46] This must be specified in order for the NAT rule to be processed in a distributed manner on all chassis\[char46] 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\[char46] +.IP "\fBallowed_ext_ips\fR: optional \fBAddress_Set\fR" +It represents Address Set of external ips that NAT rule is applicable to\[char46] For SNAT type NAT rules, this refers to destination addresses\[char46] For DNAT type NAT rules, this refers to source addresses\[char46] +.IP +This configuration overrides the default NAT behavior of applying a rule solely based on internal IP\[char46] Without this configuration, NAT happens without considering the external IP (i\[char46]e dest/source for snat/dnat type rule)\[char46] With this configuration NAT rule is applied ONLY if external ip is in the input Address Set\[char46] +.IP "\fBexempted_ext_ips\fR: optional \fBAddress_Set\fR" +It represents Address Set of external ips that NAT rule is NOT applicable to\[char46] For SNAT type NAT rules, this refers to destination addresses\[char46] For DNAT type NAT rules, this refers to source addresses\[char46] +.IP +This configuration overrides the default NAT behavior of applying a rule solely based on internal IP\[char46] Without this configuration, NAT happens without considering the external IP (i\[char46]e dest/source for snat/dnat type rule)\[char46] With this configuration NAT rule is NOT applied if external ip is in the input Address Set\[char46] +.IP +If there are NAT rules in a logical router with overlapping IP prefixes (including /32), then usage of \fIexempted_ext_ips\fR should be avoided in following scenario\[char46] a\[char46] SNAT rule (let us say RULE1) with logical_ip PREFIX/MASK (let us say 50\[char46]0\[char46]0\[char46]0/24)\[char46] b\[char46] SNAT rule (let us say RULE2) with logical_ip PREFIX/MASK+1 (let us say 50\[char46]0\[char46]0\[char46]0/25)\[char46] c\[char46] Now, if exempted_ext_ips is associated with RULE2, then a logical ip which matches both 50\[char46]0\[char46]0\[char46]0/24 and 50\[char46]0\[char46]0\[char46]0/25 may get the RULE2 applied to it instead of RULE1\[char46] +.IP +\fIallowed_ext_ips\fR and \fIexempted_ext_ips\fR are mutually exclusive to each other\[char46] If both Address Sets are set for a rule, then the NAT rule is not considered\[char46] +.IP "\fBgateway_port\fR: optional weak reference to \fBLogical_Router_Port\fR" +A distributed gateway port in the \fBLogical_Router_Port\fR table where the NAT rule needs to be applied\[char46] +.IP +When multiple distributed gateway ports are configured on a \fBLogical_Router\fR, applying a NAT rule at each of the distributed gateway ports might not be desired\[char46] Consider the case where a logical router has 2 distributed gateway port, one with \fBnetworks\fR \fB50\[char46]0\[char46]0\[char46]10/24\fR and the other with \fBnetworks\fR \fB60\[char46]0\[char46]0\[char46]10/24\fR\[char46] If the logical router has a NAT rule of \fBtype\fR \fBsnat\fR, \fBlogical_ip\fR \fB10\[char46]1\[char46]1\[char46]0/24\fR and \fBexternal_ip\fR \fB50\[char46]1\[char46]1\[char46]20/24\fR, the rule needs to be selectively applied on matching packets entering/leaving through the distributed gateway port with \fBnetworks\fR \fB50\[char46]0\[char46]0\[char46]10/24\fR\[char46] +.IP +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 \fBexternal_ip\fR of the NAT rule, if such a router port exists\[char46] 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 \fBexternal_ip\fR of the NAT rule\[char46] +.IP "\fBoptions : stateless\fR: optional string" +Indicates if a dnat_and_snat rule should lead to connection tracking state or not\[char46] +.IP "\fBoptions : add_route\fR: optional string" +If set to \fBtrue\fR, then neighbor routers will have logical flows added that will allow for routing to the NAT address\[char46] It also will have ARP resolution logical flows added\[char46] By setting this option, it means there is no reason to create a \fBLogical_Router_Static_Route\fR from neighbor routers to this NAT address\[char46] It also means that no ARP request is required for neighbor routers to learn the IP-MAC mapping for this NAT address\[char46] This option only applies to NATs of type \fBdnat\fR and \fBdnat_and_snat\fR\[char46] For more information about what flows are added for IP routes, please see the \fBovn\-northd\fR manpage section on IP Routing\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "DHCP_Options TABLE" +.PP +.PP +.PP +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\[char46] To do this it allows a short list of DHCPv4 options to be configured and applied at each compute host running \fBovn\-controller\fR\[char46] +.PP +.PP +OVN also implements native DHCPv6 support which provides stateless replies to DHCPv6 requests\[char46] +.SS "Summary: +.TQ 3.00in +\fBcidr\fR +string +.TQ .25in +\fIDHCPv4 options:\fR +.RS .25in +.TQ .25in +\fIMandatory DHCPv4 options:\fR +.RS .25in +.TQ 2.50in +\fBoptions : server_id\fR +optional string +.TQ 2.50in +\fBoptions : server_mac\fR +optional string +.TQ 2.50in +\fBoptions : lease_time\fR +optional string, containing an integer, in range 0 to 4,294,967,295 +.RE +.TQ .25in +\fIIPv4 DHCP Options:\fR +.RS .25in +.TQ 2.50in +\fBoptions : router\fR +optional string +.TQ 2.50in +\fBoptions : netmask\fR +optional string +.TQ 2.50in +\fBoptions : dns_server\fR +optional string +.TQ 2.50in +\fBoptions : log_server\fR +optional string +.TQ 2.50in +\fBoptions : lpr_server\fR +optional string +.TQ 2.50in +\fBoptions : swap_server\fR +optional string +.TQ 2.50in +\fBoptions : policy_filter\fR +optional string +.TQ 2.50in +\fBoptions : router_solicitation\fR +optional string +.TQ 2.50in +\fBoptions : nis_server\fR +optional string +.TQ 2.50in +\fBoptions : ntp_server\fR +optional string +.TQ 2.50in +\fBoptions : netbios_name_server\fR +optional string +.TQ 2.50in +\fBoptions : classless_static_route\fR +optional string +.TQ 2.50in +\fBoptions : ms_classless_static_route\fR +optional string +.TQ 2.50in +\fBoptions : next_server\fR +optional string +.RE +.TQ .25in +\fIBoolean DHCP Options:\fR +.RS .25in +.TQ 2.50in +\fBoptions : ip_forward_enable\fR +optional string, either \fB0\fR or \fB1\fR +.TQ 2.50in +\fBoptions : router_discovery\fR +optional string, either \fB0\fR or \fB1\fR +.TQ 2.50in +\fBoptions : ethernet_encap\fR +optional string, either \fB0\fR or \fB1\fR +.RE +.TQ .25in +\fIInteger DHCP Options:\fR +.RS .25in +.TQ 2.50in +\fBoptions : default_ttl\fR +optional string, containing an integer, in range 0 to 255 +.TQ 2.50in +\fBoptions : tcp_ttl\fR +optional string, containing an integer, in range 0 to 255 +.TQ 2.50in +\fBoptions : mtu\fR +optional string, containing an integer, in range 68 to 65,535 +.TQ 2.50in +\fBoptions : T1\fR +optional string, containing an integer, in range 68 to 4,294,967,295 +.TQ 2.50in +\fBoptions : T2\fR +optional string, containing an integer, in range 68 to 4,294,967,295 +.TQ 2.50in +\fBoptions : arp_cache_timeout\fR +optional string, containing an integer, in range 0 to 255 +.TQ 2.50in +\fBoptions : tcp_keepalive_interval\fR +optional string, containing an integer, in range 0 to 255 +.TQ 2.50in +\fBoptions : netbios_node_type\fR +optional string, containing an integer, in range 0 to 255 +.RE +.TQ .25in +\fIString DHCP Options:\fR +.RS .25in +.TQ 2.50in +\fBoptions : wpad\fR +optional string +.TQ 2.50in +\fBoptions : bootfile_name\fR +optional string +.TQ 2.50in +\fBoptions : path_prefix\fR +optional string +.TQ 2.50in +\fBoptions : tftp_server_address\fR +optional string +.TQ 2.50in +\fBoptions : hostname\fR +optional string +.TQ 2.50in +\fBoptions : domain_name\fR +optional string +.TQ 2.50in +\fBoptions : bootfile_name_alt\fR +optional string +.TQ 2.50in +\fBoptions : broadcast_address\fR +optional string +.RE +.TQ .25in +\fIDHCP Options of type host_id:\fR +.RS .25in +.TQ 2.50in +\fBoptions : tftp_server\fR +optional string +.RE +.TQ .25in +\fI DHCP Options of type domains:\fR +.RS .25in +.TQ 2.50in +\fBoptions : domain_search_list\fR +optional string +.RE +.RE +.TQ .25in +\fIDHCPv6 options:\fR +.RS .25in +.TQ .25in +\fIMandatory DHCPv6 options:\fR +.RS .25in +.TQ 2.50in +\fBoptions : server_id\fR +optional string +.RE +.TQ .25in +\fIIPv6 DHCPv6 options:\fR +.RS .25in +.TQ 2.50in +\fBoptions : dns_server\fR +optional string +.RE +.TQ .25in +\fIString DHCPv6 options:\fR +.RS .25in +.TQ 2.50in +\fBoptions : domain_search\fR +optional string +.TQ 2.50in +\fBoptions : dhcpv6_stateless\fR +optional string +.RE +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBcidr\fR: string" +The DHCPv4/DHCPv6 options will be included if the logical port has its IP address in this \fBcidr\fR\[char46] +.ST "DHCPv4 options:" +.PP +.PP +.PP +The CMS should define the set of DHCPv4 options as key/value pairs in the \fBoptions\fR column of this table\[char46] For \fBovn\-controller\fR to include these DHCPv4 options, the \fBdhcpv4_options\fR of \fBLogical_Switch_Port\fR should refer to an entry in this table\[char46] +.ST "Mandatory DHCPv4 options:" +.PP +.PP +.PP +The following options must be defined\[char46] +.IP "\fBoptions : server_id\fR: optional string" +The IP address for the DHCP server to use\[char46] This should be in the subnet of the offered IP\[char46] This is also included in the DHCP offer as option 54, ``server identifier\[char46]\(cq\(cq +.IP "\fBoptions : server_mac\fR: optional string" +The Ethernet address for the DHCP server to use\[char46] +.IP "\fBoptions : lease_time\fR: optional string, containing an integer, in range 0 to 4,294,967,295" +The offered lease time in seconds, +.IP +The DHCPv4 option code for this option is 51\[char46] +.ST "IPv4 DHCP Options:" +.PP +.PP +.PP +Below are the supported DHCPv4 options whose values are an IPv4 address, e\[char46]g\[char46] \fB192\[char46]168\[char46]1\[char46]1\fR\[char46] Some options accept multiple IPv4 addresses enclosed within curly braces, e\[char46]g\[char46] \fB{192\[char46]168\[char46]1\[char46]2, +192\[char46]168\[char46]1\[char46]3}\fR\[char46] Please refer to RFC 2132 for more details on DHCPv4 options and their codes\[char46] +.IP "\fBoptions : router\fR: optional string" +The IP address of a gateway for the client to use\[char46] This should be in the subnet of the offered IP\[char46] The DHCPv4 option code for this option is 3\[char46] +.IP "\fBoptions : netmask\fR: optional string" +The DHCPv4 option code for this option is 1\[char46] +.IP "\fBoptions : dns_server\fR: optional string" +The DHCPv4 option code for this option is 6\[char46] +.IP "\fBoptions : log_server\fR: optional string" +The DHCPv4 option code for this option is 7\[char46] +.IP "\fBoptions : lpr_server\fR: optional string" +The DHCPv4 option code for this option is 9\[char46] +.IP "\fBoptions : swap_server\fR: optional string" +The DHCPv4 option code for this option is 16\[char46] +.IP "\fBoptions : policy_filter\fR: optional string" +The DHCPv4 option code for this option is 21\[char46] +.IP "\fBoptions : router_solicitation\fR: optional string" +The DHCPv4 option code for this option is 32\[char46] +.IP "\fBoptions : nis_server\fR: optional string" +The DHCPv4 option code for this option is 41\[char46] +.IP "\fBoptions : ntp_server\fR: optional string" +The DHCPv4 option code for this option is 42\[char46] +.IP "\fBoptions : netbios_name_server\fR: optional string" +The DHCPv4 option code for this option is 44\[char46] +.IP "\fBoptions : classless_static_route\fR: optional string" +The DHCPv4 option code for this option is 121\[char46] +.IP +This option can contain one or more static routes, each of which consists of a destination descriptor and the IP address of the router that should be used to reach that destination\[char46] Please see RFC 3442 for more details\[char46] +.IP +Example: \fB{30\[char46]0\[char46]0\[char46]0/24,10\[char46]0\[char46]0\[char46]10, 0\[char46]0\[char46]0\[char46]0/0,10\[char46]0\[char46]0\[char46]1}\fR +.IP "\fBoptions : ms_classless_static_route\fR: optional string" +The DHCPv4 option code for this option is 249\[char46] This option is similar to \fBclassless_static_route\fR supported by Microsoft Windows DHCPv4 clients\[char46] +.IP "\fBoptions : next_server\fR: optional string" +The DHCPv4 option code for setting the \(dqNext server IP address\(dq field in the DHCP header\[char46] +.ST "Boolean DHCP Options:" +.PP +.PP +.PP +These options accept a Boolean value, expressed as \fB0\fR for false or \fB1\fR for true\[char46] +.IP "\fBoptions : ip_forward_enable\fR: optional string, either \fB0\fR or \fB1\fR" +The DHCPv4 option code for this option is 19\[char46] +.IP "\fBoptions : router_discovery\fR: optional string, either \fB0\fR or \fB1\fR" +The DHCPv4 option code for this option is 31\[char46] +.IP "\fBoptions : ethernet_encap\fR: optional string, either \fB0\fR or \fB1\fR" +The DHCPv4 option code for this option is 36\[char46] +.ST "Integer DHCP Options:" +.PP +.PP +.PP +These options accept a nonnegative integer value\[char46] +.IP "\fBoptions : default_ttl\fR: optional string, containing an integer, in range 0 to 255" +The DHCPv4 option code for this option is 23\[char46] +.IP "\fBoptions : tcp_ttl\fR: optional string, containing an integer, in range 0 to 255" +The DHCPv4 option code for this option is 37\[char46] +.IP "\fBoptions : mtu\fR: optional string, containing an integer, in range 68 to 65,535" +The DHCPv4 option code for this option is 26\[char46] +.IP "\fBoptions : T1\fR: 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 renew its address\[char46] The DHCPv4 option code for this option is 58\[char46] +.IP "\fBoptions : T2\fR: 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\[char46] The DHCPv4 option code for this option is 59\[char46] +.IP "\fBoptions : arp_cache_timeout\fR: optional string, containing an integer, in range 0 to 255" +The DHCPv4 option code for this option is 35\[char46] This option specifies the timeout in seconds for ARP cache entries\[char46] +.IP "\fBoptions : tcp_keepalive_interval\fR: optional string, containing an integer, in range 0 to 255" +The DHCPv4 option code for this option is 38\[char46] This option specifies the interval that the client TCP should wait before sending a keepalive message on a TCP connection\[char46] +.IP "\fBoptions : netbios_node_type\fR: optional string, containing an integer, in range 0 to 255" +The DHCPv4 option code for this option is 46\[char46] +.ST "String DHCP Options:" +.PP +.PP +.PP +These options accept a string value\[char46] +.IP "\fBoptions : wpad\fR: optional string" +The DHCPv4 option code for this option is 252\[char46] This option is used as part of web proxy auto discovery to provide a URL for a web proxy\[char46] +.IP "\fBoptions : bootfile_name\fR: optional string" +The DHCPv4 option code for this option is 67\[char46] This option is used to identify a bootfile\[char46] +.IP "\fBoptions : path_prefix\fR: optional string" +The DHCPv4 option code for this option is 210\[char46] In PXELINUX\(cq case this option is used to set a common path prefix, instead of deriving it from the bootfile name\[char46] +.IP "\fBoptions : tftp_server_address\fR: optional string" +The DHCPv4 option code for this option is 150\[char46] The option contains one or more IPv4 addresses that the client MAY use\[char46] This option is Cisco proprietary, the IEEE standard that matches with this requirement is option 66 (tftp_server)\[char46] +.IP "\fBoptions : hostname\fR: optional string" +The DHCPv4 option code for this option is 12\[char46] If set, indicates the DHCPv4 option \(dqHostname\(dq\[char46] Alternatively, this option can be configured in \fBoptions:hostname\fR column in table \fBLogical_Switch_Port\fR\[char46] If Hostname option value is set in both conflicting \fBLogical_Switch_Port\fR and \fBDHCP_Options\fR tables, \fBLogical_Switch_Port\fR takes precedence\[char46] +.IP "\fBoptions : domain_name\fR: optional string" +The DHCPv4 option code for this option is 15\[char46] This option specifies the domain name that client should use when resolving hostnames via the Domain Name System\[char46] +.IP "\fBoptions : bootfile_name_alt\fR: optional string" +\(dqbootfile_name_alt\(dq option is used to support iPXE\[char46] When both \(dqbootfile_name\(dq and \(dqbootfile_name_alt\(dq are provided by the CMS, \(dqbootfile_name\(dq will be used for option 67 if the dhcp request contains etherboot option (175), otherwise \(dqbootfile_name_alt\(dq will be used\[char46] +.IP "\fBoptions : broadcast_address\fR: optional string" +The DHCPv4 option code for this option is 28\[char46] This option specifies the IP address used as a broadcast address\[char46] +.ST "DHCP Options of type host_id:" +.PP +.PP +.PP +These options accept either an IPv4 address or a string value\[char46] +.IP "\fBoptions : tftp_server\fR: optional string" +The DHCPv4 option code for this option is 66\[char46] +.ST " DHCP Options of type domains:" +.PP +.PP +.PP +These options accept string value which is a comma separated list of domain names\[char46] The domain names are encoded based on RFC 1035\[char46] +.IP "\fBoptions : domain_search_list\fR: optional string" +The DHCPv4 option code for this option is 119\[char46] +.ST "DHCPv6 options:" +.PP +.PP +.PP +OVN also implements native DHCPv6 support\[char46] The CMS should define the set of DHCPv6 options as key/value pairs\[char46] 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 \fBcidr\fR\[char46] +.ST "Mandatory DHCPv6 options:" +.PP +.PP +.PP +The following options must be defined\[char46] +.IP "\fBoptions : server_id\fR: optional string" +The Ethernet address for the DHCP server to use\[char46] This is also included in the DHCPv6 reply as option 2, ``Server Identifier\(cq\(cq to carry a DUID identifying a server between a client and a server\[char46] \fBovn\-controller\fR defines DUID based on Link-layer Address [DUID-LL]\[char46] +.ST "IPv6 DHCPv6 options:" +.PP +.PP +.PP +Below are the supported DHCPv6 options whose values are an IPv6 address, e\[char46]g\[char46] \fBaef0::4\fR\[char46] Some options accept multiple IPv6 addresses enclosed within curly braces, e\[char46]g\[char46] \fB{aef0::4, +aef0::5}\fR\[char46] Please refer to RFC 3315 for more details on DHCPv6 options and their codes\[char46] +.IP "\fBoptions : dns_server\fR: optional string" +The DHCPv6 option code for this option is 23\[char46] This option specifies the DNS servers that the VM should use\[char46] +.ST "String DHCPv6 options:" +.PP +.PP +.PP +These options accept string values\[char46] +.IP "\fBoptions : domain_search\fR: optional string" +The DHCPv6 option code for this option is 24\[char46] This option specifies the domain search list the client should use to resolve hostnames with DNS\[char46] +.IP +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] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "Connection TABLE" +.PP +.PP +.PP +Configuration for a database connection to an Open vSwitch database (OVSDB) client\[char46] +.PP +.PP +This table primarily configures the Open vSwitch database server (\fBovsdb\-server\fR)\[char46] +.PP +.PP +The Open vSwitch database server can initiate and maintain active connections to remote clients\[char46] It can also listen for database connections\[char46] +.SS "Summary: +.TQ .25in +\fICore Features:\fR +.RS .25in +.TQ 2.75in +\fBtarget\fR +string (must be unique within table) +.RE +.TQ .25in +\fIClient Failure Detection and Handling:\fR +.RS .25in +.TQ 2.75in +\fBmax_backoff\fR +optional integer, at least 1,000 +.TQ 2.75in +\fBinactivity_probe\fR +optional integer +.RE +.TQ .25in +\fIStatus:\fR +.RS .25in +.TQ 2.75in +\fBis_connected\fR +boolean +.TQ 2.75in +\fBstatus : last_error\fR +optional string +.TQ 2.75in +\fBstatus : state\fR +optional string, one of \fBACTIVE\fR, \fBBACKOFF\fR, \fBCONNECTING\fR, \fBIDLE\fR, or \fBVOID\fR +.TQ 2.75in +\fBstatus : sec_since_connect\fR +optional string, containing an integer, at least 0 +.TQ 2.75in +\fBstatus : sec_since_disconnect\fR +optional string, containing an integer, at least 0 +.TQ 2.75in +\fBstatus : locks_held\fR +optional string +.TQ 2.75in +\fBstatus : locks_waiting\fR +optional string +.TQ 2.75in +\fBstatus : locks_lost\fR +optional string +.TQ 2.75in +\fBstatus : n_connections\fR +optional string, containing an integer, at least 2 +.TQ 2.75in +\fBstatus : bound_port\fR +optional string, containing an integer +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.TQ 2.75in +\fBother_config\fR +map of string-string pairs +.RE +.SS "Details: +.ST "Core Features:" +.PP +.IP "\fBtarget\fR: string (must be unique within table)" +Connection methods for clients\[char46] +.IP +The following connection methods are currently supported: +.RS +.TP +\fBssl:\fIhost\fB\fR[\fB:\fIport\fB\fR] +The specified SSL \fIport\fR on the host at the given \fIhost\fR, which can either be a DNS name (if built with unbound library) or an IP address\[char46] A valid SSL configuration must be provided when this form is used, this configuration can be specified via command-line options or the \fBSSL\fR table\[char46] +.IP +If \fIport\fR is not specified, it defaults to 6640\[char46] +.IP +SSL support is an optional feature that is not always built as part of Open vSwitch\[char46] +.TP +\fBtcp:\fIhost\fB\fR[\fB:\fIport\fB\fR] +The specified TCP \fIport\fR on the host at the given \fIhost\fR, which can either be a DNS name (if built with unbound library) or an IP address\[char46] If \fIhost\fR is an IPv6 address, wrap it in square brackets, e\[char46]g\[char46] \fBtcp:[::1]:6640\fR\[char46] +.IP +If \fIport\fR is not specified, it defaults to 6640\[char46] +.TP +\fBpssl:\fR[\fIport\fR][\fB:\fIhost\fB\fR] +Listens for SSL connections on the specified TCP \fIport\fR\[char46] Specify 0 for \fIport\fR to have the kernel automatically choose an available port\[char46] If \fIhost\fR, which can either be a DNS name (if built with unbound library) or an IP address, is specified, then connections are restricted to the resolved or specified local IPaddress (either IPv4 or IPv6 address)\[char46] If \fIhost\fR is an IPv6 address, wrap in square brackets, e\[char46]g\[char46] \fBpssl:6640:[::1]\fR\[char46] If \fIhost\fR is not specified then it listens only on IPv4 (but not IPv6) addresses\[char46] A valid SSL configuration must be provided when this form is used, this can be specified either via command-line options or the \fBSSL\fR table\[char46] +.IP +If \fIport\fR is not specified, it defaults to 6640\[char46] +.IP +SSL support is an optional feature that is not always built as part of Open vSwitch\[char46] +.TP +\fBptcp:\fR[\fIport\fR][\fB:\fIhost\fB\fR] +Listens for connections on the specified TCP \fIport\fR\[char46] Specify 0 for \fIport\fR to have the kernel automatically choose an available port\[char46] If \fIhost\fR, 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)\[char46] If \fIhost\fR is an IPv6 address, wrap it in square brackets, e\[char46]g\[char46] \fBptcp:6640:[::1]\fR\[char46] If \fIhost\fR is not specified then it listens only on IPv4 addresses\[char46] +.IP +If \fIport\fR is not specified, it defaults to 6640\[char46] +.RE +.IP +When multiple clients are configured, the \fBtarget\fR values must be unique\[char46] Duplicate \fBtarget\fR values yield unspecified results\[char46] +.ST "Client Failure Detection and Handling:" +.PP +.IP "\fBmax_backoff\fR: optional integer, at least 1,000" +Maximum number of milliseconds to wait between connection attempts\[char46] Default is implementation-specific\[char46] +.IP "\fBinactivity_probe\fR: optional integer" +Maximum number of milliseconds of idle time on connection to the client before sending an inactivity probe message\[char46] If Open vSwitch does not communicate with the client for the specified number of seconds, it will send a probe\[char46] If a response is not received for the same additional amount of time, Open vSwitch assumes the connection has been broken and attempts to reconnect\[char46] Default is implementation-specific\[char46] A value of 0 disables inactivity probes\[char46] +.ST "Status:" +.PP +.PP +.PP +Key-value pair of \fBis_connected\fR is always updated\[char46] Other key-value pairs in the status columns may be updated depends on the \fBtarget\fR type\[char46] +.PP +.PP +When \fBtarget\fR specifies a connection method that listens for inbound connections (e\[char46]g\[char46] \fBptcp:\fR or \fBpunix:\fR), both \fBn_connections\fR and \fBis_connected\fR may also be updated while the remaining key-value pairs are omitted\[char46] +.PP +.PP +On the other hand, when \fBtarget\fR specifies an outbound connection, all key-value pairs may be updated, except the above-mentioned two key-value pairs associated with inbound connection targets\[char46] They are omitted\[char46] +.IP "\fBis_connected\fR: boolean" +\fBtrue\fR if currently connected to this client, \fBfalse\fR otherwise\[char46] +.IP "\fBstatus : last_error\fR: optional string" +A human-readable description of the last error on the connection to the manager; i\[char46]e\[char46] \fBstrerror(errno)\fR\[char46] This key will exist only if an error has occurred\[char46] +.IP "\fBstatus : state\fR: optional string, one of \fBACTIVE\fR, \fBBACKOFF\fR, \fBCONNECTING\fR, \fBIDLE\fR, or \fBVOID\fR" +The state of the connection to the manager: +.RS +.TP +\fBVOID\fR +Connection is disabled\[char46] +.TP +\fBBACKOFF\fR +Attempting to reconnect at an increasing period\[char46] +.TP +\fBCONNECTING\fR +Attempting to connect\[char46] +.TP +\fBACTIVE\fR +Connected, remote host responsive\[char46] +.TP +\fBIDLE\fR +Connection is idle\[char46] Waiting for response to keep-alive\[char46] +.RE +.IP +These values may change in the future\[char46] They are provided only for human consumption\[char46] +.IP "\fBstatus : sec_since_connect\fR: optional string, containing an integer, at least 0" +The amount of time since this client last successfully connected to the database (in seconds)\[char46] Value is empty if client has never successfully been connected\[char46] +.IP "\fBstatus : sec_since_disconnect\fR: optional string, containing an integer, at least 0" +The amount of time since this client last disconnected from the database (in seconds)\[char46] Value is empty if client has never disconnected\[char46] +.IP "\fBstatus : locks_held\fR: optional string" +Space-separated list of the names of OVSDB locks that the connection holds\[char46] Omitted if the connection does not hold any locks\[char46] +.IP "\fBstatus : locks_waiting\fR: optional string" +Space-separated list of the names of OVSDB locks that the connection is currently waiting to acquire\[char46] Omitted if the connection is not waiting for any locks\[char46] +.IP "\fBstatus : locks_lost\fR: optional string" +Space-separated list of the names of OVSDB locks that the connection has had stolen by another OVSDB client\[char46] Omitted if no locks have been stolen from this connection\[char46] +.IP "\fBstatus : n_connections\fR: optional string, containing an integer, at least 2" +When \fBtarget\fR specifies a connection method that listens for inbound connections (e\[char46]g\[char46] \fBptcp:\fR or \fBpssl:\fR) and more than one connection is actually active, the value is the number of active connections\[char46] Otherwise, this key-value pair is omitted\[char46] +.IP "\fBstatus : bound_port\fR: optional string, containing an integer" +When \fBtarget\fR is \fBptcp:\fR or \fBpssl:\fR, this is the TCP port on which the OVSDB server is listening\[char46] (This is particularly useful when \fBtarget\fR specifies a port of 0, allowing the kernel to choose any available port\[char46]) +.ST "Common Columns:" +.PP +The overall purpose of these columns is described under \fBCommon +Columns\fR at the beginning of this document\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +.IP "\fBother_config\fR: map of string-string pairs" +.bp +.SH "DNS TABLE" +.PP +.PP +.PP +Each row in this table stores the DNS records\[char46] The \fBLogical_Switch\fR table\(cqs \fBdns_records\fR references these records\[char46] +.SS "Summary: +.TQ 3.00in +\fBrecords\fR +map of string-string pairs +.TQ 3.00in +\fBexternal_ids\fR +map of string-string pairs +.SS "Details: +.IP "\fBrecords\fR: map of string-string pairs" +Key-value pair of DNS records with \fBDNS query name\fR as the key and value as a string of IP address(es) separated by comma or space\[char46] For PTR requests, the key-value pair can be \fBReverse IPv4 address\[char46]in\-addr\[char46]arpa\fR and the value \fBDNS domain name\fR\[char46] For IPv6 addresses, the key has to be \fBReverse IPv6 address\[char46]ip6\[char46]arpa\fR\[char46] +.IP +\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 "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "SSL TABLE" +.PP +SSL configuration for ovn-nb database access\[char46] +.SS "Summary: +.TQ 3.00in +\fBprivate_key\fR +string +.TQ 3.00in +\fBcertificate\fR +string +.TQ 3.00in +\fBca_cert\fR +string +.TQ 3.00in +\fBbootstrap_ca_cert\fR +boolean +.TQ 3.00in +\fBssl_protocols\fR +string +.TQ 3.00in +\fBssl_ciphers\fR +string +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBprivate_key\fR: string" +Name of a PEM file containing the private key used as the switch\(cqs identity for SSL connections to the controller\[char46] +.IP "\fBcertificate\fR: string" +Name of a PEM file containing a certificate, signed by the certificate authority (CA) used by the controller and manager, that certifies the switch\(cqs private key, identifying a trustworthy switch\[char46] +.IP "\fBca_cert\fR: string" +Name of a PEM file containing the CA certificate used to verify that the switch is connected to a trustworthy controller\[char46] +.IP "\fBbootstrap_ca_cert\fR: boolean" +If set to \fBtrue\fR, 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\[char46] 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\[char46] \fBThis option exposes the +SSL connection to a man\-in\-the\-middle attack obtaining the initial +CA certificate\[char46]\fR It may still be useful for bootstrapping\[char46] +.IP "\fBssl_protocols\fR: string" +List of SSL protocols to be enabled for SSL connections\[char46] The default when this option is omitted is \fBTLSv1,TLSv1\[char46]1,TLSv1\[char46]2\fR\[char46] +.IP "\fBssl_ciphers\fR: string" +List of ciphers (in OpenSSL cipher string format) to be supported for SSL connections\[char46] The default when this option is omitted is \fBHIGH:!aNULL:!MD5\fR\[char46] +.ST "Common Columns:" +.PP +The overall purpose of these columns is described under \fBCommon +Columns\fR at the beginning of this document\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +.bp +.SH "Gateway_Chassis TABLE" +.PP +.PP +.PP +Association of a chassis to a logical router port\[char46] The traffic going out through an specific router port will be redirected to a chassis, or a set of them in high availability configurations\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBchassis_name\fR +string +.TQ 3.00in +\fBpriority\fR +integer, in range 0 to 32,767 +.TQ 3.00in +\fBoptions\fR +map of string-string pairs +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBname\fR: string (must be unique within table)" +Name of the \fBGateway_Chassis\fR\[char46] +.IP +A suggested, but not required naming convention is \fB${port_name}_${chassis_name}\fR\[char46] +.IP "\fBchassis_name\fR: string" +Name of the chassis that we want to redirect traffic through for the associated logical router port\[char46] The value must match the \fBname\fR column of the \fBChassis\fR table in the \fBOVN_Southbound\fR database\[char46] +.IP "\fBpriority\fR: integer, in range 0 to 32,767" +This is the priority of a chassis among all \fBGateway_Chassis\fR belonging to the same logical router port\[char46] +.IP "\fBoptions\fR: map of string-string pairs" +Reserved for future use\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "HA_Chassis_Group TABLE" +.PP +.PP +.PP +Table representing a group of chassis which can provide high availability services\[char46] Each chassis in the group is represented by the table \fBHA_Chassis\fR\[char46] The HA chassis with highest priority will be the master of this group\[char46] If the master chassis failover is detected, the HA chassis with the next higher priority takes over the responsibility of providing the HA\[char46] If a distributed gateway router port references a row in this table, then the master HA chassis in this group provides the gateway functionality\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBha_chassis\fR +set of \fBHA_Chassis\fRes +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBname\fR: string (must be unique within table)" +Name of the \fBHA_Chassis_Group\fR\[char46] Name should be unique\[char46] +.IP "\fBha_chassis\fR: set of \fBHA_Chassis\fRes" +A list of HA chassis which belongs to this group\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "HA_Chassis TABLE" +.PP +.SS "Summary: +.TQ 3.00in +\fBchassis_name\fR +string +.TQ 3.00in +\fBpriority\fR +integer, in range 0 to 32,767 +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBchassis_name\fR: string" +Name of the chassis which is part of the HA chassis group\[char46] The value must match the \fBname\fR column of the \fBChassis\fR table in the \fBOVN_Southbound\fR database\[char46] +.IP "\fBpriority\fR: integer, in range 0 to 32,767" +Priority of the chassis\[char46] Chassis with highest priority will be the master\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "BFD TABLE" +.PP +.PP +.PP +Contains BFD parameter for ovn-controller BFD configuration\[char46] OVN BFD implementation is used to provide detection of failures in the path between adjacent forwarding engines, including the OVN interfaces\[char46] OVN BFD provides link status info to OVN northd in order to update logical flows according to the status of BFD endpoints\[char46] In the current implementation OVN BFD is used to check next-hop status for ECMP routes\[char46] Please note BFD table refers to OVN BFD implementation and not to OVS legacy one\[char46] +.SS "Summary: +.TQ .25in +\fIConfiguration:\fR +.RS .25in +.TQ 2.75in +\fBlogical_port\fR +string +.TQ 2.75in +\fBdst_ip\fR +string +.TQ 2.75in +\fBmin_tx\fR +optional integer, at least 1 +.TQ 2.75in +\fBmin_rx\fR +optional integer +.TQ 2.75in +\fBdetect_mult\fR +optional integer, at least 1 +.TQ 2.75in +\fBoptions\fR +map of string-string pairs +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.TQ .25in +\fIStatus Reporting:\fR +.RS .25in +.TQ 2.75in +\fBstatus\fR +optional string, one of \fBadmin_down\fR, \fBdown\fR, \fBinit\fR, or \fBup\fR +.RE +.SS "Details: +.ST "Configuration:" +.PP +.PP +.PP +\fBovn\-northd\fR reads configuration from these columns\[char46] +.IP "\fBlogical_port\fR: string" +OVN logical port when BFD engine is running\[char46] +.IP "\fBdst_ip\fR: string" +BFD peer IP address\[char46] +.IP "\fBmin_tx\fR: optional integer, at least 1" +This is the minimum interval, in milliseconds, that the local system would like to use when transmitting BFD Control packets, less any jitter applied\[char46] The value zero is reserved\[char46] Default value is 1000 ms\[char46] +.IP "\fBmin_rx\fR: optional 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\[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: optional integer, at least 1" +Detection time multiplier\[char46] The negotiated transmit interval, multiplied by this value, provides the Detection Time for the receiving system in Asynchronous mode\[char46] Default value is 5\[char46] +.IP "\fBoptions\fR: map of string-string pairs" +Reserved for future use\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.ST "Status Reporting:" +.PP +.PP +.PP +\fBovn\-northd\fR writes BFD status into these columns\[char46] +.IP "\fBstatus\fR: optional string, one of \fBadmin_down\fR, \fBdown\fR, \fBinit\fR, or \fBup\fR" +BFD port logical states\[char46] Possible values are: +.RS +.IP \(bu +\fBadmin_down\fR +.IP \(bu +\fBdown\fR +.IP \(bu +\fBinit\fR +.IP \(bu +\fBup\fR +.RE +.bp +.SH "Static_MAC_Binding TABLE" +.PP +.PP +.PP +Each record represents a Static_MAC_Binding entry for a logical router\[char46] +.SS "Summary: +.TQ .25in +\fIConfiguration:\fR +.RS .25in +.TQ 2.75in +\fBlogical_port\fR +string +.TQ 2.75in +\fBip\fR +string +.TQ 2.75in +\fBmac\fR +string +.TQ 2.75in +\fBoverride_dynamic_mac\fR +boolean +.RE +.SS "Details: +.ST "Configuration:" +.PP +.PP +.PP +\fBovn\-northd\fR reads configuration from these columns and propagates the value to SBDB\[char46] +.IP "\fBlogical_port\fR: string" +The logical router port for the binding\[char46] +.IP "\fBip\fR: string" +The bound IP address\[char46] +.IP "\fBmac\fR: string" +The Ethernet address to which the IP is bound\[char46] +.IP "\fBoverride_dynamic_mac\fR: boolean" +Override dynamically learnt MACs\[char46] +.bp +.SH "Chassis_Template_Var TABLE" +.PP +.PP +.PP +One record per chassis, each containing a map, \fBvariables\fR, between template variable names and their value for that specific chassis\[char46] A template variable has a name and potentially different values on different hypervisors in the OVN cluster\[char46] For example, two rows, \fBR1 = (\[char46]chassis=C1, variables={(N: V1)}\fR and \fBR2 = (\[char46]chassis=C2, variables={(N: V2)}\fR will make \fBovn\-controller\fR running on chassis \fBC1\fR and \fBC2\fR interpret the token \fBN\fR either as \fBV1\fR (on \fBC1\fR) or as \fBV2\fR (on \fBC2\fR)\[char46] Users can refer to template variables from within other logical components, e\[char46]g\[char46], within ACL, QoS or Logical_Router_Policy matches or from Load_Balancer VIP and backend definitions\[char46] +.PP +.PP +If a template variable is referenced on a chassis for which that variable is not defined then \fBovn\-controller\fR running on that chassis will just interpret it as a raw string literal\[char46] +.SS "Summary: +.TQ 3.00in +\fBchassis\fR +string (must be unique within table) +.TQ 3.00in +\fBvariables\fR +map of string-string pairs +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBchassis\fR: string (must be unique within table)" +The chassis this set of variable values applies to\[char46] +.IP "\fBvariables\fR: map of string-string pairs" +The set of variable values for a given chassis\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] diff --git a/src/static/support/dist-docs-branch-23.06/ovn-nb.5.html b/src/static/support/dist-docs-branch-23.06/ovn-nb.5.html new file mode 100644 index 00000000..24ae1893 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-nb.5.html @@ -0,0 +1,4100 @@ +
+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 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
+       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
+       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ā€
+                     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
+       later page.
+
+       Table     Purpose
+       NB_Global Northbound configuration
+       Copp      Control plane protection
+       Logical_Switch
+                 L2 logical switch
+       Logical_Switch_Port
+                 L2 logical switch port
+       Forwarding_Group
+                 forwarding group
+       Address_Set
+                 Address Sets
+       Port_Group
+                 Port Groups
+       Load_Balancer
+                 load balancer
+       Load_Balancer_Group
+                 load balancer group
+       Load_Balancer_Health_Check
+                 load balancer
+       ACL       Access Control List (ACL) rule
+       Logical_Router
+                 L3 logical router
+       QoS       QoS rule
+       Mirror    Mirror Entry
+       Meter     Meter entry
+       Meter_Band
+                 Band for meter entries
+       Logical_Router_Port
+                 L3 logical router port
+       Logical_Router_Static_Route
+                 Logical router static routes
+       Logical_Router_Policy
+                 Logical router policies
+       NAT       NAT rules
+       DHCP_Options
+                 DHCP options
+       Connection
+                 OVSDB client connections.
+       DNS       Native DNS resolution
+       SSL       SSL configuration.
+       Gateway_Chassis
+                 Gateway_Chassis configuration.
+       HA_Chassis_Group
+                 HA_Chassis_Group configuration.
+       HA_Chassis
+                 HA_Chassis configuration.
+       BFD       BFD configuration.
+       Static_MAC_Binding
+                 Static_MAC_Binding configuration.
+       Chassis_Template_Var
+                 Chassis_Template_Var configuration.
+
+NB_Global TABLE
+       Northbound configuration for an OVN system. This table  must  have  exā€
+       actly one row.
+
+   Summary:
+       Identity:
+         name                        string
+       Status:
+         nb_cfg                      integer
+         nb_cfg_timestamp            integer
+         sb_cfg                      integer
+         sb_cfg_timestamp            integer
+         hv_cfg                      integer
+         hv_cfg_timestamp            integer
+       Common Columns:
+         external_ids                map of string-string pairs
+       Common options:
+         options                     map of string-string pairs
+         Options for configuring OVS BFD:
+            options : bfd-min-rx     optional string
+            options : bfd-decay-min-rx
+                                     optional string
+            options : bfd-min-tx     optional string
+            options : bfd-mult       optional string
+         options : mac_prefix        optional string
+         options : mac_binding_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
+                                     optional string
+         options : ignore_lsp_down   optional string
+         options : use_ct_inv_match  optional string
+         options : default_acl_drop  optional string
+         options : debug_drop_domain_id
+                                     optional string
+         options : debug_drop_collector_set
+                                     optional string
+         options : use_common_zone   optional string, either true or false
+         Options for configuring interconnection route advertisement:
+            options : ic-route-adv   optional string
+            options : ic-route-learn optional string
+            options : ic-route-adv-default
+                                     optional string
+            options : ic-route-learn-default
+                                     optional string
+            options : ic-route-blacklist
+                                     optional string
+       Connection Options:
+         connections                 set of Connections
+         ssl                         optional SSL
+       Security Configurations:
+         ipsec                       boolean
+       Read-only Options:
+         options : max_tunid         optional string
+
+   Details:
+     Identity:
+
+       name: string
+              The name of the OVN cluster, which uniquely identifies  the  OVN
+              cluster  throughout  all  OVN  clusters supposed to interconnect
+              with each other.
+
+     Status:
+
+       These columns allow a client to track the overall  configuration  state
+       of the system.
+
+       nb_cfg: integer
+              Sequence  number for client to increment. When a client modifies
+              any part of the northbound database configuration and wishes  to
+              wait  for ovn-northd and possibly all of the hypervisors to finā€
+              ish applying the changes, it may increment this sequence number.
+
+       nb_cfg_timestamp: integer
+              The timestamp, in milliseconds since the epoch, when  ovn-northd
+              sees the latest nb_cfg and starts processing.
+
+              To print the timestamp as a human-readable date:
+
+                        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 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
+              finishes applying the corresponding configuration changes to the
+              OVN_Southbound database successfully.
+
+       hv_cfg: integer
+              Sequence  number  that  ovn-northd sets to the smallest sequence
+              number of all the chassis in the  system,  as  reported  in  the
+              Chassis_Private  table  in the southbound database. Thus, hv_cfg
+              equals nb_cfg if all chassis are caught up with  the  northbound
+              configuration  (which may never happen, if any chassis is down).
+              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
+              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.
+
+       hv_cfg_timestamp: integer
+              The  largest  timestamp, in milliseconds since the epoch, of the
+              smallest sequence number of all the chassis in  the  system,  as
+              reported  in  the  Chassis_Private table in the southbound dataā€
+              base. In other words, this timestamp reflects the time when  the
+              slowest  chassis  catches  up with the northbound configuration,
+              which is useful for end-to-end control  plane  latency  measureā€
+              ment.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+     Common options:
+
+       options: map of string-string pairs
+              This  column  provides general key/value settings. The supported
+              options are described individually below.
+
+     Options for configuring OVS BFD:
+
+       These options apply when ovn-controller configures OVS BFD  on  tunnels
+       interfaces. Please note these parameters refer to legacy OVS BFD impleā€
+       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
+              interfaces.
+
+       options : bfd-decay-min-rx: optional string
+              BFD option decay-min-rx value to use  when  configuring  BFD  on
+              tunnel interfaces.
+
+       options : bfd-min-tx: optional string
+              BFD  option  min-tx  value to use when configuring BFD on tunnel
+              interfaces.
+
+       options : bfd-mult: optional string
+              BFD option mult value to use when configuring BFD on tunnel  inā€
+              terfaces.
+
+       options : mac_prefix: optional string
+              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 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 : controller_event: optional string, either true or false
+              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ā€ā€
+              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
+
+       options : northd_probe_interval: optional string
+              The  inactivity  probe  interval  of  the  connection to the OVN
+              Northbound and Southbound databases  from  ovn-northd,  in  milā€
+              liseconds.  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 : 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
+              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
+              attached.
+
+       options : use_parallel_build: optional string
+              If set to true, ovn-northd will attempt to compute logical flows
+              in parallel.
+
+              Parallel computation is enabled only if the system has 4 or more
+              cores/threads available to be used by ovn-northd.
+
+              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
+              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ā€
+              trol plane. The default value is true.
+
+       options : use_ct_inv_match: optional string
+              If set to false, ovn-northd will not use the ct.inv field in any
+              of  the  logical flow matches. The default value is true. If the
+              NIC supports offloading OVS datapath flows but  doesnā€™t  support
+              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 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
+              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
+              observation_domain_id field will be the datapathā€™s key.
+
+              The observation_point_id will be set to the first 32 bits of the
+              logical flowā€™s UUID.
+
+       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 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 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ā€ā€
+       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:
+
+       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 diā€
+       rectly connected subnets on the router.
+
+       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ā€ā€
+       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.
+
+       options : ic-route-adv: optional string
+              A  boolean  value that enables route advertisement to the global
+              OVN_IC_Southbound database. Default is false.
+
+       options : ic-route-learn: optional string
+              A boolean value that enables  route  learning  from  the  global
+              OVN_IC_Southbound database. Default is false.
+
+       options : ic-route-adv-default: optional string
+              A  boolean  value  that enables advertising default route to the
+              global OVN_IC_Southbound database. Default is false. This option
+              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
+              global OVN_IC_Southbound database. Default is false. This option
+              takes effect only when option ic-route-learn is true.
+
+       options : ic-route-blacklist: optional string
+              A  string  value  contains  a  list of CIDRs delimited by ",". A
+              route will not be advertised or learned if  the  routeā€™s  prefix
+              belongs to any of the CIDRs listed.
+
+     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ā€ā€
+              tion table for more information.
+
+       ssl: optional SSL
+              Global SSL configuration.
+
+     Security Configurations:
+
+       ipsec: boolean
+              Tunnel encryption configuration. If this column  is  set  to  be
+              true, all OVN tunnels will be encrypted with IPsec.
+
+     Read-only Options:
+
+       options : max_tunid: optional string
+              The  maximum supported tunnel ID. Depends on types of encapsulaā€
+              tion enabled in the cluster.
+
+Copp TABLE
+       This table is used to define control plane protection  policies,  i.e.,
+       associate entries from table Meter to control protocol names.
+
+   Summary:
+       name                          string (must be unique within table)
+       meters : arp                  optional string
+       meters : arp-resolve          optional string
+       meters : dhcpv4-opts          optional string
+       meters : dhcpv6-opts          optional string
+       meters : dns                  optional string
+       meters : event-elb            optional string
+       meters : icmp4-error          optional string
+       meters : icmp6-error          optional string
+       meters : igmp                 optional string
+       meters : nd-na                optional string
+       meters : nd-ns                optional string
+       meters : nd-ns-resolve        optional string
+       meters : nd-ra-opts           optional string
+       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:
+       name: string (must be unique within table)
+              CoPP name.
+
+       meters : arp: optional string
+              Rate  limiting  meter  for  ARP packets (request/reply) used for
+              learning neighbors.
+
+       meters : arp-resolve: optional string
+              Rate limiting meter for packets that require resolving the next-
+              hop (through ARP).
+
+       meters : dhcpv4-opts: optional string
+              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 opā€
+              tions.
+
+       meters : dns: optional string
+              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
+              ICMP error.
+
+       meters : icmp6-error: optional string
+              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
+              for learning neighbors.
+
+       meters : nd-ns: optional string
+              Rate limiting meter for ND neighbor  solicitation  packets  used
+              for learning neighbors.
+
+       meters : nd-ns-resolve: optional string
+              Rate limiting meter for packets that require resolving the next-
+              hop (through ND).
+
+       meters : nd-ra-opts: optional string
+              Rate  limiting  meter  for packets that require adding ND router
+              advertisement options.
+
+       meters : tcp-reset: optional string
+              Rate limiting meter for packets that require replying  with  TCP
+              RST packet.
+
+       meters : bfd: optional string
+              Rate limiting meter for BFD packets.
+
+       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 unā€ā€
+       known.
+
+   Summary:
+       ports                         set of Logical_Switch_Ports
+       load_balancer                 set of weak reference to Load_Balancers
+       load_balancer_group           set of Load_Balancer_Groups
+       acls                          set of ACLs
+       qos_rules                     set of QoSes
+       dns_records                   set of weak reference to DNSes
+       forwarding_groups             set of Forwarding_Groups
+       Naming:
+         name                        string
+         external_ids : neutron:network_name
+                                     optional string
+       IP Address Assignment:
+         other_config : subnet       optional string
+         other_config : exclude_ips  optional string
+         other_config : ipv6_prefix  optional string
+         other_config : mac_only     optional string, either true or false
+       IP Multicast Snooping Options:
+         other_config : mcast_snoop  optional string, either true or false
+         other_config : mcast_querier
+                                     optional string, either true or false
+         other_config : mcast_flood_unregistered
+                                     optional string, either true or false
+         other_config : mcast_table_size
+                                     optional string, containing  an  integer,
+                                     in range 1 to 32,766
+         other_config : mcast_idle_timeout
+                                     optional  string,  containing an integer,
+                                     in range 15 to 3,600
+         other_config : mcast_query_interval
+                                     optional string, containing  an  integer,
+                                     in range 1 to 3,600
+         other_config : mcast_query_max_response
+                                     optional  string,  containing an integer,
+                                     in range 1 to 10
+         other_config : mcast_eth_src
+                                     optional string
+         other_config : mcast_ip4_src
+                                     optional string
+         other_config : mcast_ip6_src
+                                     optional string
+       Interconnection:
+         other_config : interconn-ts
+                                     optional string
+       Tunnel Key:
+         other_config : requested-tnl-key
+                                     optional string, containing  an  integer,
+                                     in range 1 to 16,777,215
+       copp                          optional weak reference to Copp
+       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
+
+   Details:
+       ports: set of Logical_Switch_Ports
+              The logical ports connected to the logical switch.
+
+              It is an error for multiple logical switches to include the same
+              logical port.
+
+       load_balancer: set of weak reference to Load_Balancers
+              Set of load balancers associated to this logical switch.
+
+       load_balancer_group: set of Load_Balancer_Groups
+              Set of load balancers groups associated to this logical switch.
+
+       acls: set of ACLs
+              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
+              logical switch.
+
+       dns_records: set of weak reference to DNSes
+              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
+              Groups a set of logical port endpoints for traffic going out  of
+              the logical switch.
+
+     Naming:
+
+       These columns provide names for the logical switch. From OVNā€™s perspecā€
+       tive, these names have no special meaning or purpose other than to proā€
+       vide  convenience  for human interaction with the database. There is no
+       requirement for the name to be unique. (For a unique identifier  for  a
+       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ā€ā€
+       work_name. Perhaps this can be cleaned up someday.)
+
+       name: string
+              A name for the logical switch.
+
+       external_ids : neutron:network_name: optional string
+              Another name for the logical switch.
+
+     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ā€ā€
+       fig:subnet  and optionally other_config:exclude_ips. To enable IPAM for
+       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ā€ā€
+       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
+              ovn-northd to automatically assign IP addresses within that subā€
+              net.
+
+       other_config : exclude_ips: optional string
+              To exclude some addresses from automatic IP address  management,
+              set  this to a list of the IPv4 addresses or ..-delimited ranges
+              to exclude. The addresses or ranges should be a subset of  those
+              in other_config:subnet.
+
+              Whether  listed or not, ovn-northd will never allocate the first
+              or  last  address  in  a  subnet,   such   as   192.168.0.0   or
+              192.168.0.255 in 192.168.0.0/24.
+
+              Examples:
+
+              ā€¢      192.168.0.2 192.168.0.10
+
+              ā€¢      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.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 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::
+
+              ā€¢      bef0:1234:a890: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ā€
+              net nor ipv6_prefix are specified
+
+     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_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.
+              Default: false.
+
+       other_config : mcast_querier: optional string, either true or false
+              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
+       or false
+              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ā€
+       ger, in range 1 to 32,766
+              Number of multicast groups to be stored. Default: 2048.
+
+       other_config : mcast_idle_timeout: optional string, containing an inteā€
+       ger, in range 15 to 3,600
+              Configures the IP Multicast Snooping group idle timeout (in secā€
+              onds). Default: 300 seconds.
+
+       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ā€
+              ond.
+
+       other_config : mcast_eth_src: optional string
+              Configures the source Ethernet address for queries originated by
+              the logical switch.
+
+       other_config : mcast_ip4_src: optional string
+              Configures the source IPv4 address for queries originated by the
+              logical switch.
+
+       other_config : mcast_ip6_src: optional string
+              Configures the source IPv6 address for queries originated by the
+              logical switch.
+
+     Interconnection:
+
+       other_config : interconn-ts: optional string
+              The name of corresponding transit  switch  in  OVN_IC_Northbound
+              database.  This kind of logical switch is created and controlled
+              by ovn-ic.
+
+     Tunnel Key:
+
+       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ā€
+              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
+              for  interconnection:  the tunnel keys for 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.
+
+       copp: optional weak reference to Copp
+              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  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
+              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
+              See External IDs at the beginning of this document.
+
+Logical_Switch_Port TABLE
+       A port within an L2 logical switch.
+
+   Summary:
+       Core Features:
+         name                        string (must be unique within table)
+         type                        string
+       Options:
+         options                     map of string-string pairs
+         Options for router ports:
+            options : router-port    optional string
+            options : nat-addresses  optional string
+            options : exclude-lb-vips-from-garp
+                                     optional string
+            options : arp_proxy      optional string
+         Options for localnet ports:
+            options : network_name   optional string
+            options : ethtype        optional string
+            options : localnet_learn_fdb
+                                     optional string, either true or false
+         Options for l2gateway ports:
+            options : network_name   optional string
+            options : l2gateway-chassis
+                                     optional string
+         Options for vtep ports:
+            options : vtep-physical-switch
+                                     optional string
+            options : vtep-logical-switch
+                                     optional string
+         VMI (or VIF) Options:
+            options : requested-chassis
+                                     optional string
+            options : activation-strategy
+                                     optional string
+            options : iface-id-ver   optional string
+            options : qos_min_rate   optional string
+            options : qos_max_rate   optional string
+            options : qos_burst      optional string
+            options : hostname       optional string
+            VIF Plugging Options:
+              options : vif-plug-type
+                                     optional string
+              options : vif-plug-mtu-request
+                                     optional string
+         Virtual port Options:
+            options : virtual-ip     optional string
+            options : virtual-parents
+                                     optional string
+         IP Multicast Snooping Options:
+            options : mcast_flood    optional string, either true or false
+            options : mcast_flood_reports
+                                     optional string, either true or false
+       Containers:
+         parent_name                 optional string
+         tag_request                 optional integer, in range 0 to 4,095
+         tag                         optional integer, in range 1 to 4,095
+       Port State:
+         up                          optional boolean
+         enabled                     optional boolean
+       Addressing:
+         addresses                   set of strings
+         dynamic_addresses           optional string
+         port_security               set of strings
+       DHCP:
+         dhcpv4_options              optional weak reference to DHCP_Options
+         dhcpv6_options              optional weak reference to DHCP_Options
+       mirror_rules                  set of weak reference to Mirrors
+       ha_chassis_group              optional HA_Chassis_Group
+       Naming:
+         external_ids : neutron:port_name
+                                     optional string
+       Tunnel Key:
+         options : requested-tnl-key
+                                     optional string, containing  an  integer,
+                                     in range 1 to 32,767
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+     Core Features:
+
+       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ā€ā€
+              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.
+
+              For containers that share a VIF within a VM, the name can be any
+              unique identifier. See Containers, below, for more information.
+
+              A  logical  switch  port may not have the same name as a logical
+              router port, but the database schema cannot enforce this.
+
+       type: string
+              Specify a type for this logical port. Logical ports can be  used
+              to model other types of connectivity into an OVN logical switch.
+              The following types are defined:
+
+              (empty string)
+                     A VM (or VIF) interface.
+
+              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
+                     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
+                     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
+                     hypervisor.
+
+              l2gateway
+                     A connection to a physical network.
+
+              vtep   A port to a logical switch on a VTEP gateway.
+
+              external
+                     Represents a logical port which is external and not  havā€
+                     ing an OVS port in the integration bridge. OVN will never
+                     receive any traffic from this port or send any traffic to
+                     this   port.   OVN   can  support  native  services  like
+                     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
+                     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,
+                     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_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ā€ā€
+                            troller do not bind these ports and  cannot  serve
+                            the native services.
+
+                     ā€¢      When CMS supports provisioning baremetal servers.
+
+              virtual
+                     Represents a logical port which does not have an OVS port
+                     in the integration bridge and has a virtual ip configured
+                     in  the  options:virtual-ip  column.  This virtual ip can
+                     move around between the logical ports configured  in  the
+                     options:virtual-parents column.
+
+                     One of the use case where virtual ports can be used is.
+
+                     ā€¢      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
+                     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
+              below.
+
+     Options for router ports:
+
+       These options apply when type is router.
+
+       options : router-port: optional string
+              Required. The name of the Logical_Router_Port to which this logā€
+              ical switch port is connected.
+
+       options : nat-addresses: optional string
+              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,  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 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.
+                     This would result in generation of gratuitous ARPs for IP
+                     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
+                     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  opā€ā€
+              tions:router-portā€™s MAC address, not cosidering configured  load
+              balancers.
+
+       options : arp_proxy: optional string
+              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 for localnet ports:
+
+       These options apply when type is localnet.
+
+       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 loā€
+              cally accessible network, if at all.
+
+       options : ethtype: optional string
+              Optional. VLAN EtherType  field  value  for  encapsulating  VLAN
+              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
+              FDB table if set to true. The default value is false.
+
+     Options for l2gateway ports:
+
+       These options apply when type is l2gateway.
+
+       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ā€
+              work.
+
+       options : l2gateway-chassis: optional string
+              Required. The chassis on which the l2gateway logical port should
+              be bound to. ovn-controller running on the defined chassis  will
+              connect this logical port to the physical network.
+
+     Options for vtep ports:
+
+       These options apply when type is vtep.
+
+       options : vtep-physical-switch: optional string
+              Required. The name of the VTEP gateway.
+
+       options : vtep-logical-switch: optional string
+              Required. A logical switch name connected by the VTEP gateway.
+
+     VMI (or VIF) Options:
+
+       These options apply to logical ports with type having (empty string)
+
+       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
+              more than one chassis.
+
+              If set to a comma separated list, the first entry identifies the
+              main  chassis  and  the  rest are one or more additional chassis
+              that are allowed to bind the same port.
+
+              When multiple chassis are set for  the  port,  and  the  logical
+              switch  is  connected  to an external network through a localnet
+              port, tunneling is enforced for the port to  guarantee  delivery
+              of  packets  directed to the port to all its locations. This has
+              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 (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  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
+              useful in live migration scenarios for virtual machines.
+
+       options : iface-id-ver: optional string
+              If  set,  this port will be bound by ovn-controller only if this
+              same key and value is configured in the external_ids  column  in
+              the Open_vSwitch databaseā€™s Interface table.
+
+       options : qos_min_rate: optional string
+              If set, indicates the minimum guaranteed rate available for data
+              sent from this interface, in bit/s.
+
+       options : qos_max_rate: optional string
+              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 : 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 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 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ā€
+              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
+              update the MTU of the linked interface.
+
+     Virtual port Options:
+
+       These options apply when type is virtual.
+
+       options : virtual-ip: optional string
+              This option represents the virtual IPv4 address.
+
+       options : virtual-parents: optional string
+              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
+              enabled.
+
+     IP Multicast Snooping Options:
+
+       These options apply when the port is part of a logical switch which has
+       other_config :mcast_snoop set to true.
+
+       options : mcast_flood: optional string, either true or false
+              If  set to true, multicast packets (except reports) are uncondiā€
+              tionally forwarded to the specific port. Default: false.
+
+       options : mcast_flood_reports: optional string, either true or false
+              If set to true, multicast reports are unconditionally  forwarded
+              to the specific port. Default: false.
+
+     Containers:
+
+       When a large number of containers are nested within a VM, it may be too
+       expensive to dedicate a VIF to each container. OVN can use VLAN tags to
+       support  such  cases.  Each  container  is  assigned a VLAN ID and each
+       packet that passes between the hypervisor and the VM is tagged with the
+       appropriate ID for the container. Such VLAN IDs never appear on a physā€
+       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
+       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.
+
+       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
+              this column. The allocated value is written by ovn-northd 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
+              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 tag_request column.
+
+     Port State:
+
+       up: optional boolean
+              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 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
+              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
+              has all ingress and egress traffic dropped.
+
+     Addressing:
+
+       addresses: set of strings
+              Addresses owned by the logical port.
+
+              Each element in the set must take one of the following forms:
+
+              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
+                     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
+                     address on the port.
+
+                     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 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 adā€
+                     dress must be listed before the  IP  address(es)  if  deā€
+                     fined.
+
+                     Examples:
+
+                     80:fa:5b:06:72:b7
+                            This  indicates  that  the  logical  port owns the
+                            above mac address.
+
+                     80:fa:5b:06:72:b7 10.0.0.4 20.0.0.4
+                            This indicates that the logical port owns the  mac
+                            address and two IPv4 addresses.
+
+                     80:fa:5b:06:72:b7 fdaa:15f2:72cf:0:f816:3eff:fe20:3f41
+                            This  indicates that the logical port owns the mac
+                            address and 1 IPv6 address.
+
+                     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
+                            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
+                     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
+                     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
+                     dynamic_addresses column.
+
+                     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. Exā€
+                   ample: dynamic 192.168.0.1 2001::1.
+
+              mac dynamic
+                   This acts like dynamic alone but specifies a particular MAC
+                   address to use. OVN IPAM will still automatically  allocate
+                   IPv4  or  IPv6  addresses, or both, if configured appropriā€
+                   ately. Example: 80:fa:5b:06:72:b7 dynamic
+
+              router
+                   Accepted only when type is 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 options.
+
+                   The  resulting  addresses  are used to populate the logical
+                   switchā€™s destination  lookup,  and  also  for  the  logical
+                   switch to generate ARP and ND replies.
+
+                   If  the  connected  logical  router  port has a distributed
+                   gateway port specified and the  logical  router  has  rules
+                   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  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
+              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
+              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
+              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 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
+                     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
+                     source IPv4 address. (RARP is not restricted.)
+
+              ā€¢      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
+                     restricted  to  sending IPv6 Neighbor Discovery Solicitaā€
+                     tion or Advertisement packets with the  specified  source
+                     address or, for solicitations, the unspecified address.
+
+              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
+              allowed.
+
+              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 imā€
+              plemented as ACLs using the ACL table.
+
+              Examples:
+
+              80:fa:5b:06:72:b7
+                     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
+                     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
+                     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
+                     (including IPv6 Neighbor Discovery) traffic.
+
+              "80:fa:5b:12:42:ba", "80:fa:5b:06:72:b7 192.168.1.10/24"
+                     The host may send traffic from and receive traffic to the
+                     specified MAC addresses, and to receive traffic to Etherā€
+                     net multicast and broadcast addresses, but not otherwise.
+                     With MAC 80:fa:5b:12:42:ba, the  host  may  send  traffic
+                     from  and  receive  traffic  to  any L3 address. With MAC
+                     80:fa:5b:06:72:b7, 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 or  receive  any  IPv6
+                     (including IPv6 Neighbor Discovery) traffic.
+
+     DHCP:
+
+       dhcpv4_options: optional weak reference to DHCP_Options
+              This  column  defines  the  DHCPv4 Options to be included by the
+              ovn-controller when it replies to the  DHCPv4  requests.  Please
+              see the DHCP_Options table.
+
+       dhcpv6_options: optional weak reference to DHCP_Options
+              This  column  defines  the  DHCPv6 Options to be included by the
+              ovn-controller when it replies to the  DHCPv6  requests.  Please
+              see the DHCP_Options table.
+
+       mirror_rules: set of weak reference to Mirrors
+              Mirror  rules  that  apply  to  logical switch port which is the
+              source. Please see the Mirror table.
+
+       ha_chassis_group: optional HA_Chassis_Group
+              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.
+
+     Naming:
+
+       external_ids : neutron:port_name: optional string
+              This  column gives an optional human-friendly name for the port.
+              This name has no special meaning or purpose other than  to  proā€
+              vide convenience for human interaction with the northbound dataā€
+              base.
+
+              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.)
+
+     Tunnel Key:
+
+       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
+              the value from OVN_IC_Southbound through this config.
+
+     Common Columns:
+
+       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ā€ā€
+              nal_ids column of the Port_Binding table in OVN_Southbound dataā€
+              base.
+
+Forwarding_Group TABLE
+       Each row represents one forwarding group.
+
+   Summary:
+       name                          string
+       vip                           string
+       vmac                          string
+       liveness                      boolean
+       child_port                    set of 1 or more strings
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   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 inā€
+              teraction with the ovn-nb database.
+
+       vip: string
+              The virtual IP address assigned to the forwarding group. It will
+              respond with vmac when an ARP request is sent for vip.
+
+       vmac: string
+              The virtual MAC address assigned to the forwarding group.
+
+       liveness: boolean
+              If set to true, liveness is enabled for child ports otherwise it
+              is disabled.
+
+       child_port: set of 1 or more strings
+              List of child ports in the forwarding group.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+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
+       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ā€™ā€™
+
+
+       Address sets may be used in the match column of the ACL table. For synā€
+       tax information, see the details of the expression  language  used  for
+       the  match column in the Logical_Flow table of the OVN_Southbound dataā€
+       base.
+
+   Summary:
+       name                          string (must be unique within table)
+       addresses                     set of strings
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       name: string (must be unique within table)
+              A name for the address set.  Names  are  ASCII  and  must  match
+              [a-zA-Z_.][a-zA-Z_.0-9]*.
+
+       addresses: set of strings
+              The set of addresses in string form.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+Port_Group TABLE
+       Each  row  in  this  table  represents  a named group of logical switch
+       ports.
+
+       Port groups may be used in the match column of the ACL table. For  synā€
+       tax  information,  see  the details of the expression language used for
+       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 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ā€ā€
+       bound database.
+
+   Summary:
+       name                          string (must be unique within table)
+       ports                         set    of   weak   reference   to   Logiā€ā€
+                                     cal_Switch_Ports
+       acls                          set of ACLs
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       name: string (must be unique within table)
+              A name for the port  group.  Names  are  ASCII  and  must  match
+              [a-zA-Z_.][a-zA-Z_.0-9]*.
+
+       ports: set of weak reference to Logical_Switch_Ports
+              The logical switch ports belonging to the group in uuids.
+
+       acls: set of ACLs
+              Access  control  rules that apply to the port group. Applying an
+              ACL to a port group has the same effect as applying the  ACL  to
+              all  logical  lswitches  that the ports of the port group belong
+              to.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+Load_Balancer TABLE
+       Each row represents one load balancer.
+
+   Summary:
+       name                          string
+       vips                          map of string-string pairs
+       protocol                      optional string, one of sctp, tcp, or udp
+       Health Checks:
+         health_check                set of Load_Balancer_Health_Checks
+         ip_port_mappings            map of string-string pairs
+       selection_fields              set of strings, one of eth_dst,  eth_src,
+                                     ip_dst, ip_src, tp_dst, or tp_src
+       Common Columns:
+         external_ids                map of string-string pairs
+       Load_Balancer options:
+         options : reject            optional string, either true or false
+         options : hairpin_snat_ip   optional string
+         options : skip_snat         optional string
+         options : add_route         optional string
+         options : neighbor_responder
+                                     optional string
+         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
+              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
+              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
+              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ā€ā€
+              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
+              with VIP as the destination IP address and routerā€™s mac  address
+              as the destination MAC address).
+
+       protocol: optional string, one of sctp, tcp, or udp
+              Valid  protocols  are  tcp,  udp, or sctp. This column is useful
+              when a port number is provided as part of the  vips  column.  If
+              this  column  is  empty and a port number is provided as part of
+              vips column, OVN assumes the protocol to be tcp.
+
+     Health Checks:
+
+       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,
+       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.  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  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.
+
+              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
+              flow.
+
+              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
+              OVS sources for the implementation details.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+     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
+              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 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.
+
+       options : skip_snat: optional string
+              If  the load balancing rule is configured with skip_snat option,
+              the option lb_force_snat_ip configured for  the  logical  router
+              that  references this load balancer will not be applied for this
+              load balancer.
+
+       options : add_route: optional string
+              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  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 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
+              option,  if  not  specified,  is reachable for regular load balā€
+              ancers and none for template load balancers.
+
+       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ā€ā€
+              plate_Var in their definitions.
+
+              Load balancer template VIP supported formats are:
+
+              ^VIP_VAR[:^PORT_VAR|:port]
+
+
+              where VIP_VAR and PORT_VAR are keys of the  Chassis_Template_Var
+              variables records.
+
+              Note: The VIP and PORT cannot be combined into a single template
+              variable. For example, a Chassis_Template_Var variable expanding
+              to 10.0.0.1:8080 is not valid if used as VIP.
+
+              Load balancer template backend supported formats are:
+
+              ^BACKEND_VAR1[:^PORT_VAR1|:port],^BACKEND_VAR2[:^PORT_VAR2|:port]
+              or
+              ^BACKENDS_VAR1,^BACKENDS_VAR2
+
+
+              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,
+              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ā€
+              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 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:
+       name                          string (must be unique within table)
+       load_balancer                 set of weak reference to Load_Balancers
+
+   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
+              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.
+
+   Summary:
+       vip                           string
+       Health check options:
+         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
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       vip: string
+              vip whose endpoints should be monitored for health check.
+
+     Health check options:
+
+       options : interval: optional string, containing an integer
+              The interval, in seconds, between health checks.
+
+       options : timeout: optional string, containing an integer
+              The time, in seconds, after which a health check times out.
+
+       options : success_count: optional string, containing an integer
+              The number of successful checks after which the endpoint is conā€
+              sidered online.
+
+       options : failure_count: optional string, containing an integer
+              The number of failure checks after which the endpoint is considā€
+              ered offline.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+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
+       match, and deny as action.)
+
+   Summary:
+       label                         integer, in range 0 to 4,294,967,295
+       priority                      integer, in range 0 to 32,767
+       direction                     string, either from-lport or to-lport
+       match                         string
+       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:
+         log                         boolean
+         name                        optional string, at  most  63  characters
+                                     long
+         severity                    optional  string,  one  of  alert, debug,
+                                     info, notice, or warning
+         meter                       optional string
+       Common Columns:
+         options                     map of string-string pairs
+         ACL configuration options:
+            options : log-related    optional string
+         external_ids                map of string-string pairs
+
+   Details:
+       label: integer, in range 0 to 4,294,967,295
+              Associates an identifier with the ACL. The same  value  will  be
+              written  to  corresponding  connection  tracker entry. The value
+              should be a valid 32-bit unsigned integer. This value  can  help
+              in  debugging from connection tracker side. For example, through
+              this "label" we can backtrack to the ACL rule which is causing a
+              "leaked" connection. Connection tracker entries are created only
+              for allowed connections so the label is valid only for allow and
+              allow-related actions.
+
+       priority: integer, in range 0 to 32,767
+              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.
+
+              Return traffic from an allow-related flow is always allowed  and
+              cannot be changed through an ACL.
+
+              allow-stateless  flows  always  take  precedence before 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 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 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
+              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
+              ARP and IPv6 neighbor discovery packets.
+
+              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,
+       pass, or reject
+              The action to take when the ACL rule matches:
+
+              ā€¢      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
+                     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  exā€
+                     ist  on the logical switch. Otherwise, itā€™s equivalent to
+                     allow-stateless.
+
+              ā€¢      allow-related: Forward the  packet  and  related  traffic
+                     (e.g. inbound replies to an outbound connection).
+
+              ā€¢      drop: Silently drop the packet.
+
+              ā€¢      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.
+
+       options : apply-after-lb: optional string
+              If  set  to  true,  the ACL will be applied after load balancing
+              stage. Supported only for from-lport direction.
+
+              The main use case of this option is to support ACLs matching  on
+              the  destination IP address of the packet for the backend IPs of
+              load balancers.
+
+              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 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
+       ACL.
+
+       log: boolean
+              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.
+
+              If set to false, the remaining columns in  this  group  have  no
+              significance.
+
+       name: optional string, at most 63 characters long
+              This  name,  if  it  is provided, is included in log records. It
+              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ā€ā€
+       ing
+              The severity of the ACL. The severity levels match those of sysā€
+              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 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
+              options are described individually below.
+
+     ACL configuration options:
+
+       options : log-related: optional string
+              If set to true, then log when reply or related traffic is admitā€
+              ted from a stateful ACL. In order for this option  to  function,
+              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 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.
+
+Logical_Router TABLE
+       Each row represents one L3 logical router.
+
+   Summary:
+       ports                         set of Logical_Router_Ports
+       static_routes                 set of Logical_Router_Static_Routes
+       policies                      set of Logical_Router_Policys
+       enabled                       optional boolean
+       nat                           set of NATs
+       load_balancer                 set of weak reference to Load_Balancers
+       load_balancer_group           set of Load_Balancer_Groups
+       Naming:
+         name                        string
+         external_ids : neutron:router_name
+                                     optional string
+       copp                          optional weak reference to Copp
+       Options:
+         options : chassis           optional string
+         options : dnat_force_snat_ip
+                                     optional string
+         options : lb_force_snat_ip  optional string
+         options : mcast_relay       optional string, either true or false
+         options : dynamic_neigh_routers
+                                     optional string, either true or false
+         options : always_learn_from_arp_request
+                                     optional string, either true or false
+         options : requested-tnl-key
+                                     optional string, containing  an  integer,
+                                     in range 1 to 16,777,215
+         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
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       ports: set of Logical_Router_Ports
+              The routerā€™s ports.
+
+       static_routes: set of Logical_Router_Static_Routes
+              Zero or more static routes for the router.
+
+       policies: set of Logical_Router_Policys
+              Zero or more routing policies for the router.
+
+       enabled: optional boolean
+              This  column  is  used  to administratively set router state. If
+              this column is empty or is set to true, the router  is  enabled.
+              If  this  column is set to false, the router is disabled. A disā€
+              abled router has all ingress and egress traffic dropped.
+
+       nat: set of NATs
+              One or more NAT rules for the router. NAT  rules  only  work  on
+              Gateway  routers,  and  on distributed routers with one and only
+              one distributed gateway port.
+
+       load_balancer: set of weak reference to Load_Balancers
+              Set of load balancers associated to this  logical  router.  Load
+              balancer Load balancer rules only work on the Gateway routers or
+              routers with one and only one distributed gateway port.
+
+       load_balancer_group: set of Load_Balancer_Groups
+              Set of load balancers groups associated to this logical router.
+
+     Naming:
+
+       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ā€
+       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ā€ā€
+       tron:router_name. Perhaps this can be cleaned up someday.)
+
+       name: string
+              A name for the logical router.
+
+       external_ids : neutron:router_name: optional string
+              Another name for the logical router.
+
+       copp: optional weak reference to Copp
+              The control plane protection policy from table Copp used for meā€
+              tering packets sent to ovn-controller from logical ports of this
+              router.
+
+     Options:
+
+       Additional options for the logical router.
+
+       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ā€ā€
+              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ā€
+              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ā€
+              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.
+              This option may have exactly one IPv4 and/or one IPv6 address on
+              it, separated by a a space.
+
+       options : lb_force_snat_ip: optional string
+              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 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ā€
+              anced packet is SNATed with the IP of router port  (attached  to
+              the gateway router) selected as the destination after taking the
+              routing decision.
+
+       options : mcast_relay: optional string, either true or false
+              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 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
+              will prevent the automatic creation of these logical flows.
+
+       options : always_learn_from_arp_request: optional string, either true
+       or false
+              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
+              binding entry.
+
+              false - If there is a MAC binding for that IP  and  the  MAC  is
+              different,  or, if TPA of ARP request belongs to any router port
+              on this router, then update/add that MAC-IP binding.  Otherwise,
+              donā€™t update/add entries.
+
+              It  is true by default. It is recommended to set to false when a
+              large number of logical routers are connected to the same  logiā€
+              cal  switch  but most of them never need to send traffic between
+              each other, to reduce the size of the MAC binding 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,
+              ovn-northd honors the configured value.
+
+       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
+              sources can make use of the same conntrack zone.
+
+       options : mac_binding_age_threshold: optional string, containing an inā€
+       teger, in range 0 to 4,294,967,295
+              MAC  binding  aging  threshold value in seconds. MAC binding exā€
+              ceeding this timeout will be automatically  removed.  The  value
+              defaults to 0, which means disabled.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              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
+       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. 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
+       bandwidth                     map of string-integer pairs,  key  either
+                                     burst  or  rate,  value  in  range  1  to
+                                     4,294,967,295
+       external_ids                  map of string-string pairs
+
+   Details:
+       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
+              packet is undefined.
+
+       direction: string, either from-lport or to-lport
+              The value of this field is similar to  ACL  column  in  the  OVN
+              Northbound databaseā€™s ACL table.
+
+       match: string
+              The packets that the QoS rules should match, in the same expresā€
+              sion  language  used  for the match column in the OVN Southbound
+              databaseā€™s Logical_Flow table. The outport logical port is  only
+              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.
+
+              ā€¢      dscp: The value of this action should be in the range  of
+                     0 to 63 (inclusive).
+
+       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.
+
+              ā€¢      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
+       the Logical_Switch_Port table.
+
+   Summary:
+       name                          string (must be unique within table)
+       filter                        string,  one  of  both,  from-lport,   or
+                                     to-lport
+       sink                          string
+       type                          string, one of erspan, gre, or local
+       index                         integer
+       external_ids                  map of string-string pairs
+
+   Details:
+       name: string (must be unique within table)
+              Represents the name of the mirror.
+
+       filter: string, one of both, from-lport, or to-lport
+              The  value  of  this  field represents selection criteria of the
+              mirror. to-lport mirrors the packets coming into  logical  port.
+              from-lport  mirrors  the packets going out of logical port. both
+              mirrors for both directions.
+
+       sink: string
+              The value of this field represents the destination/sink  of  the
+              mirror.  If  the  type is gre or erspan, the value indicates the
+              tunnel remote IP (either IPv4 or IPv6). For  a  type  of  local,
+              this  field  defines  a  local  interface on the OVS integration
+              bridge to be used as the mirror destination. The interface  must
+              possess external-ids:mirror-id that matches this string.
+
+       type: string, one of erspan, gre, 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. 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
+       rate-limiting.
+
+   Summary:
+       name                          string (must be unique within table)
+       unit                          string, either kbps or pktps
+       bands                         set of 1 or more Meter_Bands
+       fair                          optional boolean
+       external_ids                  map of string-string pairs
+
+   Details:
+       name: string (must be unique within table)
+              A name for this meter.
+
+              Names that begin with "__" (two underscores)  are  reserved  for
+              OVN internal use and should not be added manually.
+
+       unit: string, either kbps or pktps
+              The  unit for rate and burst_rate parameters in the bands entry.
+              kbps specifies kilobits per second, and pktps specifies  packets
+              per second.
+
+       bands: set of 1 or more Meter_Bands
+              The bands associated with this meter. Each band specifies a rate
+              above  which  the band is to take the action action. If multiple
+              bandsā€™ rates are exceeded, then the band with the  highest  rate
+              among the exceeded bands is selected.
+
+       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
+              rate-limited on its own.
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+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
+       referenced by the bands column in the Meter table.
+
+   Summary:
+       action                        string, must be drop
+       rate                          integer, in range 1 to 4,294,967,295
+       burst_size                    integer, in range 0 to 4,294,967,295
+       external_ids                  map of string-string pairs
+
+   Details:
+       action: string, must be drop
+              The action to execute when this band matches. The only supported
+              action is drop.
+
+       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ā€
+              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
+              free to select some reasonable value depending on its configuraā€
+              tion.
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+Logical_Router_Port TABLE
+       A port within an L3 logical router.
+
+       Exactly one Logical_Router row must reference a  given  logical  router
+       port.
+
+   Summary:
+       name                          string (must be unique within table)
+       networks                      set of 1 or more strings
+       mac                           string
+       enabled                       optional boolean
+       Distributed Gateway Ports:
+         ha_chassis_group            optional HA_Chassis_Group
+         gateway_chassis             set of Gateway_Chassises
+         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ā€ā€
+                                     lay
+       ipv6_prefix                   set of strings
+       ipv6_ra_configs:
+         ipv6_ra_configs : address_mode
+                                     optional string
+         ipv6_ra_configs : router_preference
+                                     optional string
+         ipv6_ra_configs : route_info
+                                     optional string
+         ipv6_ra_configs : mtu       optional string
+         ipv6_ra_configs : send_periodic
+                                     optional string
+         ipv6_ra_configs : max_interval
+                                     optional string
+         ipv6_ra_configs : min_interval
+                                     optional string
+         ipv6_ra_configs : rdnss     optional string
+         ipv6_ra_configs : dnssl     optional string
+       Options:
+         options : mcast_flood       optional string, either true or false
+         options : requested-tnl-key
+                                     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,
+                                     in range 68 to 65,535
+         options : gateway_mtu_bypass
+                                     optional string
+       Attachment:
+         peer                        optional string
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       name: string (must be unique within table)
+              A name for the logical router port.
+
+              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
+              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
+              routed to this port.
+
+              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.
+
+       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
+              has all ingress and egress traffic dropped.
+
+     Distributed Gateway Ports:
+
+       Gateways,  as  documented under Gateways in the OVN architecture guide,
+       provide limited connectivity  between  logical  networks  and  physical
+       ones.  OVN  support multiple kinds of gateways. The Logical_Router_Port
+       table can be used two different ways to configure  distributed  gateway
+       ports,  which are one kind of gateway. These two forms of configuration
+       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
+       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
+       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
+       manner on the gateway chassis.
+
+       There can be more than one distributed gateway ports configured on each
+       logical router, each connecting to different L2 segments.  Load-balancā€
+       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ā€ā€
+       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
+       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-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
+       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ā€ā€
+       way-chassis lrp chassis.
+
+       ha_chassis_group: optional HA_Chassis_Group
+              Designates an HA_Chassis_Group to provide  gateway  high  availā€
+              ability.
+
+       gateway_chassis: set of Gateway_Chassises
+              Designates  one  or  more Gateway_Chassis for the logical router
+              port.
+
+     Options for Physical VLAN MTU Issues:
+
+       MTU issues arise in mixing  tunnels  with  logical  networks  that  are
+       bridged  to  a physical VLAN. For an explanation of the MTU issues, see
+       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
+       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
+       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
+              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,
+                     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
+                     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
+              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
+              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 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 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
+              router according to RFC 3633
+
+     ipv6_ra_configs:
+
+       This column defines the IPv6 ND RA address mode and ND MTU Option to be
+       included by ovn-controller when it replies to the IPv6 Router solicitaā€
+       tion requests.
+
+       ipv6_ra_configs : address_mode: optional string
+              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
+                     in the RAā€™s ICMPv6 option - Prefix information.
+
+              ā€¢      dhcpv6_stateful: Address configuration using 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
+
+              ā€¢      MEDIUM: mapped to 0x00 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
+              Advertisement according to RFC 4191. Route Info is a comma sepaā€
+              rated string where each field provides  PRF  and  prefix  for  a
+              given route (e.g: HIGH-aef1::11/48,LOW-aef2::11/96) Possible PRF
+              values are:
+
+              ā€¢      HIGH: mapped to 0x01 in RA PRF field
+
+              ā€¢      MEDIUM: mapped to 0x00 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ā€
+              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  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ā€ā€
+              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ā€ā€
+              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 moā€
+              ment OVN supports just one RDNSS server.
+
+       ipv6_ra_configs : dnssl: optional string
+              DNS  Search  List  announced  in RA packets. Multiple DNS Search
+              List must be ā€™commaā€™ separated (e.g. "a.b.c, d.e.f")
+
+     Options:
+
+       Additional options for the logical router port.
+
+       options : mcast_flood: optional string, either true or false
+              If set to true, multicast traffic (including reports) are unconā€
+              ditionally forwarded to the specific port.
+
+              This option applies when the port is part of  a  logical  router
+              which has options:mcast_relay set to true.
+
+              Default: false.
+
+       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.
+
+       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
+              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  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
+              have higher priority than routes with route_table option set.
+
+       options : gateway_mtu: optional string, containing an integer, in range
+       68 to 65,535
+              If set, logical flows will be added to router pipeline to  check
+              packet  length.  If packet length is greater than the value set,
+              ICMPv4 type 3 (Destination Unreachable)  code  4  (Fragmentation
+              Needed  and Donā€™t Fragment was Set) or ICMPv6 type 2 (Packet Too
+              Big) code 0 (no route to destination) packets will be generated.
+              This allows for Path MTU Discovery.
+
+       options : gateway_mtu_bypass: optional string
+              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ā€ā€
+                     cal_Switch_Port. In this case peer column is empty.
+
+              ā€¢      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
+                     other in its peer column. No Logical_Switch refers to the
+                     router port.
+
+       peer: optional string
+              For  a  router  port  used  to connect two logical routers, this
+              identifies the other router port in the pair by name.
+
+              For a router port attached to a logical switch, this  column  is
+              empty.
+
+     Common Columns:
+
+       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ā€ā€
+              nal_ids column of the Port_Binding table in OVN_Southbound dataā€
+              base.
+
+Logical_Router_Static_Route TABLE
+       Each record represents a static route.
+
+       When multiple routes match a packet, the longest-prefix match  is  choā€
+       sen.  For  a  given  prefix  length, a dst-ip route is preferred over a
+       src-ip route.
+
+       When there are ECMP routes, i.e. multiple routes with same  prefix  and
+       policy,  one  of  them will be selected based on the 5-tuple hashing of
+       the packet header.
+
+   Summary:
+       ip_prefix                     string
+       policy                        optional string, either dst-ip or src-ip
+       nexthop                       string
+       output_port                   optional string
+       bfd                           optional weak reference to BFD
+       route_table                   string
+       external_ids : ic-learned-route
+                                     optional string
+       Common Columns:
+         external_ids                map of string-string pairs
+       Common options:
+         options                     map of string-string pairs
+         options : ecmp_symmetric_reply
+                                     optional string
+         options : origin            optional string
+
+   Details:
+       ip_prefix: string
+              IP prefix of this route (e.g. 192.168.100.0/24).
+
+       policy: optional string, either dst-ip or src-ip
+              If it is specified, this setting describes the  policy  used  to
+              make  routing decisions. This setting must be one of the followā€
+              ing strings:
+
+              ā€¢      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
+                     the packetā€™s destination IP address matches ip_prefix.
+
+              If not specified, the default is dst-ip.
+
+       nexthop: string
+              Nexthop IP address for this route. Nexthop IP address should  be
+              the IP address of a connected router port or the IP address of a
+              logical port or can be set to discard for dropping packets which
+              match the given route.
+
+       output_port: optional string
+              The  name  of the Logical_Router_Port via which the packet needs
+              to be sent out. This is optional and  when  not  specified,  OVN
+              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ā€ā€
+              thop is reachable.
+
+       bfd: optional weak reference to BFD
+              Reference to BFD row if the route has associated a BFD session
+
+       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 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
+                     networks.
+
+              ā€¢      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_Southbound database.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+     Common options:
+
+       options: map of string-string pairs
+              This column provides general key/value settings.  The  supported
+              options are described individually below.
+
+       options : ecmp_symmetric_reply: optional string
+              If true, then new traffic that arrives over this route will have
+              its  reply  traffic bypass ECMP route selection and will be sent
+              out this route instead. Note  that  this  option  overrides  any
+              rules  set  in the Logical_Router_policy table. This option only
+              works on gateway  routers  (routers  that  have  options:chassis
+              set).
+
+       options : origin: optional string
+              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ā€ā€
+              cal_Router_Static_Route  records with same ip_prefix within same
+              Logical Router will have next lookup order based on  origin  key
+              value:
+
+              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
+       match, and drop as action.)
+
+   Summary:
+       priority                      integer, in range 0 to 32,767
+       match                         string
+       action                        string, one of allow, drop, or reroute
+       nexthop                       optional string
+       nexthops                      set of strings
+       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
+              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ā€
+              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
+              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.
+
+              ā€¢      drop: Silently drop the packet.
+
+              ā€¢      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 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
+              address of a logical port.
+
+              One IP from the list is selected as next hop.
+
+       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 deā€
+              cisions  if desired. This value is not preserved when the packet
+              goes out on the wire.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+NAT TABLE
+       Each record represents a NAT rule.
+
+   Summary:
+       type                          string, one of  dnat,  dnat_and_snat,  or
+                                     snat
+       external_ip                   string
+       external_mac                  optional string
+       external_port_range           string
+       logical_ip                    string
+       logical_port                  optional string
+       allowed_ext_ips               optional Address_Set
+       exempted_ext_ips              optional Address_Set
+       gateway_port                  optional    weak   reference   to   Logiā€ā€
+                                     cal_Router_Port
+       options : stateless           optional string
+       options : add_route           optional string
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       type: string, one of dnat, dnat_and_snat, or snat
+              Type of the NAT rule.
+
+              ā€¢      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  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 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.
+
+       external_mac: optional string
+              A MAC address.
+
+              This is only used on the gateway port  on  distributed  routers.
+              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  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ā€ā€
+              ical_port is globally unique, then that MAC address can be specā€
+              ified as this external_mac.
+
+       external_port_range: string
+              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 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"
+
+              Valid range of ports is 1-65535.
+
+       logical_ip: string
+              An IPv4 network (e.g 192.168.1.0/24) or an IPv4 address.
+
+       logical_port: optional string
+              The name of the logical port where the logical_ip resides.
+
+              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
+              chassis.
+
+       allowed_ext_ips: optional Address_Set
+              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ā€
+              tion,  NAT  happens  without  considering  the  external IP (i.e
+              dest/source for snat/dnat type rule).  With  this  configuration
+              NAT  rule is applied ONLY if external ip is in the input Address
+              Set.
+
+       exempted_ext_ips: optional Address_Set
+              It represents Address Set of external ips that NAT rule  is  NOT
+              applicable  to. For SNAT type NAT rules, this refers to destinaā€
+              tion addresses. For DNAT type NAT rules, this refers  to  source
+              addresses.
+
+              This  configuration overrides the default NAT behavior of applyā€
+              ing a rule solely based on internal IP. Without this  configuraā€
+              tion,  NAT  happens  without  considering  the  external IP (i.e
+              dest/source for snat/dnat type rule).  With  this  configuration
+              NAT  rule  is NOT applied if external ip is in the input Address
+              Set.
+
+              If there are NAT rules in a logical router with  overlapping  IP
+              prefixes  (including /32), then usage of exempted_ext_ips should
+              be avoided in following scenario.  a.  SNAT  rule  (let  us  say
+              RULE1)  with logical_ip PREFIX/MASK (let us say 50.0.0.0/24). b.
+              SNAT rule (let us say RULE2) with logical_ip PREFIX/MASK+1  (let
+              us  say  50.0.0.0/25). c. Now, if exempted_ext_ips is associated
+              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
+              NAT rule is not considered.
+
+       gateway_port: optional weak reference to Logical_Router_Port
+              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ā€ā€
+              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
+              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 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
+              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 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:
+
+       external_ids: map of string-string pairs
+              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 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:
+       cidr                          string
+       DHCPv4 options:
+         Mandatory DHCPv4 options:
+            options : server_id      optional string
+            options : server_mac     optional string
+            options : lease_time     optional  string,  containing an integer,
+                                     in range 0 to 4,294,967,295
+         IPv4 DHCP Options:
+            options : router         optional string
+            options : netmask        optional string
+            options : dns_server     optional string
+            options : log_server     optional string
+            options : lpr_server     optional string
+            options : swap_server    optional string
+            options : policy_filter  optional string
+            options : router_solicitation
+                                     optional string
+            options : nis_server     optional string
+            options : ntp_server     optional string
+            options : netbios_name_server
+                                     optional string
+            options : classless_static_route
+                                     optional string
+            options : ms_classless_static_route
+                                     optional string
+            options : next_server    optional string
+         Boolean DHCP Options:
+            options : ip_forward_enable
+                                     optional string, either 0 or 1
+            options : router_discovery
+                                     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,
+                                     in range 0 to 255
+            options : tcp_ttl        optional  string,  containing an integer,
+                                     in range 0 to 255
+            options : mtu            optional string, containing  an  integer,
+                                     in range 68 to 65,535
+            options : T1             optional  string,  containing an integer,
+                                     in range 68 to 4,294,967,295
+            options : T2             optional string, containing  an  integer,
+                                     in range 68 to 4,294,967,295
+            options : arp_cache_timeout
+                                     optional  string,  containing an integer,
+                                     in range 0 to 255
+            options : tcp_keepalive_interval
+                                     optional string, containing  an  integer,
+                                     in range 0 to 255
+            options : netbios_node_type
+                                     optional  string,  containing an integer,
+                                     in range 0 to 255
+         String DHCP Options:
+            options : wpad           optional string
+            options : bootfile_name  optional string
+            options : path_prefix    optional string
+            options : tftp_server_address
+                                     optional string
+            options : hostname       optional string
+            options : domain_name    optional string
+            options : bootfile_name_alt
+                                     optional string
+            options : broadcast_address
+                                     optional string
+         DHCP Options of type host_id:
+            options : tftp_server    optional string
+          DHCP Options of type domains:
+            options : domain_search_list
+                                     optional string
+       DHCPv6 options:
+         Mandatory DHCPv6 options:
+            options : server_id      optional string
+         IPv6 DHCPv6 options:
+            options : dns_server     optional string
+         String DHCPv6 options:
+            options : domain_search  optional string
+            options : dhcpv6_stateless
+                                     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
+              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
+       to an entry in this table.
+
+     Mandatory DHCPv4 options:
+
+       The following options must be defined.
+
+       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  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
+       0 to 4,294,967,295
+              The offered lease time in seconds,
+
+              The DHCPv4 option code for this option is 51.
+
+     IPv4 DHCP Options:
+
+       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
+              this option is 3.
+
+       options : netmask: optional string
+              The DHCPv4 option code for this option is 1.
+
+       options : dns_server: optional string
+              The DHCPv4 option code for this option is 6.
+
+       options : log_server: optional string
+              The DHCPv4 option code for this option is 7.
+
+       options : lpr_server: optional string
+              The DHCPv4 option code for this option is 9.
+
+       options : swap_server: optional string
+              The DHCPv4 option code for this option is 16.
+
+       options : policy_filter: optional string
+              The DHCPv4 option code for this option is 21.
+
+       options : router_solicitation: optional string
+              The DHCPv4 option code for this option is 32.
+
+       options : nis_server: optional string
+              The DHCPv4 option code for this option is 41.
+
+       options : ntp_server: optional string
+              The DHCPv4 option code for this option is 42.
+
+       options : netbios_name_server: optional string
+              The DHCPv4 option code for this option is 44.
+
+       options : classless_static_route: optional string
+              The DHCPv4 option code for this option is 121.
+
+              This option can contain one or more static routes, each of which
+              consists of a destination descriptor and the IP address  of  the
+              router that should be used to reach that destination. Please see
+              RFC 3442 for more details.
+
+              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
+              similar to classless_static_route supported by Microsoft Windows
+              DHCPv4 clients.
+
+       options : next_server: optional string
+              The DHCPv4 option code for setting the "Next server IP  address"
+              field in the DHCP header.
+
+     Boolean DHCP Options:
+
+       These options accept a Boolean value, expressed as 0 for false or 1 for
+       true.
+
+       options : ip_forward_enable: optional string, either 0 or 1
+              The DHCPv4 option code for this option is 19.
+
+       options : router_discovery: optional string, either 0 or 1
+              The DHCPv4 option code for this option is 31.
+
+       options : ethernet_encap: optional string, either 0 or 1
+              The DHCPv4 option code for this option is 36.
+
+     Integer DHCP Options:
+
+       These options accept a nonnegative integer value.
+
+       options : default_ttl: optional string, containing an integer, in range
+       0 to 255
+              The DHCPv4 option code for this option is 23.
+
+       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
+       65,535
+              The DHCPv4 option code for this option is 26.
+
+       options : T1: 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 renew its address. The DHCPv4 option
+              code for this option is 58.
+
+       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 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ā€
+       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
+              a keepalive message on a TCP connection.
+
+       options : netbios_node_type: optional string, containing an integer, in
+       range 0 to 255
+              The DHCPv4 option code for this option is 46.
+
+     String DHCP Options:
+
+       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
+              web proxy.
+
+       options : bootfile_name: optional string
+              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 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ā€
+              tains  one  or more IPv4 addresses that the client MAY use. This
+              option is Cisco proprietary, the IEEE standard that matches with
+              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ā€ā€
+              cal_Switch_Port takes precedence.
+
+       options : domain_name: optional string
+              The DHCPv4 option code for this option is 15. This option speciā€
+              fies the domain name that client should use when resolving hostā€
+              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" 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"
+              will be used.
+
+       options : broadcast_address: optional string
+              The DHCPv4 option code for this option is 28. This option speciā€
+              fies the IP address used as a broadcast address.
+
+     DHCP Options of type host_id:
+
+       These options accept either an IPv4 address or a string value.
+
+       options : tftp_server: optional string
+              The DHCPv4 option code for this option is 66.
+
+      DHCP Options of type domains:
+
+       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
+              The DHCPv4 option code for this option is 119.
+
+     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/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
+              [DUID-LL].
+
+     IPv6 DHCPv6 options:
+
+       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
+              The DHCPv6 option code for this option is 23. This option speciā€
+              fies the DNS servers that the VM should use.
+
+     String DHCPv6 options:
+
+       These options accept string values.
+
+       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
+              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 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.
+
+     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
+       (OVSDB) client.
+
+       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ā€
+       tions.
+
+   Summary:
+       Core Features:
+         target                      string (must be unique within table)
+       Client Failure Detection and Handling:
+         max_backoff                 optional integer, at least 1,000
+         inactivity_probe            optional integer
+       Status:
+         is_connected                boolean
+         status : last_error         optional string
+         status : state              optional  string, one of ACTIVE, BACKOFF,
+                                     CONNECTING, IDLE, or VOID
+         status : sec_since_connect  optional string, containing  an  integer,
+                                     at least 0
+         status : sec_since_disconnect
+                                     optional  string,  containing an integer,
+                                     at least 0
+         status : locks_held         optional string
+         status : locks_waiting      optional string
+         status : locks_lost         optional string
+         status : n_connections      optional string, containing  an  integer,
+                                     at least 2
+         status : bound_port         optional string, containing an integer
+       Common Columns:
+         external_ids                map of string-string pairs
+         other_config                map of string-string pairs
+
+   Details:
+     Core Features:
+
+       target: string (must be unique within table)
+              Connection methods for clients.
+
+              The following connection methods are currently supported:
+
+              ssl:host[:port]
+                     The  specified  SSL  port  on the host at the given host,
+                     which can either be a DNS name (if built with unbound 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.
+
+                     If port is not specified, it defaults to 6640.
+
+                     SSL  support  is  an  optional feature that is not always
+                     built as part of Open vSwitch.
+
+              tcp:host[:port]
+                     The specified TCP port on the host  at  the  given  host,
+                     which can either be a DNS name (if built with unbound 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.
+
+              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  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
+                     then  it listens only on IPv4 (but not IPv6) addresses. A
+                     valid SSL configuration must be provided when  this  form
+                     is  used,  this  can be specified either via command-line
+                     options or the SSL table.
+
+                     If port is not specified, it defaults to 6640.
+
+                     SSL support is an optional feature  that  is  not  always
+                     built as part of Open vSwitch.
+
+              ptcp:[port][:host]
+                     Listens  for connections on the specified TCP port. 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  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
+              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  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
+              inactivity probes.
+
+     Status:
+
+       Key-value pair of is_connected is always updated. Other key-value pairs
+       in the status columns may be updated depends on the target type.
+
+       When target specifies a connection method that listens for inbound conā€
+       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ā€
+       ted.
+
+       is_connected: boolean
+              true if currently connected to this client, false otherwise.
+
+       status : last_error: optional string
+              A human-readable description of the last error on the connection
+              to  the  manager; i.e. strerror(errno). This key will exist only
+              if an error has occurred.
+
+       status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
+       IDLE, or VOID
+              The state of the connection to the manager:
+
+              VOID   Connection is disabled.
+
+              BACKOFF
+                     Attempting to reconnect at an increasing period.
+
+              CONNECTING
+                     Attempting to connect.
+
+              ACTIVE Connected, remote host responsive.
+
+              IDLE   Connection is idle. Waiting for response to keep-alive.
+
+              These values may change in the future. They  are  provided  only
+              for human consumption.
+
+       status : sec_since_connect: optional string, containing an integer, at
+       least 0
+              The amount of time since this client last successfully connected
+              to the database (in seconds). Value is empty if client has never
+              successfully been connected.
+
+       status : sec_since_disconnect: optional string, containing an integer,
+       at least 0
+              The  amount of time since this client last disconnected from the
+              database (in seconds). Value is empty if client has  never  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
+              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ā€
+              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
+              locks have been stolen from this connection.
+
+       status : n_connections: optional string, containing an integer, at
+       least 2
+              When  target  specifies a connection method that listens for 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
+              available port.)
+
+     Common Columns:
+
+       The overall purpose of these columns is described under Common  Columns
+       at the beginning of this document.
+
+       external_ids: map of string-string pairs
+
+       other_config: map of string-string pairs
+DNS TABLE
+       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
+       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  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"
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+SSL TABLE
+       SSL configuration for ovn-nb database access.
+
+   Summary:
+       private_key                   string
+       certificate                   string
+       ca_cert                       string
+       bootstrap_ca_cert             boolean
+       ssl_protocols                 string
+       ssl_ciphers                   string
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       private_key: string
+              Name of a PEM file  containing  the  private  key  used  as  the
+              switchā€™s identity for SSL connections to the controller.
+
+       certificate: string
+              Name  of a PEM file containing a certificate, signed by the cerā€
+              tificate authority (CA) used by the controller and manager, that
+              certifies the switchā€™s private key,  identifying  a  trustworthy
+              switch.
+
+       ca_cert: string
+              Name  of a PEM file containing the CA certificate used to verify
+              that the switch is connected to a trustworthy controller.
+
+       bootstrap_ca_cert: boolean
+              If set to true, then Open vSwitch will attempt to obtain the  CA
+              certificate  from the controller on its first SSL connection and
+              save it to the named PEM file. If it is successful, it will  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 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
+              omitted is HIGH:!aNULL:!MD5.
+
+     Common Columns:
+
+       The overall purpose of these columns is described under Common  Columns
+       at the beginning of this document.
+
+       external_ids: map of string-string pairs
+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
+       a set of them in high availability configurations.
+
+   Summary:
+       name                          string (must be unique within table)
+       chassis_name                  string
+       priority                      integer, in range 0 to 32,767
+       options                       map of string-string pairs
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       name: string (must be unique within table)
+              Name of the Gateway_Chassis.
+
+              A   suggested,   but   not   required   naming   convention   is
+              ${port_name}_${chassis_name}.
+
+       chassis_name: string
+              Name of the chassis that we want to redirect traffic through for
+              the  associated  logical  router  port. The value must match the
+              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  beā€
+              longing to the same logical router port.
+
+       options: map of string-string pairs
+              Reserved for future use.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+HA_Chassis_Group TABLE
+       Table representing a group of chassis which can provide high 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
+       this table, then the master HA chassis in this group provides the gateā€
+       way functionality.
+
+   Summary:
+       name                          string (must be unique within table)
+       ha_chassis                    set of HA_Chassises
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       name: string (must be unique within table)
+              Name of the HA_Chassis_Group. Name should be unique.
+
+       ha_chassis: set of HA_Chassises
+              A list of HA chassis which belongs to this group.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+HA_Chassis TABLE
+   Summary:
+       chassis_name                  string
+       priority                      integer, in range 0 to 32,767
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       chassis_name: string
+              Name of the chassis which is part of the HA chassis  group.  The
+              value  must  match  the  name column of the Chassis table in the
+              OVN_Southbound database.
+
+       priority: integer, in range 0 to 32,767
+              Priority of the chassis. Chassis with highest priority  will  be
+              the master.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+BFD TABLE
+       Contains  BFD  parameter  for ovn-controller BFD configuration. OVN BFD
+       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:
+       Configuration:
+         logical_port                string
+         dst_ip                      string
+         min_tx                      optional integer, at least 1
+         min_rx                      optional integer
+         detect_mult                 optional integer, at least 1
+         options                     map of string-string pairs
+         external_ids                map of string-string pairs
+       Status Reporting:
+         status                      optional string, one of admin_down, down,
+                                     init, or up
+
+   Details:
+     Configuration:
+
+       ovn-northd reads configuration from these columns.
+
+       logical_port: string
+              OVN logical port when BFD engine is running.
+
+       dst_ip: string
+              BFD peer IP address.
+
+       min_tx: optional integer, at least 1
+              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. Default
+              value is 1000 ms.
+
+       min_rx: optional integer
+              This is the minimum interval, in milliseconds, between  received
+              BFD  Control  packets that this system is capable of supporting,
+              less any jitter applied by the sender. If this  value  is  zero,
+              the  transmitting system does not want the remote system to send
+              any periodic BFD Control packets.
+
+       detect_mult: optional integer, at least 1
+              Detection time multiplier.  The  negotiated  transmit  interval,
+              multiplied  by  this  value, provides the Detection Time for the
+              receiving system in Asynchronous mode. Default value is 5.
+
+       options: map of string-string pairs
+              Reserved for future use.
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+     Status Reporting:
+
+       ovn-northd writes BFD status into these columns.
+
+       status: optional string, one of admin_down, down, init, or up
+              BFD port logical states. Possible values are:
+
+              ā€¢      admin_down
+
+              ā€¢      down
+
+              ā€¢      init
+
+              ā€¢      up
+Static_MAC_Binding TABLE
+       Each record represents a Static_MAC_Binding entry for a logical router.
+
+   Summary:
+       Configuration:
+         logical_port                string
+         ip                          string
+         mac                         string
+         override_dynamic_mac        boolean
+
+   Details:
+     Configuration:
+
+       ovn-northd reads configuration from these columns  and  propagates  the
+       value to SBDB.
+
+       logical_port: string
+              The logical router port for the binding.
+
+       ip: string
+              The bound IP address.
+
+       mac: string
+              The Ethernet address to which the IP is bound.
+
+       override_dynamic_mac: boolean
+              Override dynamically learnt MACs.
+
+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 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
+       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
+       just interpret it as a raw string literal.
+
+   Summary:
+       chassis                       string (must be unique within table)
+       variables                     map of string-string pairs
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       chassis: string (must be unique within table)
+              The chassis this set of variable values applies to.
+
+       variables: map of string-string pairs
+              The set of variable values for a given chassis.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+Open vSwitch 23.06.3            DB Schema 7.0.4                      ovn-nb(5)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-nb.5.pdf b/src/static/support/dist-docs-branch-23.06/ovn-nb.5.pdf new file mode 100644 index 00000000..58dca0ac Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-nb.5.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-nb.5.txt b/src/static/support/dist-docs-branch-23.06/ovn-nb.5.txt new file mode 100644 index 00000000..21f18325 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-nb.5.txt @@ -0,0 +1,4098 @@ +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 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 + 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 + 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ā€ + 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 + later page. + + Table Purpose + NB_Global Northbound configuration + Copp Control plane protection + Logical_Switch + L2 logical switch + Logical_Switch_Port + L2 logical switch port + Forwarding_Group + forwarding group + Address_Set + Address Sets + Port_Group + Port Groups + Load_Balancer + load balancer + Load_Balancer_Group + load balancer group + Load_Balancer_Health_Check + load balancer + ACL Access Control List (ACL) rule + Logical_Router + L3 logical router + QoS QoS rule + Mirror Mirror Entry + Meter Meter entry + Meter_Band + Band for meter entries + Logical_Router_Port + L3 logical router port + Logical_Router_Static_Route + Logical router static routes + Logical_Router_Policy + Logical router policies + NAT NAT rules + DHCP_Options + DHCP options + Connection + OVSDB client connections. + DNS Native DNS resolution + SSL SSL configuration. + Gateway_Chassis + Gateway_Chassis configuration. + HA_Chassis_Group + HA_Chassis_Group configuration. + HA_Chassis + HA_Chassis configuration. + BFD BFD configuration. + Static_MAC_Binding + Static_MAC_Binding configuration. + Chassis_Template_Var + Chassis_Template_Var configuration. + +NB_Global TABLE + Northbound configuration for an OVN system. This table must have exā€ + actly one row. + + Summary: + Identity: + name string + Status: + nb_cfg integer + nb_cfg_timestamp integer + sb_cfg integer + sb_cfg_timestamp integer + hv_cfg integer + hv_cfg_timestamp integer + Common Columns: + external_ids map of string-string pairs + Common options: + options map of string-string pairs + Options for configuring OVS BFD: + options : bfd-min-rx optional string + options : bfd-decay-min-rx + optional string + options : bfd-min-tx optional string + options : bfd-mult optional string + options : mac_prefix optional string + options : mac_binding_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 + optional string + options : ignore_lsp_down optional string + options : use_ct_inv_match optional string + options : default_acl_drop optional string + options : debug_drop_domain_id + optional string + options : debug_drop_collector_set + optional string + options : use_common_zone optional string, either true or false + Options for configuring interconnection route advertisement: + options : ic-route-adv optional string + options : ic-route-learn optional string + options : ic-route-adv-default + optional string + options : ic-route-learn-default + optional string + options : ic-route-blacklist + optional string + Connection Options: + connections set of Connections + ssl optional SSL + Security Configurations: + ipsec boolean + Read-only Options: + options : max_tunid optional string + + Details: + Identity: + + name: string + The name of the OVN cluster, which uniquely identifies the OVN + cluster throughout all OVN clusters supposed to interconnect + with each other. + + Status: + + These columns allow a client to track the overall configuration state + of the system. + + nb_cfg: integer + Sequence number for client to increment. When a client modifies + any part of the northbound database configuration and wishes to + wait for ovn-northd and possibly all of the hypervisors to finā€ + ish applying the changes, it may increment this sequence number. + + nb_cfg_timestamp: integer + The timestamp, in milliseconds since the epoch, when ovn-northd + sees the latest nb_cfg and starts processing. + + To print the timestamp as a human-readable date: + + 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 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 + finishes applying the corresponding configuration changes to the + OVN_Southbound database successfully. + + hv_cfg: integer + Sequence number that ovn-northd sets to the smallest sequence + number of all the chassis in the system, as reported in the + Chassis_Private table in the southbound database. Thus, hv_cfg + equals nb_cfg if all chassis are caught up with the northbound + configuration (which may never happen, if any chassis is down). + 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 + 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. + + hv_cfg_timestamp: integer + The largest timestamp, in milliseconds since the epoch, of the + smallest sequence number of all the chassis in the system, as + reported in the Chassis_Private table in the southbound dataā€ + base. In other words, this timestamp reflects the time when the + slowest chassis catches up with the northbound configuration, + which is useful for end-to-end control plane latency measureā€ + ment. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + + Common options: + + options: map of string-string pairs + This column provides general key/value settings. The supported + options are described individually below. + + Options for configuring OVS BFD: + + These options apply when ovn-controller configures OVS BFD on tunnels + interfaces. Please note these parameters refer to legacy OVS BFD impleā€ + 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 + interfaces. + + options : bfd-decay-min-rx: optional string + BFD option decay-min-rx value to use when configuring BFD on + tunnel interfaces. + + options : bfd-min-tx: optional string + BFD option min-tx value to use when configuring BFD on tunnel + interfaces. + + options : bfd-mult: optional string + BFD option mult value to use when configuring BFD on tunnel inā€ + terfaces. + + options : mac_prefix: optional string + 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 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 : controller_event: optional string, either true or false + 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ā€ā€ + 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 + + options : northd_probe_interval: optional string + The inactivity probe interval of the connection to the OVN + Northbound and Southbound databases from ovn-northd, in milā€ + liseconds. 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 : 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 + 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 + attached. + + options : use_parallel_build: optional string + If set to true, ovn-northd will attempt to compute logical flows + in parallel. + + Parallel computation is enabled only if the system has 4 or more + cores/threads available to be used by ovn-northd. + + 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 + 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ā€ + trol plane. The default value is true. + + options : use_ct_inv_match: optional string + If set to false, ovn-northd will not use the ct.inv field in any + of the logical flow matches. The default value is true. If the + NIC supports offloading OVS datapath flows but doesnā€™t support + 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 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 + 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 + observation_domain_id field will be the datapathā€™s key. + + The observation_point_id will be set to the first 32 bits of the + logical flowā€™s UUID. + + 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 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 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ā€ā€ + 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: + + 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 diā€ + rectly connected subnets on the router. + + 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ā€ā€ + 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. + + options : ic-route-adv: optional string + A boolean value that enables route advertisement to the global + OVN_IC_Southbound database. Default is false. + + options : ic-route-learn: optional string + A boolean value that enables route learning from the global + OVN_IC_Southbound database. Default is false. + + options : ic-route-adv-default: optional string + A boolean value that enables advertising default route to the + global OVN_IC_Southbound database. Default is false. This option + 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 + global OVN_IC_Southbound database. Default is false. This option + takes effect only when option ic-route-learn is true. + + options : ic-route-blacklist: optional string + A string value contains a list of CIDRs delimited by ",". A + route will not be advertised or learned if the routeā€™s prefix + belongs to any of the CIDRs listed. + + 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ā€ā€ + tion table for more information. + + ssl: optional SSL + Global SSL configuration. + + Security Configurations: + + ipsec: boolean + Tunnel encryption configuration. If this column is set to be + true, all OVN tunnels will be encrypted with IPsec. + + Read-only Options: + + options : max_tunid: optional string + The maximum supported tunnel ID. Depends on types of encapsulaā€ + tion enabled in the cluster. + +Copp TABLE + This table is used to define control plane protection policies, i.e., + associate entries from table Meter to control protocol names. + + Summary: + name string (must be unique within table) + meters : arp optional string + meters : arp-resolve optional string + meters : dhcpv4-opts optional string + meters : dhcpv6-opts optional string + meters : dns optional string + meters : event-elb optional string + meters : icmp4-error optional string + meters : icmp6-error optional string + meters : igmp optional string + meters : nd-na optional string + meters : nd-ns optional string + meters : nd-ns-resolve optional string + meters : nd-ra-opts optional string + 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: + name: string (must be unique within table) + CoPP name. + + meters : arp: optional string + Rate limiting meter for ARP packets (request/reply) used for + learning neighbors. + + meters : arp-resolve: optional string + Rate limiting meter for packets that require resolving the next- + hop (through ARP). + + meters : dhcpv4-opts: optional string + 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 opā€ + tions. + + meters : dns: optional string + 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 + ICMP error. + + meters : icmp6-error: optional string + 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 + for learning neighbors. + + meters : nd-ns: optional string + Rate limiting meter for ND neighbor solicitation packets used + for learning neighbors. + + meters : nd-ns-resolve: optional string + Rate limiting meter for packets that require resolving the next- + hop (through ND). + + meters : nd-ra-opts: optional string + Rate limiting meter for packets that require adding ND router + advertisement options. + + meters : tcp-reset: optional string + Rate limiting meter for packets that require replying with TCP + RST packet. + + meters : bfd: optional string + Rate limiting meter for BFD packets. + + 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 unā€ā€ + known. + + Summary: + ports set of Logical_Switch_Ports + load_balancer set of weak reference to Load_Balancers + load_balancer_group set of Load_Balancer_Groups + acls set of ACLs + qos_rules set of QoSes + dns_records set of weak reference to DNSes + forwarding_groups set of Forwarding_Groups + Naming: + name string + external_ids : neutron:network_name + optional string + IP Address Assignment: + other_config : subnet optional string + other_config : exclude_ips optional string + other_config : ipv6_prefix optional string + other_config : mac_only optional string, either true or false + IP Multicast Snooping Options: + other_config : mcast_snoop optional string, either true or false + other_config : mcast_querier + optional string, either true or false + other_config : mcast_flood_unregistered + optional string, either true or false + other_config : mcast_table_size + optional string, containing an integer, + in range 1 to 32,766 + other_config : mcast_idle_timeout + optional string, containing an integer, + in range 15 to 3,600 + other_config : mcast_query_interval + optional string, containing an integer, + in range 1 to 3,600 + other_config : mcast_query_max_response + optional string, containing an integer, + in range 1 to 10 + other_config : mcast_eth_src + optional string + other_config : mcast_ip4_src + optional string + other_config : mcast_ip6_src + optional string + Interconnection: + other_config : interconn-ts + optional string + Tunnel Key: + other_config : requested-tnl-key + optional string, containing an integer, + in range 1 to 16,777,215 + copp optional weak reference to Copp + 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 + + Details: + ports: set of Logical_Switch_Ports + The logical ports connected to the logical switch. + + It is an error for multiple logical switches to include the same + logical port. + + load_balancer: set of weak reference to Load_Balancers + Set of load balancers associated to this logical switch. + + load_balancer_group: set of Load_Balancer_Groups + Set of load balancers groups associated to this logical switch. + + acls: set of ACLs + 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 + logical switch. + + dns_records: set of weak reference to DNSes + 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 + Groups a set of logical port endpoints for traffic going out of + the logical switch. + + Naming: + + These columns provide names for the logical switch. From OVNā€™s perspecā€ + tive, these names have no special meaning or purpose other than to proā€ + vide convenience for human interaction with the database. There is no + requirement for the name to be unique. (For a unique identifier for a + 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ā€ā€ + work_name. Perhaps this can be cleaned up someday.) + + name: string + A name for the logical switch. + + external_ids : neutron:network_name: optional string + Another name for the logical switch. + + 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ā€ā€ + fig:subnet and optionally other_config:exclude_ips. To enable IPAM for + 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ā€ā€ + 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 + ovn-northd to automatically assign IP addresses within that subā€ + net. + + other_config : exclude_ips: optional string + To exclude some addresses from automatic IP address management, + set this to a list of the IPv4 addresses or ..-delimited ranges + to exclude. The addresses or ranges should be a subset of those + in other_config:subnet. + + Whether listed or not, ovn-northd will never allocate the first + or last address in a subnet, such as 192.168.0.0 or + 192.168.0.255 in 192.168.0.0/24. + + Examples: + + ā€¢ 192.168.0.2 192.168.0.10 + + ā€¢ 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.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 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:: + + ā€¢ bef0:1234:a890: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ā€ + net nor ipv6_prefix are specified + + 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_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. + Default: false. + + other_config : mcast_querier: optional string, either true or false + 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 + or false + 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ā€ + ger, in range 1 to 32,766 + Number of multicast groups to be stored. Default: 2048. + + other_config : mcast_idle_timeout: optional string, containing an inteā€ + ger, in range 15 to 3,600 + Configures the IP Multicast Snooping group idle timeout (in secā€ + onds). Default: 300 seconds. + + 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ā€ + ond. + + other_config : mcast_eth_src: optional string + Configures the source Ethernet address for queries originated by + the logical switch. + + other_config : mcast_ip4_src: optional string + Configures the source IPv4 address for queries originated by the + logical switch. + + other_config : mcast_ip6_src: optional string + Configures the source IPv6 address for queries originated by the + logical switch. + + Interconnection: + + other_config : interconn-ts: optional string + The name of corresponding transit switch in OVN_IC_Northbound + database. This kind of logical switch is created and controlled + by ovn-ic. + + Tunnel Key: + + 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ā€ + 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 + for interconnection: the tunnel keys for 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. + + copp: optional weak reference to Copp + 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 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 + 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 + See External IDs at the beginning of this document. + +Logical_Switch_Port TABLE + A port within an L2 logical switch. + + Summary: + Core Features: + name string (must be unique within table) + type string + Options: + options map of string-string pairs + Options for router ports: + options : router-port optional string + options : nat-addresses optional string + options : exclude-lb-vips-from-garp + optional string + options : arp_proxy optional string + Options for localnet ports: + options : network_name optional string + options : ethtype optional string + options : localnet_learn_fdb + optional string, either true or false + Options for l2gateway ports: + options : network_name optional string + options : l2gateway-chassis + optional string + Options for vtep ports: + options : vtep-physical-switch + optional string + options : vtep-logical-switch + optional string + VMI (or VIF) Options: + options : requested-chassis + optional string + options : activation-strategy + optional string + options : iface-id-ver optional string + options : qos_min_rate optional string + options : qos_max_rate optional string + options : qos_burst optional string + options : hostname optional string + VIF Plugging Options: + options : vif-plug-type + optional string + options : vif-plug-mtu-request + optional string + Virtual port Options: + options : virtual-ip optional string + options : virtual-parents + optional string + IP Multicast Snooping Options: + options : mcast_flood optional string, either true or false + options : mcast_flood_reports + optional string, either true or false + Containers: + parent_name optional string + tag_request optional integer, in range 0 to 4,095 + tag optional integer, in range 1 to 4,095 + Port State: + up optional boolean + enabled optional boolean + Addressing: + addresses set of strings + dynamic_addresses optional string + port_security set of strings + DHCP: + dhcpv4_options optional weak reference to DHCP_Options + dhcpv6_options optional weak reference to DHCP_Options + mirror_rules set of weak reference to Mirrors + ha_chassis_group optional HA_Chassis_Group + Naming: + external_ids : neutron:port_name + optional string + Tunnel Key: + options : requested-tnl-key + optional string, containing an integer, + in range 1 to 32,767 + Common Columns: + external_ids map of string-string pairs + + Details: + Core Features: + + 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ā€ā€ + 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. + + For containers that share a VIF within a VM, the name can be any + unique identifier. See Containers, below, for more information. + + A logical switch port may not have the same name as a logical + router port, but the database schema cannot enforce this. + + type: string + Specify a type for this logical port. Logical ports can be used + to model other types of connectivity into an OVN logical switch. + The following types are defined: + + (empty string) + A VM (or VIF) interface. + + 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 + 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 + 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 + hypervisor. + + l2gateway + A connection to a physical network. + + vtep A port to a logical switch on a VTEP gateway. + + external + Represents a logical port which is external and not havā€ + ing an OVS port in the integration bridge. OVN will never + receive any traffic from this port or send any traffic to + this port. OVN can support native services like + 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 + 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, + 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_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ā€ā€ + troller do not bind these ports and cannot serve + the native services. + + ā€¢ When CMS supports provisioning baremetal servers. + + virtual + Represents a logical port which does not have an OVS port + in the integration bridge and has a virtual ip configured + in the options:virtual-ip column. This virtual ip can + move around between the logical ports configured in the + options:virtual-parents column. + + One of the use case where virtual ports can be used is. + + ā€¢ 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 + 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 + below. + + Options for router ports: + + These options apply when type is router. + + options : router-port: optional string + Required. The name of the Logical_Router_Port to which this logā€ + ical switch port is connected. + + options : nat-addresses: optional string + 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, 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 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. + This would result in generation of gratuitous ARPs for IP + 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 + 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 opā€ā€ + tions:router-portā€™s MAC address, not cosidering configured load + balancers. + + options : arp_proxy: optional string + 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 for localnet ports: + + These options apply when type is localnet. + + 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 loā€ + cally accessible network, if at all. + + options : ethtype: optional string + Optional. VLAN EtherType field value for encapsulating VLAN + 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 + FDB table if set to true. The default value is false. + + Options for l2gateway ports: + + These options apply when type is l2gateway. + + 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ā€ + work. + + options : l2gateway-chassis: optional string + Required. The chassis on which the l2gateway logical port should + be bound to. ovn-controller running on the defined chassis will + connect this logical port to the physical network. + + Options for vtep ports: + + These options apply when type is vtep. + + options : vtep-physical-switch: optional string + Required. The name of the VTEP gateway. + + options : vtep-logical-switch: optional string + Required. A logical switch name connected by the VTEP gateway. + + VMI (or VIF) Options: + + These options apply to logical ports with type having (empty string) + + 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 + more than one chassis. + + If set to a comma separated list, the first entry identifies the + main chassis and the rest are one or more additional chassis + that are allowed to bind the same port. + + When multiple chassis are set for the port, and the logical + switch is connected to an external network through a localnet + port, tunneling is enforced for the port to guarantee delivery + of packets directed to the port to all its locations. This has + 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 (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 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 + useful in live migration scenarios for virtual machines. + + options : iface-id-ver: optional string + If set, this port will be bound by ovn-controller only if this + same key and value is configured in the external_ids column in + the Open_vSwitch databaseā€™s Interface table. + + options : qos_min_rate: optional string + If set, indicates the minimum guaranteed rate available for data + sent from this interface, in bit/s. + + options : qos_max_rate: optional string + 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 : 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 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 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ā€ + 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 + update the MTU of the linked interface. + + Virtual port Options: + + These options apply when type is virtual. + + options : virtual-ip: optional string + This option represents the virtual IPv4 address. + + options : virtual-parents: optional string + 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 + enabled. + + IP Multicast Snooping Options: + + These options apply when the port is part of a logical switch which has + other_config :mcast_snoop set to true. + + options : mcast_flood: optional string, either true or false + If set to true, multicast packets (except reports) are uncondiā€ + tionally forwarded to the specific port. Default: false. + + options : mcast_flood_reports: optional string, either true or false + If set to true, multicast reports are unconditionally forwarded + to the specific port. Default: false. + + Containers: + + When a large number of containers are nested within a VM, it may be too + expensive to dedicate a VIF to each container. OVN can use VLAN tags to + support such cases. Each container is assigned a VLAN ID and each + packet that passes between the hypervisor and the VM is tagged with the + appropriate ID for the container. Such VLAN IDs never appear on a physā€ + 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 + 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. + + 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 + this column. The allocated value is written by ovn-northd 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 + 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 tag_request column. + + Port State: + + up: optional boolean + 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 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 + 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 + has all ingress and egress traffic dropped. + + Addressing: + + addresses: set of strings + Addresses owned by the logical port. + + Each element in the set must take one of the following forms: + + 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 + 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 + address on the port. + + 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 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 adā€ + dress must be listed before the IP address(es) if deā€ + fined. + + Examples: + + 80:fa:5b:06:72:b7 + This indicates that the logical port owns the + above mac address. + + 80:fa:5b:06:72:b7 10.0.0.4 20.0.0.4 + This indicates that the logical port owns the mac + address and two IPv4 addresses. + + 80:fa:5b:06:72:b7 fdaa:15f2:72cf:0:f816:3eff:fe20:3f41 + This indicates that the logical port owns the mac + address and 1 IPv6 address. + + 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 + 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 + 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 + 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 + dynamic_addresses column. + + 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. Exā€ + ample: dynamic 192.168.0.1 2001::1. + + mac dynamic + This acts like dynamic alone but specifies a particular MAC + address to use. OVN IPAM will still automatically allocate + IPv4 or IPv6 addresses, or both, if configured appropriā€ + ately. Example: 80:fa:5b:06:72:b7 dynamic + + router + Accepted only when type is 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 options. + + The resulting addresses are used to populate the logical + switchā€™s destination lookup, and also for the logical + switch to generate ARP and ND replies. + + If the connected logical router port has a distributed + gateway port specified and the logical router has rules + 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 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 + 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 + 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 + 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 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 + 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 + source IPv4 address. (RARP is not restricted.) + + ā€¢ 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 + restricted to sending IPv6 Neighbor Discovery Solicitaā€ + tion or Advertisement packets with the specified source + address or, for solicitations, the unspecified address. + + 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 + allowed. + + 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 imā€ + plemented as ACLs using the ACL table. + + Examples: + + 80:fa:5b:06:72:b7 + 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 + 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 + 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 + (including IPv6 Neighbor Discovery) traffic. + + "80:fa:5b:12:42:ba", "80:fa:5b:06:72:b7 192.168.1.10/24" + The host may send traffic from and receive traffic to the + specified MAC addresses, and to receive traffic to Etherā€ + net multicast and broadcast addresses, but not otherwise. + With MAC 80:fa:5b:12:42:ba, the host may send traffic + from and receive traffic to any L3 address. With MAC + 80:fa:5b:06:72:b7, 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 or receive any IPv6 + (including IPv6 Neighbor Discovery) traffic. + + DHCP: + + dhcpv4_options: optional weak reference to DHCP_Options + This column defines the DHCPv4 Options to be included by the + ovn-controller when it replies to the DHCPv4 requests. Please + see the DHCP_Options table. + + dhcpv6_options: optional weak reference to DHCP_Options + This column defines the DHCPv6 Options to be included by the + ovn-controller when it replies to the DHCPv6 requests. Please + see the DHCP_Options table. + + mirror_rules: set of weak reference to Mirrors + Mirror rules that apply to logical switch port which is the + source. Please see the Mirror table. + + ha_chassis_group: optional HA_Chassis_Group + 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. + + Naming: + + external_ids : neutron:port_name: optional string + This column gives an optional human-friendly name for the port. + This name has no special meaning or purpose other than to proā€ + vide convenience for human interaction with the northbound dataā€ + base. + + 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.) + + Tunnel Key: + + 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 + the value from OVN_IC_Southbound through this config. + + Common Columns: + + 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ā€ā€ + nal_ids column of the Port_Binding table in OVN_Southbound dataā€ + base. + +Forwarding_Group TABLE + Each row represents one forwarding group. + + Summary: + name string + vip string + vmac string + liveness boolean + child_port set of 1 or more strings + Common Columns: + external_ids map of string-string pairs + + 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 inā€ + teraction with the ovn-nb database. + + vip: string + The virtual IP address assigned to the forwarding group. It will + respond with vmac when an ARP request is sent for vip. + + vmac: string + The virtual MAC address assigned to the forwarding group. + + liveness: boolean + If set to true, liveness is enabled for child ports otherwise it + is disabled. + + child_port: set of 1 or more strings + List of child ports in the forwarding group. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +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 + 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ā€ā€™ + + + Address sets may be used in the match column of the ACL table. For synā€ + tax information, see the details of the expression language used for + the match column in the Logical_Flow table of the OVN_Southbound dataā€ + base. + + Summary: + name string (must be unique within table) + addresses set of strings + Common Columns: + external_ids map of string-string pairs + + Details: + name: string (must be unique within table) + A name for the address set. Names are ASCII and must match + [a-zA-Z_.][a-zA-Z_.0-9]*. + + addresses: set of strings + The set of addresses in string form. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +Port_Group TABLE + Each row in this table represents a named group of logical switch + ports. + + Port groups may be used in the match column of the ACL table. For synā€ + tax information, see the details of the expression language used for + 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 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ā€ā€ + bound database. + + Summary: + name string (must be unique within table) + ports set of weak reference to Logiā€ā€ + cal_Switch_Ports + acls set of ACLs + Common Columns: + external_ids map of string-string pairs + + Details: + name: string (must be unique within table) + A name for the port group. Names are ASCII and must match + [a-zA-Z_.][a-zA-Z_.0-9]*. + + ports: set of weak reference to Logical_Switch_Ports + The logical switch ports belonging to the group in uuids. + + acls: set of ACLs + Access control rules that apply to the port group. Applying an + ACL to a port group has the same effect as applying the ACL to + all logical lswitches that the ports of the port group belong + to. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +Load_Balancer TABLE + Each row represents one load balancer. + + Summary: + name string + vips map of string-string pairs + protocol optional string, one of sctp, tcp, or udp + Health Checks: + health_check set of Load_Balancer_Health_Checks + ip_port_mappings map of string-string pairs + selection_fields set of strings, one of eth_dst, eth_src, + ip_dst, ip_src, tp_dst, or tp_src + Common Columns: + external_ids map of string-string pairs + Load_Balancer options: + options : reject optional string, either true or false + options : hairpin_snat_ip optional string + options : skip_snat optional string + options : add_route optional string + options : neighbor_responder + optional string + 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 + 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 + 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 + 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ā€ā€ + 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 + with VIP as the destination IP address and routerā€™s mac address + as the destination MAC address). + + protocol: optional string, one of sctp, tcp, or udp + Valid protocols are tcp, udp, or sctp. This column is useful + when a port number is provided as part of the vips column. If + this column is empty and a port number is provided as part of + vips column, OVN assumes the protocol to be tcp. + + Health Checks: + + 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, + 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. 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 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. + + 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 + flow. + + 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 + OVS sources for the implementation details. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + + 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 + 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 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. + + options : skip_snat: optional string + If the load balancing rule is configured with skip_snat option, + the option lb_force_snat_ip configured for the logical router + that references this load balancer will not be applied for this + load balancer. + + options : add_route: optional string + 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 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 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 + option, if not specified, is reachable for regular load balā€ + ancers and none for template load balancers. + + 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ā€ā€ + plate_Var in their definitions. + + Load balancer template VIP supported formats are: + + ^VIP_VAR[:^PORT_VAR|:port] + + + where VIP_VAR and PORT_VAR are keys of the Chassis_Template_Var + variables records. + + Note: The VIP and PORT cannot be combined into a single template + variable. For example, a Chassis_Template_Var variable expanding + to 10.0.0.1:8080 is not valid if used as VIP. + + Load balancer template backend supported formats are: + + ^BACKEND_VAR1[:^PORT_VAR1|:port],^BACKEND_VAR2[:^PORT_VAR2|:port] + or + ^BACKENDS_VAR1,^BACKENDS_VAR2 + + + 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, + 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ā€ + 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 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: + name string (must be unique within table) + load_balancer set of weak reference to Load_Balancers + + 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 + 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. + + Summary: + vip string + Health check options: + 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 + Common Columns: + external_ids map of string-string pairs + + Details: + vip: string + vip whose endpoints should be monitored for health check. + + Health check options: + + options : interval: optional string, containing an integer + The interval, in seconds, between health checks. + + options : timeout: optional string, containing an integer + The time, in seconds, after which a health check times out. + + options : success_count: optional string, containing an integer + The number of successful checks after which the endpoint is conā€ + sidered online. + + options : failure_count: optional string, containing an integer + The number of failure checks after which the endpoint is considā€ + ered offline. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +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 + match, and deny as action.) + + Summary: + label integer, in range 0 to 4,294,967,295 + priority integer, in range 0 to 32,767 + direction string, either from-lport or to-lport + match string + 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: + log boolean + name optional string, at most 63 characters + long + severity optional string, one of alert, debug, + info, notice, or warning + meter optional string + Common Columns: + options map of string-string pairs + ACL configuration options: + options : log-related optional string + external_ids map of string-string pairs + + Details: + label: integer, in range 0 to 4,294,967,295 + Associates an identifier with the ACL. The same value will be + written to corresponding connection tracker entry. The value + should be a valid 32-bit unsigned integer. This value can help + in debugging from connection tracker side. For example, through + this "label" we can backtrack to the ACL rule which is causing a + "leaked" connection. Connection tracker entries are created only + for allowed connections so the label is valid only for allow and + allow-related actions. + + priority: integer, in range 0 to 32,767 + 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. + + Return traffic from an allow-related flow is always allowed and + cannot be changed through an ACL. + + allow-stateless flows always take precedence before 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 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 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 + 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 + ARP and IPv6 neighbor discovery packets. + + 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, + pass, or reject + The action to take when the ACL rule matches: + + ā€¢ 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 + 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 exā€ + ist on the logical switch. Otherwise, itā€™s equivalent to + allow-stateless. + + ā€¢ allow-related: Forward the packet and related traffic + (e.g. inbound replies to an outbound connection). + + ā€¢ drop: Silently drop the packet. + + ā€¢ 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. + + options : apply-after-lb: optional string + If set to true, the ACL will be applied after load balancing + stage. Supported only for from-lport direction. + + The main use case of this option is to support ACLs matching on + the destination IP address of the packet for the backend IPs of + load balancers. + + 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 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 + ACL. + + log: boolean + 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. + + If set to false, the remaining columns in this group have no + significance. + + name: optional string, at most 63 characters long + This name, if it is provided, is included in log records. It + 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ā€ā€ + ing + The severity of the ACL. The severity levels match those of sysā€ + 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 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 + options are described individually below. + + ACL configuration options: + + options : log-related: optional string + If set to true, then log when reply or related traffic is admitā€ + ted from a stateful ACL. In order for this option to function, + 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 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. + +Logical_Router TABLE + Each row represents one L3 logical router. + + Summary: + ports set of Logical_Router_Ports + static_routes set of Logical_Router_Static_Routes + policies set of Logical_Router_Policys + enabled optional boolean + nat set of NATs + load_balancer set of weak reference to Load_Balancers + load_balancer_group set of Load_Balancer_Groups + Naming: + name string + external_ids : neutron:router_name + optional string + copp optional weak reference to Copp + Options: + options : chassis optional string + options : dnat_force_snat_ip + optional string + options : lb_force_snat_ip optional string + options : mcast_relay optional string, either true or false + options : dynamic_neigh_routers + optional string, either true or false + options : always_learn_from_arp_request + optional string, either true or false + options : requested-tnl-key + optional string, containing an integer, + in range 1 to 16,777,215 + 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 + Common Columns: + external_ids map of string-string pairs + + Details: + ports: set of Logical_Router_Ports + The routerā€™s ports. + + static_routes: set of Logical_Router_Static_Routes + Zero or more static routes for the router. + + policies: set of Logical_Router_Policys + Zero or more routing policies for the router. + + enabled: optional boolean + This column is used to administratively set router state. If + this column is empty or is set to true, the router is enabled. + If this column is set to false, the router is disabled. A disā€ + abled router has all ingress and egress traffic dropped. + + nat: set of NATs + One or more NAT rules for the router. NAT rules only work on + Gateway routers, and on distributed routers with one and only + one distributed gateway port. + + load_balancer: set of weak reference to Load_Balancers + Set of load balancers associated to this logical router. Load + balancer Load balancer rules only work on the Gateway routers or + routers with one and only one distributed gateway port. + + load_balancer_group: set of Load_Balancer_Groups + Set of load balancers groups associated to this logical router. + + Naming: + + 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ā€ + 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ā€ā€ + tron:router_name. Perhaps this can be cleaned up someday.) + + name: string + A name for the logical router. + + external_ids : neutron:router_name: optional string + Another name for the logical router. + + copp: optional weak reference to Copp + The control plane protection policy from table Copp used for meā€ + tering packets sent to ovn-controller from logical ports of this + router. + + Options: + + Additional options for the logical router. + + 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ā€ā€ + 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ā€ + 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ā€ + 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. + This option may have exactly one IPv4 and/or one IPv6 address on + it, separated by a a space. + + options : lb_force_snat_ip: optional string + 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 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ā€ + anced packet is SNATed with the IP of router port (attached to + the gateway router) selected as the destination after taking the + routing decision. + + options : mcast_relay: optional string, either true or false + 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 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 + will prevent the automatic creation of these logical flows. + + options : always_learn_from_arp_request: optional string, either true + or false + 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 + binding entry. + + false - If there is a MAC binding for that IP and the MAC is + different, or, if TPA of ARP request belongs to any router port + on this router, then update/add that MAC-IP binding. Otherwise, + donā€™t update/add entries. + + It is true by default. It is recommended to set to false when a + large number of logical routers are connected to the same logiā€ + cal switch but most of them never need to send traffic between + each other, to reduce the size of the MAC binding 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, + ovn-northd honors the configured value. + + 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 + sources can make use of the same conntrack zone. + + options : mac_binding_age_threshold: optional string, containing an inā€ + teger, in range 0 to 4,294,967,295 + MAC binding aging threshold value in seconds. MAC binding exā€ + ceeding this timeout will be automatically removed. The value + defaults to 0, which means disabled. + + Common Columns: + + external_ids: map of string-string pairs + 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 + 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. 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 + bandwidth map of string-integer pairs, key either + burst or rate, value in range 1 to + 4,294,967,295 + external_ids map of string-string pairs + + Details: + 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 + packet is undefined. + + direction: string, either from-lport or to-lport + The value of this field is similar to ACL column in the OVN + Northbound databaseā€™s ACL table. + + match: string + The packets that the QoS rules should match, in the same expresā€ + sion language used for the match column in the OVN Southbound + databaseā€™s Logical_Flow table. The outport logical port is only + 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. + + ā€¢ dscp: The value of this action should be in the range of + 0 to 63 (inclusive). + + 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. + + ā€¢ 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 + the Logical_Switch_Port table. + + Summary: + name string (must be unique within table) + filter string, one of both, from-lport, or + to-lport + sink string + type string, one of erspan, gre, or local + index integer + external_ids map of string-string pairs + + Details: + name: string (must be unique within table) + Represents the name of the mirror. + + filter: string, one of both, from-lport, or to-lport + The value of this field represents selection criteria of the + mirror. to-lport mirrors the packets coming into logical port. + from-lport mirrors the packets going out of logical port. both + mirrors for both directions. + + sink: string + The value of this field represents the destination/sink of the + mirror. If the type is gre or erspan, the value indicates the + tunnel remote IP (either IPv4 or IPv6). For a type of local, + this field defines a local interface on the OVS integration + bridge to be used as the mirror destination. The interface must + possess external-ids:mirror-id that matches this string. + + type: string, one of erspan, gre, 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. 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 + rate-limiting. + + Summary: + name string (must be unique within table) + unit string, either kbps or pktps + bands set of 1 or more Meter_Bands + fair optional boolean + external_ids map of string-string pairs + + Details: + name: string (must be unique within table) + A name for this meter. + + Names that begin with "__" (two underscores) are reserved for + OVN internal use and should not be added manually. + + unit: string, either kbps or pktps + The unit for rate and burst_rate parameters in the bands entry. + kbps specifies kilobits per second, and pktps specifies packets + per second. + + bands: set of 1 or more Meter_Bands + The bands associated with this meter. Each band specifies a rate + above which the band is to take the action action. If multiple + bandsā€™ rates are exceeded, then the band with the highest rate + among the exceeded bands is selected. + + 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 + rate-limited on its own. + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +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 + referenced by the bands column in the Meter table. + + Summary: + action string, must be drop + rate integer, in range 1 to 4,294,967,295 + burst_size integer, in range 0 to 4,294,967,295 + external_ids map of string-string pairs + + Details: + action: string, must be drop + The action to execute when this band matches. The only supported + action is drop. + + 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ā€ + 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 + free to select some reasonable value depending on its configuraā€ + tion. + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +Logical_Router_Port TABLE + A port within an L3 logical router. + + Exactly one Logical_Router row must reference a given logical router + port. + + Summary: + name string (must be unique within table) + networks set of 1 or more strings + mac string + enabled optional boolean + Distributed Gateway Ports: + ha_chassis_group optional HA_Chassis_Group + gateway_chassis set of Gateway_Chassises + 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ā€ā€ + lay + ipv6_prefix set of strings + ipv6_ra_configs: + ipv6_ra_configs : address_mode + optional string + ipv6_ra_configs : router_preference + optional string + ipv6_ra_configs : route_info + optional string + ipv6_ra_configs : mtu optional string + ipv6_ra_configs : send_periodic + optional string + ipv6_ra_configs : max_interval + optional string + ipv6_ra_configs : min_interval + optional string + ipv6_ra_configs : rdnss optional string + ipv6_ra_configs : dnssl optional string + Options: + options : mcast_flood optional string, either true or false + options : requested-tnl-key + 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, + in range 68 to 65,535 + options : gateway_mtu_bypass + optional string + Attachment: + peer optional string + Common Columns: + external_ids map of string-string pairs + + Details: + name: string (must be unique within table) + A name for the logical router port. + + 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 + 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 + routed to this port. + + 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. + + 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 + has all ingress and egress traffic dropped. + + Distributed Gateway Ports: + + Gateways, as documented under Gateways in the OVN architecture guide, + provide limited connectivity between logical networks and physical + ones. OVN support multiple kinds of gateways. The Logical_Router_Port + table can be used two different ways to configure distributed gateway + ports, which are one kind of gateway. These two forms of configuration + 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 + 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 + 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 + manner on the gateway chassis. + + There can be more than one distributed gateway ports configured on each + logical router, each connecting to different L2 segments. Load-balancā€ + 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ā€ā€ + 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 + 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-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 + 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ā€ā€ + way-chassis lrp chassis. + + ha_chassis_group: optional HA_Chassis_Group + Designates an HA_Chassis_Group to provide gateway high availā€ + ability. + + gateway_chassis: set of Gateway_Chassises + Designates one or more Gateway_Chassis for the logical router + port. + + Options for Physical VLAN MTU Issues: + + MTU issues arise in mixing tunnels with logical networks that are + bridged to a physical VLAN. For an explanation of the MTU issues, see + 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 + 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 + 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 + 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, + 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 + 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 + 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 + 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 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 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 + router according to RFC 3633 + + ipv6_ra_configs: + + This column defines the IPv6 ND RA address mode and ND MTU Option to be + included by ovn-controller when it replies to the IPv6 Router solicitaā€ + tion requests. + + ipv6_ra_configs : address_mode: optional string + 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 + in the RAā€™s ICMPv6 option - Prefix information. + + ā€¢ dhcpv6_stateful: Address configuration using 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 + + ā€¢ MEDIUM: mapped to 0x00 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 + Advertisement according to RFC 4191. Route Info is a comma sepaā€ + rated string where each field provides PRF and prefix for a + given route (e.g: HIGH-aef1::11/48,LOW-aef2::11/96) Possible PRF + values are: + + ā€¢ HIGH: mapped to 0x01 in RA PRF field + + ā€¢ MEDIUM: mapped to 0x00 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ā€ + 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 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ā€ā€ + 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ā€ā€ + 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 moā€ + ment OVN supports just one RDNSS server. + + ipv6_ra_configs : dnssl: optional string + DNS Search List announced in RA packets. Multiple DNS Search + List must be ā€™commaā€™ separated (e.g. "a.b.c, d.e.f") + + Options: + + Additional options for the logical router port. + + options : mcast_flood: optional string, either true or false + If set to true, multicast traffic (including reports) are unconā€ + ditionally forwarded to the specific port. + + This option applies when the port is part of a logical router + which has options:mcast_relay set to true. + + Default: false. + + 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. + + 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 + 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 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 + have higher priority than routes with route_table option set. + + options : gateway_mtu: optional string, containing an integer, in range + 68 to 65,535 + If set, logical flows will be added to router pipeline to check + packet length. If packet length is greater than the value set, + ICMPv4 type 3 (Destination Unreachable) code 4 (Fragmentation + Needed and Donā€™t Fragment was Set) or ICMPv6 type 2 (Packet Too + Big) code 0 (no route to destination) packets will be generated. + This allows for Path MTU Discovery. + + options : gateway_mtu_bypass: optional string + 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ā€ā€ + cal_Switch_Port. In this case peer column is empty. + + ā€¢ 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 + other in its peer column. No Logical_Switch refers to the + router port. + + peer: optional string + For a router port used to connect two logical routers, this + identifies the other router port in the pair by name. + + For a router port attached to a logical switch, this column is + empty. + + Common Columns: + + 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ā€ā€ + nal_ids column of the Port_Binding table in OVN_Southbound dataā€ + base. + +Logical_Router_Static_Route TABLE + Each record represents a static route. + + When multiple routes match a packet, the longest-prefix match is choā€ + sen. For a given prefix length, a dst-ip route is preferred over a + src-ip route. + + When there are ECMP routes, i.e. multiple routes with same prefix and + policy, one of them will be selected based on the 5-tuple hashing of + the packet header. + + Summary: + ip_prefix string + policy optional string, either dst-ip or src-ip + nexthop string + output_port optional string + bfd optional weak reference to BFD + route_table string + external_ids : ic-learned-route + optional string + Common Columns: + external_ids map of string-string pairs + Common options: + options map of string-string pairs + options : ecmp_symmetric_reply + optional string + options : origin optional string + + Details: + ip_prefix: string + IP prefix of this route (e.g. 192.168.100.0/24). + + policy: optional string, either dst-ip or src-ip + If it is specified, this setting describes the policy used to + make routing decisions. This setting must be one of the followā€ + ing strings: + + ā€¢ 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 + the packetā€™s destination IP address matches ip_prefix. + + If not specified, the default is dst-ip. + + nexthop: string + Nexthop IP address for this route. Nexthop IP address should be + the IP address of a connected router port or the IP address of a + logical port or can be set to discard for dropping packets which + match the given route. + + output_port: optional string + The name of the Logical_Router_Port via which the packet needs + to be sent out. This is optional and when not specified, OVN + 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ā€ā€ + thop is reachable. + + bfd: optional weak reference to BFD + Reference to BFD row if the route has associated a BFD session + + 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 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 + networks. + + ā€¢ 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_Southbound database. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + + Common options: + + options: map of string-string pairs + This column provides general key/value settings. The supported + options are described individually below. + + options : ecmp_symmetric_reply: optional string + If true, then new traffic that arrives over this route will have + its reply traffic bypass ECMP route selection and will be sent + out this route instead. Note that this option overrides any + rules set in the Logical_Router_policy table. This option only + works on gateway routers (routers that have options:chassis + set). + + options : origin: optional string + 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ā€ā€ + cal_Router_Static_Route records with same ip_prefix within same + Logical Router will have next lookup order based on origin key + value: + + 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 + match, and drop as action.) + + Summary: + priority integer, in range 0 to 32,767 + match string + action string, one of allow, drop, or reroute + nexthop optional string + nexthops set of strings + 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 + 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ā€ + 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 + 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. + + ā€¢ drop: Silently drop the packet. + + ā€¢ 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 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 + address of a logical port. + + One IP from the list is selected as next hop. + + 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 deā€ + cisions if desired. This value is not preserved when the packet + goes out on the wire. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +NAT TABLE + Each record represents a NAT rule. + + Summary: + type string, one of dnat, dnat_and_snat, or + snat + external_ip string + external_mac optional string + external_port_range string + logical_ip string + logical_port optional string + allowed_ext_ips optional Address_Set + exempted_ext_ips optional Address_Set + gateway_port optional weak reference to Logiā€ā€ + cal_Router_Port + options : stateless optional string + options : add_route optional string + Common Columns: + external_ids map of string-string pairs + + Details: + type: string, one of dnat, dnat_and_snat, or snat + Type of the NAT rule. + + ā€¢ 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 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 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. + + external_mac: optional string + A MAC address. + + This is only used on the gateway port on distributed routers. + 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 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ā€ā€ + ical_port is globally unique, then that MAC address can be specā€ + ified as this external_mac. + + external_port_range: string + 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 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" + + Valid range of ports is 1-65535. + + logical_ip: string + An IPv4 network (e.g 192.168.1.0/24) or an IPv4 address. + + logical_port: optional string + The name of the logical port where the logical_ip resides. + + 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 + chassis. + + allowed_ext_ips: optional Address_Set + 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ā€ + tion, NAT happens without considering the external IP (i.e + dest/source for snat/dnat type rule). With this configuration + NAT rule is applied ONLY if external ip is in the input Address + Set. + + exempted_ext_ips: optional Address_Set + It represents Address Set of external ips that NAT rule is NOT + applicable to. For SNAT type NAT rules, this refers to destinaā€ + tion addresses. For DNAT type NAT rules, this refers to source + addresses. + + This configuration overrides the default NAT behavior of applyā€ + ing a rule solely based on internal IP. Without this configuraā€ + tion, NAT happens without considering the external IP (i.e + dest/source for snat/dnat type rule). With this configuration + NAT rule is NOT applied if external ip is in the input Address + Set. + + If there are NAT rules in a logical router with overlapping IP + prefixes (including /32), then usage of exempted_ext_ips should + be avoided in following scenario. a. SNAT rule (let us say + RULE1) with logical_ip PREFIX/MASK (let us say 50.0.0.0/24). b. + SNAT rule (let us say RULE2) with logical_ip PREFIX/MASK+1 (let + us say 50.0.0.0/25). c. Now, if exempted_ext_ips is associated + 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 + NAT rule is not considered. + + gateway_port: optional weak reference to Logical_Router_Port + 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ā€ā€ + 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 + 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 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 + 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 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: + + external_ids: map of string-string pairs + 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 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: + cidr string + DHCPv4 options: + Mandatory DHCPv4 options: + options : server_id optional string + options : server_mac optional string + options : lease_time optional string, containing an integer, + in range 0 to 4,294,967,295 + IPv4 DHCP Options: + options : router optional string + options : netmask optional string + options : dns_server optional string + options : log_server optional string + options : lpr_server optional string + options : swap_server optional string + options : policy_filter optional string + options : router_solicitation + optional string + options : nis_server optional string + options : ntp_server optional string + options : netbios_name_server + optional string + options : classless_static_route + optional string + options : ms_classless_static_route + optional string + options : next_server optional string + Boolean DHCP Options: + options : ip_forward_enable + optional string, either 0 or 1 + options : router_discovery + 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, + in range 0 to 255 + options : tcp_ttl optional string, containing an integer, + in range 0 to 255 + options : mtu optional string, containing an integer, + in range 68 to 65,535 + options : T1 optional string, containing an integer, + in range 68 to 4,294,967,295 + options : T2 optional string, containing an integer, + in range 68 to 4,294,967,295 + options : arp_cache_timeout + optional string, containing an integer, + in range 0 to 255 + options : tcp_keepalive_interval + optional string, containing an integer, + in range 0 to 255 + options : netbios_node_type + optional string, containing an integer, + in range 0 to 255 + String DHCP Options: + options : wpad optional string + options : bootfile_name optional string + options : path_prefix optional string + options : tftp_server_address + optional string + options : hostname optional string + options : domain_name optional string + options : bootfile_name_alt + optional string + options : broadcast_address + optional string + DHCP Options of type host_id: + options : tftp_server optional string + DHCP Options of type domains: + options : domain_search_list + optional string + DHCPv6 options: + Mandatory DHCPv6 options: + options : server_id optional string + IPv6 DHCPv6 options: + options : dns_server optional string + String DHCPv6 options: + options : domain_search optional string + options : dhcpv6_stateless + 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 + 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 + to an entry in this table. + + Mandatory DHCPv4 options: + + The following options must be defined. + + 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 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 + 0 to 4,294,967,295 + The offered lease time in seconds, + + The DHCPv4 option code for this option is 51. + + IPv4 DHCP Options: + + 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 + this option is 3. + + options : netmask: optional string + The DHCPv4 option code for this option is 1. + + options : dns_server: optional string + The DHCPv4 option code for this option is 6. + + options : log_server: optional string + The DHCPv4 option code for this option is 7. + + options : lpr_server: optional string + The DHCPv4 option code for this option is 9. + + options : swap_server: optional string + The DHCPv4 option code for this option is 16. + + options : policy_filter: optional string + The DHCPv4 option code for this option is 21. + + options : router_solicitation: optional string + The DHCPv4 option code for this option is 32. + + options : nis_server: optional string + The DHCPv4 option code for this option is 41. + + options : ntp_server: optional string + The DHCPv4 option code for this option is 42. + + options : netbios_name_server: optional string + The DHCPv4 option code for this option is 44. + + options : classless_static_route: optional string + The DHCPv4 option code for this option is 121. + + This option can contain one or more static routes, each of which + consists of a destination descriptor and the IP address of the + router that should be used to reach that destination. Please see + RFC 3442 for more details. + + 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 + similar to classless_static_route supported by Microsoft Windows + DHCPv4 clients. + + options : next_server: optional string + The DHCPv4 option code for setting the "Next server IP address" + field in the DHCP header. + + Boolean DHCP Options: + + These options accept a Boolean value, expressed as 0 for false or 1 for + true. + + options : ip_forward_enable: optional string, either 0 or 1 + The DHCPv4 option code for this option is 19. + + options : router_discovery: optional string, either 0 or 1 + The DHCPv4 option code for this option is 31. + + options : ethernet_encap: optional string, either 0 or 1 + The DHCPv4 option code for this option is 36. + + Integer DHCP Options: + + These options accept a nonnegative integer value. + + options : default_ttl: optional string, containing an integer, in range + 0 to 255 + The DHCPv4 option code for this option is 23. + + 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 + 65,535 + The DHCPv4 option code for this option is 26. + + options : T1: 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 renew its address. The DHCPv4 option + code for this option is 58. + + 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 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ā€ + 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 + a keepalive message on a TCP connection. + + options : netbios_node_type: optional string, containing an integer, in + range 0 to 255 + The DHCPv4 option code for this option is 46. + + String DHCP Options: + + 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 + web proxy. + + options : bootfile_name: optional string + 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 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ā€ + tains one or more IPv4 addresses that the client MAY use. This + option is Cisco proprietary, the IEEE standard that matches with + 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ā€ā€ + cal_Switch_Port takes precedence. + + options : domain_name: optional string + The DHCPv4 option code for this option is 15. This option speciā€ + fies the domain name that client should use when resolving hostā€ + 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" 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" + will be used. + + options : broadcast_address: optional string + The DHCPv4 option code for this option is 28. This option speciā€ + fies the IP address used as a broadcast address. + + DHCP Options of type host_id: + + These options accept either an IPv4 address or a string value. + + options : tftp_server: optional string + The DHCPv4 option code for this option is 66. + + DHCP Options of type domains: + + 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 + The DHCPv4 option code for this option is 119. + + 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/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 + [DUID-LL]. + + IPv6 DHCPv6 options: + + 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 + The DHCPv6 option code for this option is 23. This option speciā€ + fies the DNS servers that the VM should use. + + String DHCPv6 options: + + These options accept string values. + + 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 + 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 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. + + 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 + (OVSDB) client. + + 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ā€ + tions. + + Summary: + Core Features: + target string (must be unique within table) + Client Failure Detection and Handling: + max_backoff optional integer, at least 1,000 + inactivity_probe optional integer + Status: + is_connected boolean + status : last_error optional string + status : state optional string, one of ACTIVE, BACKOFF, + CONNECTING, IDLE, or VOID + status : sec_since_connect optional string, containing an integer, + at least 0 + status : sec_since_disconnect + optional string, containing an integer, + at least 0 + status : locks_held optional string + status : locks_waiting optional string + status : locks_lost optional string + status : n_connections optional string, containing an integer, + at least 2 + status : bound_port optional string, containing an integer + Common Columns: + external_ids map of string-string pairs + other_config map of string-string pairs + + Details: + Core Features: + + target: string (must be unique within table) + Connection methods for clients. + + The following connection methods are currently supported: + + ssl:host[:port] + The specified SSL port on the host at the given host, + which can either be a DNS name (if built with unbound 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. + + If port is not specified, it defaults to 6640. + + SSL support is an optional feature that is not always + built as part of Open vSwitch. + + tcp:host[:port] + The specified TCP port on the host at the given host, + which can either be a DNS name (if built with unbound 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. + + 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 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 + then it listens only on IPv4 (but not IPv6) addresses. A + valid SSL configuration must be provided when this form + is used, this can be specified either via command-line + options or the SSL table. + + If port is not specified, it defaults to 6640. + + SSL support is an optional feature that is not always + built as part of Open vSwitch. + + ptcp:[port][:host] + Listens for connections on the specified TCP port. 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 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 + 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 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 + inactivity probes. + + Status: + + Key-value pair of is_connected is always updated. Other key-value pairs + in the status columns may be updated depends on the target type. + + When target specifies a connection method that listens for inbound conā€ + 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ā€ + ted. + + is_connected: boolean + true if currently connected to this client, false otherwise. + + status : last_error: optional string + A human-readable description of the last error on the connection + to the manager; i.e. strerror(errno). This key will exist only + if an error has occurred. + + status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING, + IDLE, or VOID + The state of the connection to the manager: + + VOID Connection is disabled. + + BACKOFF + Attempting to reconnect at an increasing period. + + CONNECTING + Attempting to connect. + + ACTIVE Connected, remote host responsive. + + IDLE Connection is idle. Waiting for response to keep-alive. + + These values may change in the future. They are provided only + for human consumption. + + status : sec_since_connect: optional string, containing an integer, at + least 0 + The amount of time since this client last successfully connected + to the database (in seconds). Value is empty if client has never + successfully been connected. + + status : sec_since_disconnect: optional string, containing an integer, + at least 0 + The amount of time since this client last disconnected from the + database (in seconds). Value is empty if client has never 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 + 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ā€ + 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 + locks have been stolen from this connection. + + status : n_connections: optional string, containing an integer, at + least 2 + When target specifies a connection method that listens for 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 + available port.) + + Common Columns: + + The overall purpose of these columns is described under Common Columns + at the beginning of this document. + + external_ids: map of string-string pairs + + other_config: map of string-string pairs +DNS TABLE + 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 + 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 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" + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +SSL TABLE + SSL configuration for ovn-nb database access. + + Summary: + private_key string + certificate string + ca_cert string + bootstrap_ca_cert boolean + ssl_protocols string + ssl_ciphers string + Common Columns: + external_ids map of string-string pairs + + Details: + private_key: string + Name of a PEM file containing the private key used as the + switchā€™s identity for SSL connections to the controller. + + certificate: string + Name of a PEM file containing a certificate, signed by the cerā€ + tificate authority (CA) used by the controller and manager, that + certifies the switchā€™s private key, identifying a trustworthy + switch. + + ca_cert: string + Name of a PEM file containing the CA certificate used to verify + that the switch is connected to a trustworthy controller. + + bootstrap_ca_cert: boolean + If set to true, then Open vSwitch will attempt to obtain the CA + certificate from the controller on its first SSL connection and + save it to the named PEM file. If it is successful, it will 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 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 + omitted is HIGH:!aNULL:!MD5. + + Common Columns: + + The overall purpose of these columns is described under Common Columns + at the beginning of this document. + + external_ids: map of string-string pairs +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 + a set of them in high availability configurations. + + Summary: + name string (must be unique within table) + chassis_name string + priority integer, in range 0 to 32,767 + options map of string-string pairs + Common Columns: + external_ids map of string-string pairs + + Details: + name: string (must be unique within table) + Name of the Gateway_Chassis. + + A suggested, but not required naming convention is + ${port_name}_${chassis_name}. + + chassis_name: string + Name of the chassis that we want to redirect traffic through for + the associated logical router port. The value must match the + 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 beā€ + longing to the same logical router port. + + options: map of string-string pairs + Reserved for future use. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +HA_Chassis_Group TABLE + Table representing a group of chassis which can provide high 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 + this table, then the master HA chassis in this group provides the gateā€ + way functionality. + + Summary: + name string (must be unique within table) + ha_chassis set of HA_Chassises + Common Columns: + external_ids map of string-string pairs + + Details: + name: string (must be unique within table) + Name of the HA_Chassis_Group. Name should be unique. + + ha_chassis: set of HA_Chassises + A list of HA chassis which belongs to this group. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +HA_Chassis TABLE + Summary: + chassis_name string + priority integer, in range 0 to 32,767 + Common Columns: + external_ids map of string-string pairs + + Details: + chassis_name: string + Name of the chassis which is part of the HA chassis group. The + value must match the name column of the Chassis table in the + OVN_Southbound database. + + priority: integer, in range 0 to 32,767 + Priority of the chassis. Chassis with highest priority will be + the master. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +BFD TABLE + Contains BFD parameter for ovn-controller BFD configuration. OVN BFD + 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: + Configuration: + logical_port string + dst_ip string + min_tx optional integer, at least 1 + min_rx optional integer + detect_mult optional integer, at least 1 + options map of string-string pairs + external_ids map of string-string pairs + Status Reporting: + status optional string, one of admin_down, down, + init, or up + + Details: + Configuration: + + ovn-northd reads configuration from these columns. + + logical_port: string + OVN logical port when BFD engine is running. + + dst_ip: string + BFD peer IP address. + + min_tx: optional integer, at least 1 + 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. Default + value is 1000 ms. + + min_rx: optional integer + This is the minimum interval, in milliseconds, between received + BFD Control packets that this system is capable of supporting, + less any jitter applied by the sender. If this value is zero, + the transmitting system does not want the remote system to send + any periodic BFD Control packets. + + detect_mult: optional integer, at least 1 + Detection time multiplier. The negotiated transmit interval, + multiplied by this value, provides the Detection Time for the + receiving system in Asynchronous mode. Default value is 5. + + options: map of string-string pairs + Reserved for future use. + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + + Status Reporting: + + ovn-northd writes BFD status into these columns. + + status: optional string, one of admin_down, down, init, or up + BFD port logical states. Possible values are: + + ā€¢ admin_down + + ā€¢ down + + ā€¢ init + + ā€¢ up +Static_MAC_Binding TABLE + Each record represents a Static_MAC_Binding entry for a logical router. + + Summary: + Configuration: + logical_port string + ip string + mac string + override_dynamic_mac boolean + + Details: + Configuration: + + ovn-northd reads configuration from these columns and propagates the + value to SBDB. + + logical_port: string + The logical router port for the binding. + + ip: string + The bound IP address. + + mac: string + The Ethernet address to which the IP is bound. + + override_dynamic_mac: boolean + Override dynamically learnt MACs. + +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 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 + 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 + just interpret it as a raw string literal. + + Summary: + chassis string (must be unique within table) + variables map of string-string pairs + Common Columns: + external_ids map of string-string pairs + + Details: + chassis: string (must be unique within table) + The chassis this set of variable values applies to. + + variables: map of string-string pairs + The set of variable values for a given chassis. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +Open vSwitch 23.06.3 DB Schema 7.0.4 ovn-nb(5) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-nbctl.8 b/src/static/support/dist-docs-branch-23.06/ovn-nbctl.8 new file mode 100644 index 00000000..8f03624e --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-nbctl.8 @@ -0,0 +1,1075 @@ +'\" p +.\" -*- nroff -*- +.TH "ovn-nbctl" 8 "ovn-nbctl" "OVN 23\[char46]06\[char46]3" "OVN Manual" +.fp 5 L CR \\" Make fixed-width font available as \\fL. +.de TQ +. br +. ns +. TP "\\$1" +.. +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +.de SU +. PP +. I "\\$1" +.. +.PP +.SH "NAME" +.PP +.PP +ovn-nbctl \- Open Virtual Network northbound db management utility +.SH "SYNOPSIS" +.PP +\fBovn\-nbctl\fR [\fIoptions\fR] \fIcommand\fR [\fIarg\fR\[char46]\[char46]\[char46]] +.SH "DESCRIPTION" +.PP +.PP +The \fBovn\-nbctl\fR program configures the \fBOVN_Northbound\fR database by providing a high-level interface to its configuration database\[char46] See \fBovn\-nb\fR(5) for comprehensive documentation of the database schema\[char46] +.PP +.PP +\fBovn\-nbctl\fR connects to an \fBovsdb\-server\fR process that maintains an OVN_Northbound configuration database\[char46] Using this connection, it queries and possibly applies changes to the database, depending on the supplied commands\[char46] +.PP +.PP +\fBovn\-nbctl\fR can perform any number of commands in a single run, implemented as a single atomic transaction against the database\[char46] +.PP +.PP +The \fBovn\-nbctl\fR command line begins with global options (see \fBOPTIONS\fR below for details)\[char46] The global options are followed by one or more commands\[char46] Each command should begin with \fB\-\-\fR by itself as a command-line argument, to separate it from the following commands\[char46] (The \fB\-\-\fR before the first command is optional\[char46]) The command itself starts with command-specific options, if any, followed by the command name and any arguments\[char46] +.SH "DAEMON MODE" +.PP +.PP +When it is invoked in the most ordinary way, \fBovn\-nbctl\fR 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\(cqs reply\[char46] In common interactive use, this is fine, but if the database is large, the step in which \fBovn\-nbctl\fR retrieves a partial copy of the database can take a long time, which yields poor performance overall\[char46] +.PP +.PP +To improve performance in such a case, \fBovn\-nbctl\fR offers a \(dqdaemon mode,\(dq in which the user first starts \fBovn\-nbctl\fR running in the background and afterward uses the daemon to execute operations\[char46] Over several \fBovn\-nbctl\fR command invocations, this performs better overall because it retrieves a copy of the database only once at the beginning, not once per program run\[char46] +.PP +.PP +Use the \fB\-\-detach\fR option to start an \fBovn\-nbctl\fR daemon\[char46] With this option, \fBovn\-nbctl\fR prints the name of a control socket to stdout\[char46] The client should save this name in environment variable \fBOVN_NB_DAEMON\fR\[char46] Under the Bourne shell this might be done like this: +.PP +.nf +\fL +.br +\fL export OVN_NB_DAEMON=$(ovn\-nbctl \-\-pidfile \-\-detach) +.br +\fL \fR +.fi +.PP +.PP +When \fBOVN_NB_DAEMON\fR is set, \fBovn\-nbctl\fR automatically and transparently uses the daemon to execute its commands\[char46] +.PP +.PP +When the daemon is no longer needed, kill it and unset the environment variable, e\[char46]g\[char46]: +.PP +.nf +\fL +.br +\fL kill $(cat $OVN_RUNDIR/ovn\-nbctl\[char46]pid) +.br +\fL unset OVN_NB_DAEMON +.br +\fL \fR +.fi +.PP +.PP +When using daemon mode, an alternative to the \fBOVN_NB_DAEMON\fR environment variable is to specify a path for the Unix socket\[char46] When starting the ovn-nbctl daemon, specify the \fB\-u\fR option with a full path to the location of the socket file\[char46] Here is an exmple: +.PP +.nf +\fL +.br +\fL ovn\-nbctl \-\-detach \-u /tmp/mysock\[char46]ctl +.br +\fL \fR +.fi +.PP +.PP +Then to connect to the running daemon, use the \fB\-u\fR option with the full path to the socket created when the daemon was started: +.PP +.nf +\fL +.br +\fL ovn\-nbctl \-u /tmp/mysock\[char46]ctl show +.br +\fL \fR +.fi +.ST "Daemon Commands" +.PP +.PP +Daemon mode is internally implemented using the same mechanism used by \fBovn\-appctl\fR\[char46] One may also use \fBovn\-appctl\fR directly with the following commands: +.RS +.TP +\fBrun\fR [\fIoptions\fR] \fIcommand\fR [\fIarg\fR\[char46]\[char46]\[char46]] [\fB\-\-\fR [\fIoptions\fR] \fIcommand\fR [\fIarg\fR\[char46]\[char46]\[char46]] \[char46]\[char46]\[char46]] +Instructs the daemon process to run one or more \fBovn\-nbctl\fR commands described above and reply with the results of running these commands\[char46] Accepts the \fB\-\-no\-wait\fR, \fB\-\-wait\fR, \fB\-\-timeout\fR, \fB\-\-dry\-run\fR, \fB\-\-oneline\fR, and the options described under \fBTable Formatting Options\fR in addition to the the command-specific options\[char46] +.TP +\fBexit\fR +Causes \fBovn\-nbctl\fR to gracefully terminate\[char46] +.RE +.SH "OPTIONS" +.PP +.PP +The options listed below affect the behavior of \fBovn\-nbctl\fR as a whole\[char46] Some individual commands also accept their own options, which are given just before the command name\[char46] If the first command on the command line has options, then those options must be separated from the global options by \fB\-\-\fR\[char46] +.PP +.PP +\fBovn\-nbctl\fR also accepts options from the \fBOVN_NBCTL_OPTIONS\fR environment variable, in the same format as on the command line\[char46] Options from the command line override those in the environment\[char46] +.RS +.TP +\fB\-\-no\-wait\fR | \fB\-\-wait=none\fR +.TQ .5in +\fB\-\-wait=sb\fR +.TQ .5in +\fB\-\-wait=hv\fR +These options control whether and how \fBovn\-nbctl\fR waits for the OVN system to become up-to-date with changes made in an \fBovn\-nbctl\fR invocation\[char46] +.IP +By default, or if \fB\-\-no\-wait\fR or \fB\-\-wait=none\fR, \fBovn\-nbctl\fR exits immediately after confirming that changes have been committed to the northbound database, without waiting\[char46] +.IP +With \fB\-\-wait=sb\fR, before \fBovn\-nbctl\fR exits, it waits for \fBovn\-northd\fR to bring the southbound database up-to-date with the northbound database updates\[char46] +.IP +With \fB\-\-wait=hv\fR, before \fBovn\-nbctl\fR exits, it additionally waits for all OVN chassis (hypervisors and gateways) to become up-to-date with the northbound database updates\[char46] (This can become an indefinite wait if any chassis is malfunctioning\[char46]) +.IP +Ordinarily, \fB\-\-wait=sb\fR or \fB\-\-wait=hv\fR only waits for changes by the current \fBovn\-nbctl\fR invocation to take effect\[char46] This means that, if none of the commands supplied to \fBovn\-nbctl\fR change the database, then the command does not wait at all\[char46] Use the \fBsync\fR command to override this behavior\[char46] +.TP +\fB\-\-db\fR \fIdatabase\fR +The OVSDB database remote to contact\[char46] If the \fBOVN_NB_DB\fR environment variable is set, its value is used as the default\[char46] Otherwise, the default is \fBunix:/ovnnb_db\[char46]sock\fR, but this default is unlikely to be useful outside of single-machine OVN test environments\[char46] +.TP +\fB\-\-leader\-only\fR +.TQ .5in +\fB\-\-no\-leader\-only\fR +By default, or with \fB\-\-leader\-only\fR, when the database server is a clustered database, \fBovn\-nbctl\fR will avoid servers other than the cluster leader\[char46] This ensures that any data that \fBovn\-nbctl\fR reads and reports is up-to-date\[char46] With \fB\-\-no\-leader\-only\fR, \fBovn\-nbctl\fR 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 \fB\-\-no\-leader\-only\fR)\[char46] Refer to \fBUnderstanding Cluster Consistency\fR in \fBovsdb\fR(7) for more information\[char46] +.TP +\fB\-\-shuffle\-remotes\fR +.TQ .5in +\fB\-\-no\-shuffle\-remotes\fR +By default, or with \fB\-\-shuffle\-remotes\fR, when there are multiple remotes specified in the OVSDB connection string specified by \fB\-\-db\fR or the \fBOVN_NB_DB\fR environment variable, the order of the remotes will be shuffled before the client tries to connect\[char46] The remotes will be shuffled only once to a new order before the first connection attempt\[char46] The following retries, if any, will follow the same new order\[char46] The default behavior is to make sure clients of a clustered database can distribute evenly to all members of the cluster\[char46] With \fB\-\-no\-shuffle\-remotes\fR, \fBovn\-nbctl\fR will use the original order specified in the connection string to connect\[char46] This allows user to specify the preferred order, which is particularly useful for testing\[char46] +.TP +\fB\-\-no\-syslog\fR +By default, \fBovn\-nbctl\fR logs its arguments and the details of any changes that it makes to the system log\[char46] This option disables this logging\[char46] +.IP +This option is equivalent to \fB\-\-verbose=nbctl:syslog:warn\fR\[char46] +.TP +\fB\-\-oneline\fR +Modifies the output format so that the output for each command is printed on a single line\[char46] New-line characters that would otherwise separate lines are printed as \efB\e\en\efR, and any instances of \efB\e\e\efR that would otherwise appear in the output are doubled\[char46] Prints a blank line for each command that has no output\[char46] This option does not affect the formatting of output from the \fBlist\fR or \fBfind\fR commands; see \fBTable Formatting Options\fR below\[char46] +.TP +\fB\-\-dry\-run\fR +Prevents \fBovn\-nbctl\fR from actually modifying the database\[char46] +.TP +\fB\-t \fIsecs\fB\fR +.TQ .5in +\fB\-\-timeout=\fIsecs\fB\fR +By default, or with a \fIsecs\fR of \fB0\fR, \fBovn\-nbctl\fR waits forever for a response from the database\[char46] This option limits runtime to approximately \fIsecs\fR seconds\[char46] If the timeout expires, \fBovn\-nbctl\fR will exit with a \fBSIGALRM\fR signal\[char46] (A timeout would normally happen only if the database cannot be contacted, or if the system is overloaded\[char46]) +.TP +\fB\-\-print\-wait\-time\fR +When \fB\-\-wait\fR is specified, the option \fB\-\-print\-wait\-time\fR can be used to print the time spent on waiting, depending on the value specified in \fB \-\-wait\fR option\[char46] If \fB\-\-wait=sb\fR is specified, it prints \(dqovn-northd delay before processing\(dq, which is the time between the Northbound DB update by the command and the moment when \fB ovn\-northd\fR starts processing the update, and \(dqovn-northd completion\(dq, which is the time between the Northbound DB update and the moment when \fBovn\-northd\fR completes the Southbound DB updating successfully\[char46] If \fB\-\-wait=hv\fR is specified, in addition to the above information, it also prints \(dqovn-controller(s) completion\(dq, which is the time between the Northbound DB update and the moment when the slowest hypervisor finishes processing the update\[char46] +.RE +.SS "Daemon Options" +.TP +\fB\-\-pidfile\fR[\fB=\fR\fIpidfile\fR] +Causes a file (by default, \fB\fIprogram\fB\[char46]pid\fR) to be created indicating the PID of the running process\[char46] If the \fIpidfile\fR argument is not specified, or if it does not begin with \fB/\fR, then it is created in \fB\fR\[char46] +.IP +If \fB\-\-pidfile\fR is not specified, no pidfile is created\[char46] +.TP +\fB\-\-overwrite\-pidfile\fR +By default, when \fB\-\-pidfile\fR is specified and the specified pidfile already exists and is locked by a running process, the daemon refuses to start\[char46] Specify \fB\-\-overwrite\-pidfile\fR to cause it to instead overwrite the pidfile\[char46] +.IP +When \fB\-\-pidfile\fR is not specified, this option has no effect\[char46] +.TP +\fB\-\-detach\fR +Runs this program as a background process\[char46] 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 \fB\-\-no\-chdir\fR is specified)\[char46] After the child completes its initialization, the parent exits\[char46] +.TP +\fB\-\-monitor\fR +Creates an additional process to monitor this program\[char46] If it dies due to a signal that indicates a programming error (\fBSIGABRT\fR, \fBSIGALRM\fR, \fBSIGBUS\fR, \fBSIGFPE\fR, \fBSIGILL\fR, \fBSIGPIPE\fR, \fBSIGSEGV\fR, \fBSIGXCPU\fR, or \fBSIGXFSZ\fR) then the monitor process starts a new copy of it\[char46] If the daemon dies or exits for another reason, the monitor process exits\[char46] +.IP +This option is normally used with \fB\-\-detach\fR, but it also functions without it\[char46] +.TP +\fB\-\-no\-chdir\fR +By default, when \fB\-\-detach\fR is specified, the daemon changes its current working directory to the root directory after it detaches\[char46] Otherwise, invoking the daemon from a carelessly chosen directory would prevent the administrator from unmounting the file system that holds that directory\[char46] +.IP +Specifying \fB\-\-no\-chdir\fR suppresses this behavior, preventing the daemon from changing its current working directory\[char46] 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\[char46] +.IP +This option has no effect when \fB\-\-detach\fR is not specified\[char46] +.TP +\fB\-\-no\-self\-confinement\fR +By default this daemon will try to self-confine itself to work with files under well-known directories determined at build time\[char46] 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\[char46] Note that in contrast to other access control implementations that are typically enforced from kernel-space (e\[char46]g\[char46] 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 additional layer of security\[char46] +.TP +\fB\-\-user=\fR\fIuser\fR\fB:\fR\fIgroup\fR +Causes this program to run as a different user specified in \fIuser\fR\fB:\fR\fIgroup\fR, thus dropping most of the root privileges\[char46] Short forms \fIuser\fR and \fB:\fR\fIgroup\fR are also allowed, with current user or group assumed, respectively\[char46] Only daemons started by the root user accepts this argument\[char46] +.IP +On Linux, daemons will be granted \fBCAP_IPC_LOCK\fR and \fBCAP_NET_BIND_SERVICES\fR before dropping root privileges\[char46] Daemons that interact with a datapath, such as \fBovs\-vswitchd\fR, will be granted three additional capabilities, namely \fBCAP_NET_ADMIN\fR, \fBCAP_NET_BROADCAST\fR and \fBCAP_NET_RAW\fR\[char46] The capability change will apply even if the new user is root\[char46] +.IP +On Windows, this option is not currently supported\[char46] For security reasons, specifying this option will cause the daemon process not to start\[char46] +.SS "Logging options" +.TP +\fB\-v\fR[\fIspec\fR] +.TQ .5in +\fB\-\-verbose=\fR[\fIspec\fR] +Sets logging levels\[char46] Without any \fIspec\fR, sets the log level for every module and destination to \fBdbg\fR\[char46] Otherwise, \fIspec\fR is a list of words separated by spaces or commas or colons, up to one from each category below: +.RS +.IP \(bu +A valid module name, as displayed by the \fBvlog/list\fR command on \fBovs\-appctl\fR(8), limits the log level change to the specified module\[char46] +.IP \(bu +\fBsyslog\fR, \fBconsole\fR, or \fBfile\fR, to limit the log level change to only to the system log, to the console, or to a file, respectively\[char46] (If \fB\-\-detach\fR is specified, the daemon closes its standard file descriptors, so logging to the console will have no effect\[char46]) +.IP +On Windows platform, \fBsyslog\fR is accepted as a word and is only useful along with the \fB\-\-syslog\-target\fR option (the word has no effect otherwise)\[char46] +.IP \(bu +\fBoff\fR, \fBemer\fR, \fBerr\fR, \fBwarn\fR, \fBinfo\fR, or \fBdbg\fR, to control the log level\[char46] Messages of the given severity or higher will be logged, and messages of lower severity will be filtered out\[char46] \fBoff\fR filters out all messages\[char46] See \fBovs\-appctl\fR(8) for a definition of each log level\[char46] +.RE +.IP +Case is not significant within \fIspec\fR\[char46] +.IP +Regardless of the log levels set for \fBfile\fR, logging to a file will not take place unless \fB\-\-log\-file\fR is also specified (see below)\[char46] +.IP +For compatibility with older versions of OVS, \fBany\fR is accepted as a word but has no effect\[char46] +.TP +\fB\-v\fR +.TQ .5in +\fB\-\-verbose\fR +Sets the maximum logging verbosity level, equivalent to \fB\-\-verbose=dbg\fR\[char46] +.TP +\fB\-vPATTERN:\fR\fIdestination\fR\fB:\fR\fIpattern\fR +.TQ .5in +\fB\-\-verbose=PATTERN:\fR\fIdestination\fR\fB:\fR\fIpattern\fR +Sets the log pattern for \fIdestination\fR to \fIpattern\fR\[char46] Refer to \fBovs\-appctl\fR(8) for a description of the valid syntax for \fIpattern\fR\[char46] +.TP +\fB\-vFACILITY:\fR\fIfacility\fR +.TQ .5in +\fB\-\-verbose=FACILITY:\fR\fIfacility\fR +Sets the RFC5424 facility of the log message\[char46] \fIfacility\fR can be one of \fBkern\fR, \fBuser\fR, \fBmail\fR, \fBdaemon\fR, \fBauth\fR, \fBsyslog\fR, \fBlpr\fR, \fBnews\fR, \fBuucp\fR, \fBclock\fR, \fBftp\fR, \fBntp\fR, \fBaudit\fR, \fBalert\fR, \fBclock2\fR, \fBlocal0\fR, \fBlocal1\fR, \fBlocal2\fR, \fBlocal3\fR, \fBlocal4\fR, \fBlocal5\fR, \fBlocal6\fR or \fBlocal7\fR\[char46] If this option is not specified, \fBdaemon\fR is used as the default for the local system syslog and \fBlocal0\fR is used while sending a message to the target provided via the \fB\-\-syslog\-target\fR option\[char46] +.TP +\fB\-\-log\-file\fR[\fB=\fR\fIfile\fR] +Enables logging to a file\[char46] If \fIfile\fR is specified, then it is used as the exact name for the log file\[char46] The default log file name used if \fIfile\fR is omitted is \fB/usr/local/var/log/ovn/\fIprogram\fB\[char46]log\fR\[char46] +.TP +\fB\-\-syslog\-target=\fR\fIhost\fR\fB:\fR\fIport\fR +Send syslog messages to UDP \fIport\fR on \fIhost\fR, in addition to the system syslog\[char46] The \fIhost\fR must be a numerical IP address, not a hostname\[char46] +.TP +\fB\-\-syslog\-method=\fR\fImethod\fR +Specify \fImethod\fR as how syslog messages should be sent to syslog daemon\[char46] The following forms are supported: +.RS +.IP \(bu +\fBlibc\fR, to use the libc \fBsyslog()\fR function\[char46] Downside of using this options is that libc adds fixed prefix to every message before it is actually sent to the syslog daemon over \fB/dev/log\fR UNIX domain socket\[char46] +.IP \(bu +\fBunix:\fIfile\fB\fR, to use a UNIX domain socket directly\[char46] It is possible to specify arbitrary message format with this option\[char46] However, \fBrsyslogd 8\[char46]9\fR and older versions use hard coded parser function anyway that limits UNIX domain socket use\[char46] If you want to use arbitrary message format with older \fBrsyslogd\fR versions, then use UDP socket to localhost IP address instead\[char46] +.IP \(bu +\fBudp:\fIip\fB:\fIport\fB\fR, to use a UDP socket\[char46] With this method it is possible to use arbitrary message format also with older \fBrsyslogd\fR\[char46] When sending syslog messages over UDP socket extra precaution needs to be taken into account, for example, 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\[char46] +.IP \(bu +\fBnull\fR, to discard all messages logged to syslog\[char46] +.RE +.IP +The default is taken from the \fBOVS_SYSLOG_METHOD\fR environment variable; if it is unset, the default is \fBlibc\fR\[char46] +.SS "Table Formatting Options" +These options control the format of output from the \fBlist\fR and \fBfind\fR commands\[char46] +.RS +.TP +\fB\-f\fR \fIformat\fR +.TQ .5in +\fB\-\-format=\fR\fIformat\fR +Sets the type of table formatting\[char46] The following types of \fIformat\fR are available: +.RS +.TP +\fBtable\fR +2-D text tables with aligned columns\[char46] +.TP +\fBlist\fR (default) +A list with one column per line and rows separated by a blank line\[char46] +.TP +\fBhtml\fR +HTML tables\[char46] +.TP +\fBcsv\fR +Comma-separated values as defined in RFC 4180\[char46] +.TP +\fBjson\fR +JSON format as defined in RFC 4627\[char46] The output is a sequence of JSON objects, each of which corresponds to one table\[char46] Each JSON object has the following members with the noted values: +.RS +.TP +\fBcaption\fR +The table\(cqs caption\[char46] This member is omitted if the table has no caption\[char46] +.TP +\fBheadings\fR +An array with one element per table column\[char46] Each array element is a string giving the corresponding column\(cqs heading\[char46] +.TP +\fBdata\fR +An array with one element per table row\[char46] Each element is also an array with one element per table column\[char46] The elements of this second-level array are the cells that constitute the table\[char46] Cells that represent OVSDB data or data types are expressed in the format described in the OVSDB specification; other cells are simply expressed as text strings\[char46] +.RE +.RE +.TP +\fB\-d\fR \fIformat\fR +.TQ .5in +\fB\-\-data=\fR\fIformat\fR +Sets the formatting for cells within output tables unless the table format is set to \fBjson\fR, in which case \fBjson\fR formatting is always used when formatting cells\[char46] The following types of \fIformat\fR are available: +.RS +.TP +\fBstring\fR (default) +The simple format described in the \fBDatabase Values\fR section of \fBovs\-vsctl\fR(8)\[char46] +.TP +\fBbare\fR +The simple format with punctuation stripped off: \fB[]\fR and \fB{}\fR are omitted around sets, maps, and empty columns, items within sets and maps are space-separated, and strings are never quoted\[char46] This format may be easier for scripts to parse\[char46] +.TP +\fBjson\fR +The RFC 4627 JSON format as described above\[char46] +.RE +.TP +\fB\-\-no\-headings\fR +This option suppresses the heading row that otherwise appears in the first row of table output\[char46] +.TP +\fB\-\-pretty\fR +By default, JSON in output is printed as compactly as possible\[char46] This option causes JSON in output to be printed in a more readable fashion\[char46] Members of objects and elements of arrays are printed one per line, with indentation\[char46] +.IP +This option does not affect JSON in tables, which is always printed compactly\[char46] +.TP +\fB\-\-bare\fR +Equivalent to \fB\-\-format=list \-\-data=bare \-\-no\-headings\fR\[char46] +.RE +.SS "PKI Options" +.PP +.PP +PKI configuration is required to use SSL for the connection to the database\[char46] +.RS +.TP +\fB\-p\fR \fIprivkey\[char46]pem\fR +.TQ .5in +\fB\-\-private\-key=\fR\fIprivkey\[char46]pem\fR +Specifies a PEM file containing the private key used as identity for outgoing SSL connections\[char46] +.TP +\fB\-c\fR \fIcert\[char46]pem\fR +.TQ .5in +\fB\-\-certificate=\fR\fIcert\[char46]pem\fR +Specifies a PEM file containing a certificate that certifies the private key specified on \fB\-p\fR or \fB\-\-private\-key\fR to be trustworthy\[char46] The certificate must be signed by the certificate authority (CA) that the peer in SSL connections will use to verify it\[char46] +.TP +\fB\-C\fR \fIcacert\[char46]pem\fR +.TQ .5in +\fB\-\-ca\-cert=\fR\fIcacert\[char46]pem\fR +Specifies a PEM file containing the CA certificate for verifying certificates presented to this program by SSL peers\[char46] (This may be the same certificate that SSL peers use to verify the certificate specified on \fB\-c\fR or \fB\-\-certificate\fR, or it may be a different one, depending on the PKI design in use\[char46]) +.TP +\fB\-C none\fR +.TQ .5in +\fB\-\-ca\-cert=none\fR +Disables verification of certificates presented by SSL peers\[char46] This introduces a security risk, because it means that certificates cannot be verified to be those of known trusted hosts\[char46] +.RE +.RS +.TP +\fB\-\-bootstrap\-ca\-cert=\fR\fIcacert\[char46]pem\fR +When \fIcacert\[char46]pem\fR exists, this option has the same effect as \fB\-C\fR or \fB\-\-ca\-cert\fR\[char46] If it does not exist, then the executable will attempt to obtain the CA certificate from the SSL peer on its first SSL connection and save it to the named PEM file\[char46] 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\[char46] +.IP +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\[char46] +.IP +This option is only useful if the SSL peer sends its CA certificate as part of the SSL certificate chain\[char46] The SSL protocol does not require the server to send the CA certificate\[char46] +.IP +This option is mutually exclusive with \fB\-C\fR and \fB\-\-ca\-cert\fR\[char46] +.RE +.SS "Other Options" +.TP +\fB\-h\fR +.TQ .5in +\fB\-\-help\fR +Prints a brief help message to the console\[char46] +.TP +\fB\-V\fR +.TQ .5in +\fB\-\-version\fR +Prints version information to the console\[char46] +.SH "COMMANDS" +.PP +.PP +The following sections describe the commands that \fBovn\-nbctl\fR supports\[char46] +.SS "General Commands" +.TP +\fBinit\fR +Initializes the database, if it is empty\[char46] If the database has already been initialized, this command has no effect\[char46] +.TP +\fBshow [\fIswitch\fB | \fIrouter\fB]\fR +Prints a brief overview of the database contents\[char46] If \fIswitch\fR is provided, only records related to that logical switch are shown\[char46] If \fIrouter\fR is provided, only records related to that logical router are shown\[char46] +.SS "Logical Switch Commands" +.TP +\fBls\-add\fR +Creates a new, unnamed logical switch, which initially has no ports\[char46] The switch does not have a name, other commands must refer to this switch by its UUID\[char46] +.TP +[\fB\-\-may\-exist\fR | \fB\-\-add\-duplicate\fR] \fBls\-add\fR \fIswitch\fR +Creates a new logical switch named \fIswitch\fR, which initially has no ports\[char46] +.IP +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, making duplicate names unhelpful\[char46] Thus, without any options, this command regards it as an error if \fIswitch\fR is a duplicate name\[char46] With \fB\-\-may\-exist\fR, adding a duplicate name succeeds but does not create a new logical switch\[char46] With \fB\-\-add\-duplicate\fR, the command really creates a new logical switch with a duplicate name\[char46] It is an error to specify both options\[char46] If there are multiple logical switches with a duplicate name, configure the logical switches using the UUID instead of the \fIswitch\fR name\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBls\-del\fR \fIswitch\fR +Deletes \fIswitch\fR\[char46] It is an error if \fIswitch\fR does not exist, unless \fB\-\-if\-exists\fR is specified\[char46] +.TP +\fBls\-list\fR +Lists all existing switches on standard output, one per line\[char46] +.SS "ACL Commands" +.PP +.PP +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] [\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}] [\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]] +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] +.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 +\fBqos\-del\fR \fIswitch\fR [\fIdirection\fR [\fIpriority\fR \fImatch\fR]] +Deletes QoS rules from \fIswitch\fR\[char46] If only \fIswitch\fR is supplied, all the QoS rules from the logical switch are deleted\[char46] If \fIdirection\fR is also specified, then all the flows in that direction will be deleted from the logical switch\[char46] If all the fields are supplied, then a single flow that matches the given fields will be deleted\[char46] +.IP +If \fIswitch\fR and \fIuuid\fR are supplied, then the QoS rule with specified uuid is deleted\[char46] +.TP +\fBqos\-list\fR \fIswitch\fR +Lists the QoS rules on \fIswitch\fR\[char46] +.SS "Meter Commands" +.TP +\fBmeter\-add\fR \fIname\fR \fIaction\fR \fIrate\fR \fIunit\fR [\fIburst\fR] +Adds the specified meter\[char46] \fIname\fR must be a unique name to identify this meter\[char46] The \fIaction\fR argument specifies what should happen when this meter is exceeded\[char46] The only supported action is \fBdrop\fR\[char46] +.IP +The \fIunit\fR specifies the unit for the \fIrate\fR argument; valid values are \fBkbps\fR and \fBpktps\fR for kilobits per second and packets per second, respectively\[char46] The \fIburst\fR option configures the maximum burst allowed for the band in kilobits or packets depending on whether the \fIunit\fR chosen was \fBkbps\fR or \fBpktps\fR, respectively\[char46] If a burst is not supplied, the switch is free to select some reasonable value depending on its configuration\[char46] +.IP +\fBovn\-nbctl\fR only supports adding a meter with a single band, but the other commands support meters with multiple bands\[char46] +.IP +Names that start with \(dq__\(dq (two underscores) are reserved for internal use by OVN, so \fBovn\-nbctl\fR does not allow adding them\[char46] +.TP +\fBmeter\-del\fR [\fIname\fR] +Deletes meters\[char46] By default, all meters are deleted\[char46] If \fIname\fR is supplied, only the meter with that name will be deleted\[char46] +.TP +\fBmeter\-list\fR +Lists all meters\[char46] +.SS "Logical Switch Port Commands" +.TP +[\fB\-\-may\-exist\fR] \fBlsp\-add\fR \fIswitch\fR \fIport\fR +Creates on \fIlswitch\fR a new logical switch port named \fIport\fR\[char46] +.IP +It is an error if a logical port named \fIport\fR already exists, unless \fB\-\-may\-exist\fR is specified\[char46] Regardless of \fB\-\-may\-exist\fR, it is an error if the existing port is in some logical switch other than \fIswitch\fR or if it has a parent port\[char46] +.TP +[\fB\-\-may\-exist\fR] \fBlsp\-add\fR \fIswitch\fR \fIport\fR \fIparent\fR \fItag_request\fR +Creates on \fIswitch\fR a logical switch port named \fIport\fR that is a child of \fIparent\fR that is identified with VLAN ID \fItag_request\fR, which must be between \fB0\fR and \fB4095\fR, inclusive\[char46] If \fItag_request\fR is \fB0\fR, \fBovn\-northd\fR generates a tag that is unique in the scope of \fIparent\fR\[char46] This is useful in cases such as virtualized container environments where Open vSwitch does not have a direct connection to the container\(cqs port and it must be shared with the virtual machine\(cqs port\[char46] +.IP +It is an error if a logical port named \fIport\fR already exists, unless \fB\-\-may\-exist\fR is specified\[char46] Regardless of \fB\-\-may\-exist\fR, it is an error if the existing port is not in \fIswitch\fR or if it does not have the specified \fIparent\fR and \fItag_request\fR\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBlsp\-del\fR \fIport\fR +Deletes \fIport\fR\[char46] It is an error if \fIport\fR does not exist, unless \fB\-\-if\-exists\fR is specified\[char46] +.TP +\fBlsp\-list\fR \fIswitch\fR +Lists all the logical switch ports within \fIswitch\fR on standard output, one per line\[char46] +.TP +\fBlsp\-get\-parent\fR \fIport\fR +If set, get the parent port of \fIport\fR\[char46] If not set, print nothing\[char46] +.TP +\fBlsp\-get\-tag\fR \fIport\fR +If set, get the tag for \fIport\fR traffic\[char46] If not set, print nothing\[char46] +.TP +\fBlsp\-set\-addresses\fR \fIport\fR [\fIaddress\fR]\[char46]\[char46]\[char46] +Sets the addresses associated with \fIport\fR to \fIaddress\fR\[char46] Each \fIaddress\fR should be one of the following: +.RS +.TP +an Ethernet address, optionally followed by a space and one or more IP addresses +OVN delivers packets for the Ethernet address to this port\[char46] +.TP +\fBunknown\fR +OVN delivers unicast Ethernet packets whose destination MAC address is not in any logical port\(cqs addresses column to ports with address \fBunknown\fR\[char46] +.TP +\fBdynamic\fR +Use this keyword to make \fBovn\-northd\fR generate a globally unique MAC address and choose an unused IPv4 address with the logical port\(cqs subnet and store them in the port\(cqs \fBdynamic_addresses\fR column\[char46] +.TP +\fBrouter\fR +Accepted only when the \fBtype\fR of the logical switch port is \fBrouter\fR\[char46] 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 \fBrouter\-port\fR in \fBlsp\-set\-options\fR\[char46] +.RE +.IP +Multiple addresses may be set\[char46] If no \fIaddress\fR argument is given, \fIport\fR will have no addresses associated with it\[char46] +.TP +\fBlsp\-get\-addresses\fR \fIport\fR +Lists all the addresses associated with \fIport\fR on standard output, one per line\[char46] +.TP +\fBlsp\-set\-port\-security\fR \fIport\fR [\fIaddrs\fR]\[char46]\[char46]\[char46] +Sets the port security addresses associated with \fIport\fR to \fIaddrs\fR\[char46] Multiple sets of addresses may be set by using multiple \fIaddrs\fR arguments\[char46] If no \fIaddrs\fR argument is given, \fIport\fR will not have port security enabled\[char46] +.IP +Port security limits the addresses from which a logical port may send packets and to which it may receive packets\[char46] See the \fBovn\-nb\fR(5) documentation for the \fBport_security\fR column in the \fBLogical_Switch_Port\fR table for details\[char46] +.TP +\fBlsp\-get\-port\-security\fR \fIport\fR +Lists all the port security addresses associated with \fIport\fR on standard output, one per line\[char46] +.TP +\fBlsp\-get\-up\fR \fIport\fR +Prints the state of \fIport\fR, either \fBup\fR or \fBdown\fR\[char46] +.TP +\fBlsp\-set\-enabled\fR \fIport\fR \fIstate\fR +Set the administrative state of \fIport\fR, either \fBenabled\fR or \fBdisabled\fR\[char46] When a port is disabled, no traffic is allowed into or out of the port\[char46] +.TP +\fBlsp\-get\-enabled\fR \fIport\fR +Prints the administrative state of \fIport\fR, either \fBenabled\fR or \fBdisabled\fR\[char46] +.TP +\fBlsp\-set\-type\fR \fIport\fR \fItype\fR +Set the type for the logical port\[char46] The type must be one of the following: +.RS +.TP +\fB(empty string)\fR +A VM (or VIF) interface\[char46] +.TP +\fBrouter\fR +A connection to a logical router\[char46] +.TP +\fBlocalnet\fR +A connection to a locally accessible network from each ovn-controller instance\[char46] A logical switch can only have a single localnet port attached\[char46] This is used to model direct connectivity to an existing network\[char46] +.TP +\fBlocalport\fR +A connection to a local VIF\[char46] Traffic that arrives on a localport is never forwarded over a tunnel to another chassis\[char46] These ports are present on every chassis and have the same address in all of them\[char46] This is used to model connectivity to local services that run on every hypervisor\[char46] +.TP +\fBl2gateway\fR +A connection to a physical network\[char46] +.TP +\fBvtep\fR +A port to a logical switch on a VTEP gateway\[char46] +.RE +.TP +\fBlsp\-get\-type\fR \fIport\fR +Get the type for the logical port\[char46] +.TP +\fBlsp\-set\-options\fR \fIport\fR [\fIkey=value\fR]\[char46]\[char46]\[char46] +Set type-specific key-value options for the logical port\[char46] +.TP +\fBlsp\-get\-options\fR \fIport\fR +Get the type-specific options for the logical port\[char46] +.TP +\fBlsp\-set\-dhcpv4\-options\fR \fIport\fR \fIdhcp_options\fR +Set the DHCPv4 options for the logical port\[char46] The \fIdhcp_options\fR is a UUID referring to a set of DHCP options in the \fBDHCP_Options\fR table\[char46] +.TP +\fBlsp\-get\-dhcpv4\-options\fR \fIport\fR +Get the configured DHCPv4 options for the logical port\[char46] +.TP +\fBlsp\-set\-dhcpv6\-options\fR \fIport\fR \fIdhcp_options\fR +Set the DHCPv6 options for the logical port\[char46] The \fIdhcp_options\fR is a UUID referring to a set of DHCP options in the \fBDHCP_Options\fR table\[char46] +.TP +\fBlsp\-get\-dhcpv6\-options\fR \fIport\fR +Get the configured DHCPv6 options for the logical port\[char46] +.TP +\fBlsp\-get\-ls\fR \fIport\fR +Get the logical switch which the \fIport\fR belongs to\[char46] +.TP +\fBlsp\-attach\-mirror\fR \fIport\fR \fIm\fR +Attaches the mirror \fIm\fR to the logical port \fIport\fR\[char46] +.TP +\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 +[\fB\-\-liveness\fR]\fBfwd\-group\-add\fR \fIgroup\fR \fIswitch\fR \fIvip\fR \fIvmac\fR \fIports\fR +Creates a new forwarding group named \fIgroup\fR as the name with the provided \fIvip\fR and \fIvmac\fR\[char46] \fIvip\fR should be a virtual IP address and \fIvmac\fR should be a virtual MAC address to access the forwarding group\[char46] \fIports\fR are the logical switch port names that are put in the forwarding group\[char46] Example for \fIports\fR is lsp1 lsp2 \[char46]\[char46]\[char46] Traffic destined to virtual IP of the forwarding group will be load balanced to all the child ports\[char46] +.IP +When \fB\-\-liveness\fR is specified then child ports are expected to be bound to external devices like routers\[char46] BFD should be configured between hypervisors and the external devices\[char46] The child port selection will become dependent on BFD status with its external device\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBfwd\-group\-del\fR \fIgroup +\fR +Deletes \fIgroup\fR\[char46] It is an error if \fIgroup\fR does not exist, unless \fB\-\-if\-exists\fR is specified\[char46] +.TP +\fBfwd\-group\-list\fR [\fIswitch\fR] +Lists all existing forwarding groups, If \fIswitch\fR is specified then only the forwarding groups configured for \fIswitch\fR will be listed\[char46] +.SS "Logical Router Commands" +.TP +\fBlr\-add\fR +Creates a new, unnamed logical router, which initially has no ports\[char46] The router does not have a name, other commands must refer to this router by its UUID\[char46] +.TP +[\fB\-\-may\-exist\fR | \fB\-\-add\-duplicate\fR] \fBlr\-add\fR \fIrouter\fR +Creates a new logical router named \fIrouter\fR, which initially has no ports\[char46] +.IP +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, making duplicate names unhelpful\[char46] Thus, without any options, this command regards it as an error if \fIrouter\fR is a duplicate name\[char46] With \fB\-\-may\-exist\fR, adding a duplicate name succeeds but does not create a new logical router\[char46] With \fB\-\-add\-duplicate\fR, the command really creates a new logical router with a duplicate name\[char46] It is an error to specify both options\[char46] If there are multiple logical routers with a duplicate name, configure the logical routers using the UUID instead of the \fIrouter\fR name\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBlr\-del\fR \fIrouter\fR +Deletes \fIrouter\fR\[char46] It is an error if \fIrouter\fR does not exist, unless \fB\-\-if\-exists\fR is specified\[char46] +.TP +\fBlr\-list\fR +Lists all existing routers on standard output, one per line\[char46] +.SS "Logical Router Port Commands" +.TP +[\fB\-\-may\-exist\fR] \fBlrp\-add\fR \fIrouter\fR \fIport\fR \fImac\fR \fInetwork\fR\[char46]\[char46]\[char46] [\fBpeer=\fR\fIpeer\fR] +Creates on \fIrouter\fR a new logical router port named \fIport\fR with Ethernet address \fImac\fR and one or more IP address/netmask for each \fInetwork\fR\[char46] +.IP +The optional argument \fBpeer\fR identifies a logical router port that connects to this one\[char46] The following example adds a router port with an IPv4 and IPv6 address with peer \fBlr1\fR: +.IP +\fBlrp\-add lr0 lrp0 00:11:22:33:44:55 192\[char46]168\[char46]0\[char46]1/24 2001:db8::1/64 peer=lr1\fR +.IP +It is an error if a logical router port named \fIport\fR already exists, unless \fB\-\-may\-exist\fR is specified\[char46] Regardless of \fB\-\-may\-exist\fR, it is an error if the existing router port is in some logical router other than \fIrouter\fR\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBlrp\-del\fR \fIport\fR +Deletes \fIport\fR\[char46] It is an error if \fIport\fR does not exist, unless \fB\-\-if\-exists\fR is specified\[char46] +.TP +\fBlrp\-list\fR \fIrouter\fR +Lists all the logical router ports within \fIrouter\fR on standard output, one per line\[char46] +.TP +\fBlrp\-set\-enabled\fR \fIport\fR \fIstate\fR +Set the administrative state of \fIport\fR, either \fBenabled\fR or \fBdisabled\fR\[char46] When a port is disabled, no traffic is allowed into or out of the port\[char46] +.TP +\fBlrp\-get\-enabled\fR \fIport\fR +Prints the administrative state of \fIport\fR, either \fBenabled\fR or \fBdisabled\fR\[char46] +.TP +\fBlrp\-set\-gateway\-chassis\fR \fIport\fR \fIchassis\fR [\fIpriority\fR] +Set gateway chassis for \fIport\fR\[char46] \fIchassis\fR is the name of the chassis\[char46] This creates a gateway chassis entry in Gateway_Chassis table\[char46] It won\(cqt check if chassis really exists in OVN_Southbound database\[char46] Priority will be set to 0 if \fIpriority\fR is not provided by user\[char46] \fIpriority\fR must be between \fB0\fR and \fB32767\fR, inclusive\[char46] +.TP +\fBlrp\-del\-gateway\-chassis\fR \fIport\fR \fIchassis\fR +Deletes gateway chassis from \fIport\fR\[char46] It is an error if gateway chassis with \fIchassis\fR for \fIport\fR does not exist\[char46] +.TP +\fBlrp\-get\-gateway\-chassis\fR \fIport\fR +Lists all the gateway chassis with priority within \fIport\fR on standard output, one per line, ordered based on priority\[char46] +.SS "Logical Router Static Route Commands" +.TP +[\fB\-\-may\-exist\fR] [\fB\-\-policy\fR=\fIPOLICY\fR] [\fB\-\-ecmp\fR] [\fB\-\-ecmp\-symmetric\-reply\fR] [\fB\-\-bfd[=\fIUUID\fB\fR]] \fBlr\-route\-add\fR \fIrouter\fR \fIprefix\fR \fInexthop\fR [\fIport\fR] +Adds the specified route to \fIrouter\fR\[char46] \fIprefix\fR describes an IPv4 or IPv6 prefix for this route, such as \fB192\[char46]168\[char46]100\[char46]0/24\fR\[char46] \fInexthop\fR specifies the gateway to use for this route, which should be the IP address of one of \fIrouter\fR logical router ports or the IP address of a logical port\[char46] If \fIport\fR is specified, packets that match this route will be sent out that port\[char46] When \fIport\fR is omitted, OVN infers the output port based on \fInexthop\fR\[char46] Nexthop can be set to \fIdiscard\fR for dropping packets which match the given route\[char46] +.IP +\fB\-\-policy\fR describes the policy used to make routing decisions\[char46] This should be one of \(dqdst-ip\(dq or \(dqsrc-ip\(dq\[char46] If not specified, the default is \(dqdst-ip\(dq\[char46] +.IP +The \fB\-\-ecmp\fR option allows for multiple routes with the same \fIprefix\fR \fIPOLICY\fR but different \fInexthop\fR and \fIport\fR to be added\[char46] +.IP +The \fB\-\-ecmp\-symmetric\-reply\fR option makes it so that traffic that arrives over an ECMP route will have its reply traffic sent out over that same route\[char46] Setting \fB\-\-ecmp\-symmetric\-reply\fR implies \fB\-\-ecmp\fR so it is not necessary to set both\[char46] +.IP +\fB\-\-bfd\fR option is used to link a BFD session to the OVN route\[char46] 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\[char46] If the lookup fails and \fIport\fR is specified, a new entry in the BFD table will be created using the \fInexthop\fR as \fIdst_ip\fR and \fIport\fR as \fIlogical_port\fR\[char46] +.IP +It is an error if a route with \fIprefix\fR and \fIPOLICY\fR already exists, unless \fB\-\-may\-exist\fR, \fB\-\-ecmp\fR, or \fB\-\-ecmp\-symmetric\-reply\fR is specified\[char46] If \fB\-\-may\-exist\fR is specified but not \fB\-\-ecmp\fR or \fB\-\-ecmp\-symmetric\-reply\fR, the existed route will be updated with the new nexthop and port\[char46] If \fB\-\-ecmp\fR or \fB\-\-ecmp\-symmetric\-reply\fR is specified, a new route will be added, regardless of the existed route\[char46], which is useful when adding ECMP routes, i\[char46]e\[char46] routes with same \fIPOLICY\fR and \fIprefix\fR but different \fInexthop\fR and \fIport\fR\[char46] +.TP +[\fB\-\-if\-exists\fR] [\fB\-\-policy\fR=\fIPOLICY\fR] \fBlr\-route\-del\fR \fIrouter\fR [\fIprefix\fR [\fInexthop\fR [\fIport\fR]]] +Deletes routes from \fIrouter\fR\[char46] If only \fIrouter\fR is supplied, all the routes from the logical router are deleted\[char46] If \fIPOLICY\fR, \fIprefix\fR, \fInexthop\fR and/or \fIport\fR are also specified, then all the routes that match the conditions will be deleted from the logical router\[char46] +.IP +It is an error if there is no matching route entry, unless \fB\-\-if\-exists\fR is specified\[char46] +.TP +\fBlr\-route\-list\fR \fIrouter\fR +Lists the routes on \fIrouter\fR\[char46] +.SS "Logical Router Policy Commands" +.TP +[\fB\-\-may\-exist\fR]\fBlr\-policy\-add\fR \fIrouter\fR \fIpriority\fR \fImatch\fR \fIaction\fR [\fInexthop\fR[,\fInexthop\fR,\[char46]\[char46]\[char46]]] [\fIoptions key=value]\fR] +Add Policy to \fIrouter\fR which provides a way to configure permit/deny and reroute policies on the router\[char46] Permit/deny policies are similar to OVN ACLs, but exist on the logical-router\[char46] Reroute policies are needed for service-insertion and service-chaining\[char46] \fInexthop\fR is an optional parameter\[char46] It needs to be provided only when \fIaction\fR is \fIreroute\fR\[char46] Multiple \fBnexthops\fR can be specified for ECMP routing\[char46] A policy is uniquely identified by \fIpriority\fR and \fImatch\fR\[char46] Multiple policies can have the same \fIpriority\fR\[char46] \fIoptions\fR sets the router policy options as key-value pair\[char46] The supported option is : \fBpkt_mark\fR\[char46] +.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 +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] +.IP +\fB +lr\-policy\-add lr1 100 ip4\[char46]src == 192\[char46]168\[char46]100\[char46]0/24 allow +pkt_mark=100 +\fR\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBlr\-policy\-del\fR \fIrouter\fR [\fI{priority | uuid} [match]\fR] +Deletes polices from \fIrouter\fR\[char46] If only \fIrouter\fR is supplied, all the polices from the logical router are deleted\[char46] If \fIpriority\fR and/or \fImatch\fR are also specified, then all the polices that match the conditions will be deleted from the logical router\[char46] +.IP +If \fIrouter\fR and \fIuuid\fR are supplied, then the policy with specified uuid is deleted\[char46] It is an error if \fIuuid\fR does not exist, unless \fB\-\-if\-exists\fR is specified\[char46] +.TP +\fBlr\-policy\-list\fR \fIrouter\fR +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] +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] +.IP +\fB\-\-gateway\-port\fR option allows specifying the distributed gateway port of \fIrouter\fR where the NAT rule needs to be applied\[char46] \fIGATEWAY_PORT\fR should reference a \fBLogical_Router_Port\fR row that is a distributed gateway port of \fIrouter\fR\[char46] When \fIrouter\fR has multiple distributed gateway ports and the gateway port for this NAT can\(cqt be inferred from the \fIexternal_ip\fR, it is an error to not specify the \fIGATEWAY_PORT\fR\[char46] +.IP +When \fItype\fR is \fBdnat\fR, the externally visible IP address \fIexternal_ip\fR is DNATted to the IP address \fIlogical_ip\fR in the logical space\[char46] +.IP +When \fItype\fR is \fBsnat\fR, IP packets with their source IP address that either matches the IP address in \fIlogical_ip\fR or is in the network provided by \fIlogical_ip\fR is SNATed into the IP address in \fIexternal_ip\fR\[char46] +.IP +When \fItype\fR is \fBdnat_and_snat\fR, the externally visible IP address \fIexternal_ip\fR is DNATted to the IP address \fIlogical_ip\fR in the logical space\[char46] In addition, IP packets with the source IP address that matches \fIlogical_ip\fR is SNATed into the IP address in \fIexternal_ip\fR\[char46] +.IP +When the \fIlogical_port\fR and \fIexternal_mac\fR are specified, the NAT rule will be programmed on the chassis where the \fIlogical_port\fR resides\[char46] This includes ARP replies for the \fIexternal_ip\fR, which return the value of \fIexternal_mac\fR\[char46] All packets transmitted with source IP address equal to \fIexternal_ip\fR will be sent using the \fIexternal_mac\fR\[char46] +.IP +It is an error if a NAT already exists with the same values of \fIrouter\fR, \fItype\fR, \fIexternal_ip\fR, \fIlogical_ip\fR and \fIGATEWAY_PORT\fR (in case of multiple distributed gateway ports), unless \fB\-\-may\-exist\fR is specified\[char46] When \fB\-\-may\-exist\fR, \fIlogical_port\fR, and \fIexternal_mac\fR are all specified, the existing values of \fIlogical_port\fR and \fIexternal_mac\fR are overwritten\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBlr\-nat\-del\fR \fIrouter\fR [\fItype\fR [\fIip\fR] [\fIgateway_port\fR]] +Deletes NATs from \fIrouter\fR\[char46] If only \fIrouter\fR is supplied, all the NATs from the logical router are deleted\[char46] If \fItype\fR is also specified, then all the NATs that match the \fItype\fR will be deleted from the logical router\[char46] If \fIip\fR is also specified without specifying \fIgateway_port\fR, then all the NATs that match the \fItype\fR and \fIip\fR will be deleted from the logical router\[char46] If \fIgateway_port\fR is specified without specifying \fIip\fR, then all the NATs that match the \fItype\fR and \fIgateway_port\fR will be deleted from the logical router\[char46] If all the fields are given, then a single NAT rule that matches all the fields will be deleted\[char46] When \fItype\fR is \fBsnat\fR, the \fIip\fR should be logical_ip\[char46] When \fItype\fR is \fBdnat\fR or \fBdnat_and_snat\fR, the \fIip\fR should be external_ip\[char46] +.IP +It is an error if both \fIip\fR and \fIgateway_port\fR are specified and there is no matching NAT entry, unless \fB\-\-if\-exists\fR is specified\[char46] +.TP +\fBlr\-nat\-list\fR \fIrouter\fR +Lists the NATs on \fIrouter\fR\[char46] +.SS "Load Balancer Commands" +.TP +[\fB\-\-may\-exist\fR | \fB\-\-add\-duplicate\fR | \fB\-\-reject\fR | \fB\-\-event\fR] \fBlb\-add\fR \fIlb\fR \fIvip\fR \fIips\fR [\fIprotocol\fR] +Creates a new load balancer named \fIlb\fR with the provided \fIvip\fR and \fIips\fR or adds the \fIvip\fR to an existing \fIlb\fR\[char46] \fIvip\fR should be a virtual IP address (or an IP address and a port number with \fB:\fR as a separator)\[char46] Examples for \fIvip\fR are \fB192\[char46]168\[char46]1\[char46]4\fR, \fBfd0f::1\fR, and \fB192\[char46]168\[char46]1\[char46]5:8080\fR\[char46] \fIips\fR should be comma separated IP endpoints (or comma separated IP addresses and port numbers with \fB:\fR as a separator)\[char46] \fIips\fR must be the same address family as \fIvip\fR\[char46] Examples for \fIips\fR are \fB10\[char46]0\[char46]0\[char46]1,10\[char46]0\[char46]0\[char46]2\fRor \fB[fdef::1]:8800,[fdef::2]:8800\fR\[char46] +.IP +The optional argument \fIprotocol\fR must be either \fBtcp\fR, \fBudp\fR or \fBsctp\fR\[char46] This argument is useful when a port number is provided as part of the \fIvip\fR\[char46] If the \fIprotocol\fR is unspecified and a port number is provided as part of the \fIvip\fR, OVN assumes the \fIprotocol\fR to be \fBtcp\fR\[char46] +.IP +It is an error if the \fIvip\fR already exists in the load balancer named \fIlb\fR, unless \fB\-\-may\-exist\fR is specified\[char46] With \fB\-\-add\-duplicate\fR, the command really creates a new load balancer with a duplicate name\[char46] +.IP +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 +If the load balancer is created with \fB\-\-event\fR option and it has no active backends, whenever the lb receives traffic, the event is reported in the Controller_Event table in the SB db\[char46] Please note \fB\-\-event\fR option can\(cqt be specified with \fB\-\-reject\fR one\[char46] +.IP +The following example adds a load balancer\[char46] +.IP +\fBlb\-add lb0 30\[char46]0\[char46]0\[char46]10:80 +192\[char46]168\[char46]10\[char46]10:80,192\[char46]168\[char46]10\[char46]20:80,192\[char46]168\[char46]10\[char46]30:80 udp\fR +.TP +[\fB\-\-if\-exists\fR] \fBlb\-del\fR \fIlb\fR [\fIvip\fR] +Deletes \fIlb\fR or the \fIvip\fR from \fIlb\fR\[char46] If \fIvip\fR is supplied, only the \fIvip\fR will be deleted from the \fIlb\fR\[char46] If only the \fIlb\fR is supplied, the \fIlb\fR will be deleted\[char46] It is an error if \fIvip\fR does not already exist in \fIlb\fR, unless \fB\-\-if\-exists\fR is specified\[char46] +.TP +\fBlb\-list\fR [\fIlb\fR] +Lists the LBs\[char46] If \fIlb\fR is also specified, then only the specified \fIlb\fR will be listed\[char46] +.TP +[\fB\-\-may\-exist\fR] \fBls\-lb\-add\fR \fIswitch\fR \fIlb\fR +Adds the specified \fIlb\fR to \fIswitch\fR\[char46] It is an error if a load balancer named \fIlb\fR already exists in the \fIswitch\fR, unless \fB\-\-may\-exist\fR is specified\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBls\-lb\-del\fR \fIswitch\fR [\fIlb\fR] +Removes \fIlb\fR from \fIswitch\fR\[char46] If only \fIswitch\fR is supplied, all the LBs from the logical switch are removed\[char46] If \fIlb\fR is also specified, then only the \fIlb\fR will be removed from the logical switch\[char46] It is an error if \fIlb\fR does not exist in the \fIswitch\fR, unless \fB\-\-if\-exists\fR is specified\[char46] +.TP +\fBls\-lb\-list\fR \fIswitch\fR +Lists the LBs for the given \fIswitch\fR\[char46] +.TP +[\fB\-\-may\-exist\fR] \fBlr\-lb\-add\fR \fIrouter\fR \fIlb\fR +Adds the specified \fIlb\fR to \fIrouter\fR\[char46] It is an error if a load balancer named \fIlb\fR already exists in the \fIrouter\fR, unless \fB\-\-may\-exist\fR is specified\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBlr\-lb\-del\fR \fIrouter\fR [\fIlb\fR] +Removes \fIlb\fR from \fIrouter\fR\[char46] If only \fIrouter\fR is supplied, all the LBs from the logical router are removed\[char46] If \fIlb\fR is also specified, then only the \fIlb\fR will be removed from the logical router\[char46] It is an error if \fIlb\fR does not exist in the \fIrouter\fR, unless \fB\-\-if\-exists\fR is specified\[char46] +.TP +\fBlr\-lb\-list\fR \fIrouter\fR +Lists the LBs for the given \fIrouter\fR\[char46] +.SS "DHCP Options commands" +.TP +\fBdhcp\-options\-create\fR \fIcidr\fR [\fIkey=value\fR] +Creates a new DHCP Options entry in the \fBDHCP_Options\fR table with the specified \fBcidr\fR and optional \fBexternal\-ids\fR\[char46] +.TP +\fBdhcp\-options\-list\fR +Lists the DHCP Options entries\[char46] +.TP +\fBdhcp\-options\-del\fR \fIdhcp-option\fR +Deletes the DHCP Options entry referred by \fIdhcp-option\fR UUID\[char46] +.TP +\fBdhcp\-options\-set\-options\fR \fIdhcp-option\fR [\fIkey=value\fR]\[char46]\[char46]\[char46] +Set the DHCP Options for the \fIdhcp-option\fR UUID\[char46] +.TP +\fBdhcp\-options\-get\-options\fR \fIdhcp-option\fR +Lists the DHCP Options for the \fIdhcp-option\fR UUID\[char46] +.SS "Port Group commands" +.TP +\fBpg\-add\fR \fIgroup\fR [\fIport\fR]\[char46]\[char46]\[char46] +Creates a new port group in the \fBPort_Group\fR table named \fBgroup\fR with optional \fBports\fR added to the group\[char46] +.TP +\fBpg\-set\-ports\fR \fIgroup\fR \fIport\fR\[char46]\[char46]\[char46] +Sets \fBports\fR on the port group named \fBgroup\fR\[char46] It is an error if \fBgroup\fR does not exist\[char46] +.TP +\fBpg\-del\fR \fIgroup\fR +Deletes port group \fBgroup\fR\[char46] It is an error if \fBgroup\fR does not exist\[char46] +.SS "HA Chassis Group commands" +.TP +\fBha\-chassis\-group\-add\fR \fIgroup\fR +Creates a new HA chassis group in the \fBHA_Chassis_Group\fR table named \fBgroup\fR\[char46] +.TP +\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] +.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] +.TP +\fBha\-chassis\-group\-remove\-chassis\fR \fIgroup\fR \fIchassis\fR +Removes the HA chassis \fBchassis\fR from the HA chassis group \fBgroup\fR\[char46] It is an error if \fBchassis\fR does not exist\[char46] +.SS "Control Plane Protection Policy commands" +.PP +.PP +These commands manage meters configured in \fBCopp\fR table linking them to logical datapaths through \fBcopp\fR column in \fBLogical_Switch\fR or \fBLogical_Router\fR tables\[char46] Protocol packets for which CoPP is enforced when sending packets to ovn-controller (if configured): +.RS +.IP \(bu +ARP +.IP \(bu +ND_NS +.IP \(bu +ND_NA +.IP \(bu +ND_RA +.IP \(bu +ND +.IP \(bu +DNS +.IP \(bu +IGMP +.IP \(bu +packets that require ARP resolution before forwarding +.IP \(bu +packets that require ND_NS before forwarding +.IP \(bu +packets that need to be replied to with ICMP Errors +.IP \(bu +packets that need to be replied to with TCP RST +.IP \(bu +packets that need to be replied to with DHCP_OPTS +.IP \(bu +packets that trigger a reject action +.IP \(bu +packets that trigger a SCTP abort action +.IP \(bu +controller_events +.IP \(bu +BFD +.RE +.RS +.TP +\fBcopp\-add\fR \fIname\fR \fIproto\fR \fImeter\fR +Adds the control \fBproto\fR to \fBmeter\fR mapping to the control plane protection policy \fBname\fR\[char46] If no policy exists yet, it creates one\[char46] If a mapping already existed for \fBproto\fR, this will overwrite it\[char46] +.TP +\fBcopp\-del\fR \fIname\fR [\fIproto\fR] +Removes the control \fBproto\fR mapping for the \fBname\fR control plane protection policy\[char46] If \fBproto\fR is not specified, the whole control plane protection policy is destroyed\[char46] +.TP +\fBcopp\-list\fR \fIname\fR +Display the current control plane protection policy for \fBname\fR\[char46] +.TP +\fBls\-copp\-add\fR \fIname\fR \fIswitch\fR +Adds the control plane protection policy \fBname\fR to the logical switch \fBswitch\fR\[char46] +.TP +\fBlr\-copp\-add\fR \fIname\fR \fIrouter\fR +Adds the control plane protection policy \fBname\fR to the logical router \fBrouter\fR\[char46] +.RE +.SS "Mirror commands" +.TP +\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 , \fBerspan\fR or \fBlocal\fR\[char46] +.IP +\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, \fBto\-lport\fR or \fBboth\fR\[char46] +.IP +\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] +.TP +\fBmirror\-list\fR +Lists the mirrors\[char46] +.SS "Synchronization Commands" +.TP +sync +Ordinarily, \fB\-\-wait=sb\fR or \fB\-\-wait=hv\fR only waits for changes by the current \fBovn\-nbctl\fR invocation to take effect\[char46] This means that, if none of the commands supplied to \fBovn\-nbctl\fR change the database, then the command does not wait at all\[char46] With the \fBsync\fR command, however, \fBovn\-nbctl\fR waits even for earlier changes to the database to propagate down to the southbound database or all of the OVN chassis, according to the argument to \fB\-\-wait\fR\[char46] +.SS "Remote Connectivity Commands" +.PP +.PP +These commands manipulate the \fBconnections\fR column in the \fBNB_Global\fR table and rows in the \fBConnection\fR table\[char46] When \fBovsdb\-server\fR is configured to use the \fBconnections\fR column for OVSDB connections, this allows the administrator to use \fBovn\-nbctl\fR to configure database connections\[char46] +.RS +.TP +\fBget\-connection\fR +Prints the configured connection(s)\[char46] +.TP +\fBdel\-connection\fR +Deletes the configured connection(s)\[char46] +.TP +[\fB\-\-inactivity\-probe=\fR\fImsecs\fR] \fBset\-connection\fR \fItarget\fR\[char46]\[char46]\[char46] +Sets the configured manager target or targets\[char46] Use \fB\-\-inactivity\-probe=\fR\fImsecs\fR to override the default idle connection inactivity probe time\[char46] Use 0 to disable inactivity probes\[char46] +.RE +.SS "SSL Configuration Commands" +.TP +\fBget\-ssl\fR +Prints the SSL configuration\[char46] +.TP +\fBdel\-ssl\fR +Deletes the current SSL configuration\[char46] +.TP +[\fB\-\-bootstrap\fR] \fBset\-ssl\fR \fIprivate-key\fR \fIcertificate\fR \fIca-cert\fR [\fIssl-protocol-list\fR [\fIssl-cipher-list\fR]] +Sets the SSL configuration\[char46] +.SS "Database Commands" +.PP +.PP +These commands query and modify the contents of \fBovsdb\fR tables\[char46] They are a slight abstraction of the \fBovsdb\fR interface and as such they operate at a lower level than other \fBovn\-nbctl\fR commands\[char46] +.PP +\fIIdentifying Tables, Records, and Columns\fR +.PP +.PP +Each of these commands has a \fItable\fR parameter to identify a table within the database\[char46] Many of them also take a \fIrecord\fR parameter that identifies a particular record within a table\[char46] The \fIrecord\fR 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\[char46] Many tables offer additional ways to identify records\[char46] Some commands also take \fIcolumn\fR parameters that identify a particular field within the records in a table\[char46] +.PP +.PP +For a list of tables and their columns, see \fBovn\-nb\fR(5) or see the table listing from the \fB\-\-help\fR option\[char46] +.PP +.PP +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\[char46] Names of tables and columns are not case-sensitive, and \fB\-\fR and \fB_\fR are treated interchangeably\[char46] Unique abbreviations of table and column names are acceptable, e\[char46]g\[char46] \fBd\fR or \fBdhcp\fR is sufficient to identify the \fBDHCP_Options\fR table\[char46] +.PP +.PP +.PP +\fIDatabase Values\fR +.PP +.PP +Each column in the database accepts a fixed type of data\[char46] The currently defined basic types, and their representations, are: +.RS +.TP +integer +A decimal integer in the range \-2**63 to 2**63\-1, inclusive\[char46] +.TP +real +A floating-point number\[char46] +.TP +Boolean +True or false, written \fBtrue\fR or \fBfalse\fR, respectively\[char46] +.TP +string +An arbitrary Unicode string, except that null bytes are not allowed\[char46] Quotes are optional for most strings that begin with an English letter or underscore and consist only of letters, underscores, hyphens, and periods\[char46] However, \fBtrue\fR and \fBfalse\fR and strings that match the syntax of UUIDs (see below) must be enclosed in double quotes to distinguish them from other basic types\[char46] When double quotes are used, the syntax is that of strings in JSON, e\[char46]g\[char46] backslashes may be used to escape special characters\[char46] The empty string must be represented as a pair of double quotes (\fB\(dq\(dq\fR)\[char46] +.TP +UUID +Either a universally unique identifier in the style of RFC 4122, e\[char46]g\[char46] \fBf81d4fae\-7dec\-11d0\-a765\-00a0c91e6bf6\fR, or an \fB@\fR\fIname\fR defined by a \fBget\fR or \fBcreate\fR command within the same \fBovs\-vsctl\fR invocation\[char46] +.RE +.PP +.PP +Multiple values in a single column may be separated by spaces or a single comma\[char46] When multiple values are present, duplicates are not allowed, and order is not important\[char46] Conversely, some database columns can have an empty set of values, represented as \fB[]\fR, and square brackets may optionally enclose other non-empty sets or single values as well\[char46] +.PP +.PP +A few database columns are ``maps\(cq\(cq of key-value pairs, where the key and the value are each some fixed database type\[char46] These are specified in the form \fIkey\fR\fB=\fR\fIvalue\fR, where \fIkey\fR and \fIvalue\fR follow the syntax for the column\(cqs key type and value type, respectively\[char46] When multiple pairs are present (separated by spaces or a comma), duplicate keys are not allowed, and again the order is not important\[char46] Duplicate values are allowed\[char46] An empty map is represented as \fB{}\fR\[char46] Curly braces may optionally enclose non-empty maps as well (but use quotes to prevent the shell from expanding \fBother\-config={0=x,1=y}\fR into \fBother\-config=0=x +other\-config=1=y\fR, which may not have the desired effect)\[char46] +.PP +\fIDatabase Command Syntax\fR +.RS +.TP +[\fB\-\-if\-exists\fR] [\fB\-\-columns=\fR\fIcolumn\fR[\fB,\fR\fIcolumn\fR]\[char46]\[char46]\[char46]] \fBlist\fR \fItable\fR [\fIrecord\fR]\[char46]\[char46]\[char46] +Lists the data in each specified \fIrecord\fR\[char46] If no records are specified, lists all the records in \fItable\fR\[char46] +.IP +If \fB\-\-columns\fR is specified, only the requested columns are listed, in the specified order\[char46] Otherwise, all columns are listed, in alphabetical order by column name\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if any specified \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, the command ignores any \fIrecord\fR that does not exist, without producing any output\[char46] +.TP +[\fB\-\-columns=\fR\fIcolumn\fR[\fB,\fR\fIcolumn\fR]\[char46]\[char46]\[char46]] \fBfind\fR \fItable\fR [\fIcolumn\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR]\[char46]\[char46]\[char46] +Lists the data in each record in \fItable\fR whose \fIcolumn\fR equals \fIvalue\fR or, if \fIkey\fR is specified, whose \fIcolumn\fR contains a \fIkey\fR with the specified \fIvalue\fR\[char46] The following operators may be used where \fB=\fR is written in the syntax summary: +.RS +.TP +\fB= != < > <= >=\fR +Selects records in which \fIcolumn\fR[\fB:\fR\fIkey\fR] equals, does not equal, is less than, is greater than, is less than or equal to, or is greater than or equal to \fIvalue\fR, respectively\[char46] +.IP +Consider \fIcolumn\fR[\fB:\fR\fIkey\fR] and \fIvalue\fR as sets of elements\[char46] Identical sets are considered equal\[char46] Otherwise, if the sets have different numbers of elements, then the set with more elements is considered to be larger\[char46] Otherwise, consider a element from each set pairwise, in increasing order within each set\[char46] The first pair that differs determines the result\[char46] (For a column that contains key-value pairs, first all the keys are compared, and values are considered only if the two sets contain identical keys\[char46]) +.TP +\fB{=} {!=}\fR +Test for set equality or inequality, respectively\[char46] +.TP +\fB{<=}\fR +Selects records in which \fIcolumn\fR[\fB:\fR\fIkey\fR] is a subset of \fIvalue\fR\[char46] For example, \fBflood\-vlans{<=}1,2\fR selects records in which the \fBflood\-vlans\fR column is the empty set or contains 1 or 2 or both\[char46] +.TP +\fB{<}\fR +Selects records in which \fIcolumn\fR[\fB:\fR\fIkey\fR] is a proper subset of \fIvalue\fR\[char46] For example, \fBflood\-vlans{<}1,2\fR selects records in which the \fBflood\-vlans\fR column is the empty set or contains 1 or 2 but not both\[char46] +.TP +\fB{>=} {>}\fR +Same as \fB{<=}\fR and \fB{<}\fR, respectively, except that the relationship is reversed\[char46] For example, \fBflood\-vlans{>=}1,2\fR selects records in which the \fBflood\-vlans\fR column contains both 1 and 2\[char46] +.RE +.IP +The following operators are available only in Open vSwitch 2\[char46]16 and later: +.RS +.TP +\fB{in}\fR +Selects records in which every element in \fIcolumn\fR[\fB:\fR\fIkey\fR] is also in \fIvalue\fR\[char46] (This is the same as \fB{<=}\fR\[char46]) +.TP +\fB{not\-in}\fR +Selects records in which every element in \fIcolumn\fR[\fB:\fR\fIkey\fR] is not in \fIvalue\fR\[char46] +.RE +.IP +For arithmetic operators (\fB= != < > <= >=\fR), when \fIkey\fR is specified but a particular record\(cqs \fIcolumn\fR does not contain \fIkey\fR, the record is always omitted from the results\[char46] Thus, the condition \fBother\-config:mtu!=1500\fR matches records that have a \fBmtu\fR key whose value is not 1500, but not those that lack an \fBmtu\fR key\[char46] +.IP +For the set operators, when \fIkey\fR is specified but a particular record\(cqs \fIcolumn\fR does not contain \fIkey\fR, the comparison is done against an empty set\[char46] Thus, the condition \fBother\-config:mtu{!=}1500\fR matches records that have a \fBmtu\fR key whose value is not 1500 and those that lack an \fBmtu\fR key\[char46] +.IP +Don\(cqt forget to escape \fB<\fR or \fB>\fR from interpretation by the shell\[char46] +.IP +If \fB\-\-columns\fR is specified, only the requested columns are listed, in the specified order\[char46] Otherwise all columns are listed, in alphabetical order by column name\[char46] +.IP +The UUIDs shown for rows created in the same \fBovs\-vsctl\fR invocation will be wrong\[char46] +.TP +[\fB\-\-if\-exists\fR] [\fB\-\-id=@\fR\fIname\fR] \fBget\fR \fItable record\fR [\fIcolumn\fR[\fB:\fR\fIkey\fR]]\[char46]\[char46]\[char46] +Prints the value of each specified \fIcolumn\fR in the given \fIrecord\fR in \fItable\fR\[char46] For map columns, a \fIkey\fR may optionally be specified, in which case the value associated with \fIkey\fR in the column is printed, instead of the entire map\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist or \fIkey\fR is specified, if \fIkey\fR does not exist in \fIrecord\fR\[char46] With \fB\-\-if\-exists\fR, a missing \fIrecord\fR yields no output and a missing \fIkey\fR prints a blank line\[char46] +.IP +If \fB@\fR\fIname\fR is specified, then the UUID for \fIrecord\fR may be referred to by that name later in the same \fBovs\-vsctl\fR invocation in contexts where a UUID is expected\[char46] +.IP +Both \fB\-\-id\fR and the \fIcolumn\fR arguments are optional, but usually at least one or the other should be specified\[char46] If both are omitted, then \fBget\fR has no effect except to verify that \fIrecord\fR exists in \fItable\fR\[char46] +.IP +\fB\-\-id\fR and \fB\-\-if\-exists\fR cannot be used together\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBset\fR \fItable record column\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR\[char46]\[char46]\[char46] +Sets the value of each specified \fIcolumn\fR in the given \fIrecord\fR in \fItable\fR to \fIvalue\fR\[char46] For map columns, a \fIkey\fR may optionally be specified, in which case the value associated with \fIkey\fR in that column is changed (or added, if none exists), instead of the entire map\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, this command does nothing if \fIrecord\fR does not exist\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBadd\fR \fItable record column\fR [\fIkey\fR\fB=\fR]\fIvalue\fR\[char46]\[char46]\[char46] +Adds the specified value or key-value pair to \fIcolumn\fR in \fIrecord\fR in \fItable\fR\[char46] If \fIcolumn\fR is a map, then \fIkey\fR is required, otherwise it is prohibited\[char46] If \fIkey\fR already exists in a map column, then the current \fIvalue\fR is not replaced (use the \fBset\fR command to replace an existing value)\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, this command does nothing if \fIrecord\fR does not exist\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBremove\fR \fItable record column value\fR\[char46]\[char46]\[char46] +.IP +[\fB\-\-if\-exists\fR] \fBremove\fR \fItable record column key\fR\[char46]\[char46]\[char46] +.IP +[\fB\-\-if\-exists\fR] \fBremove\fR \fItable record column key\fR\fB=\fR\fIvalue\fR\[char46]\[char46]\[char46] +Removes the specified values or key-value pairs from \fIcolumn\fR in \fIrecord\fR in \fItable\fR\[char46] The first form applies to columns that are not maps: each specified \fIvalue\fR is removed from the column\[char46] The second and third forms apply to map columns: if only a \fIkey\fR is specified, then any key-value pair with the given \fIkey\fR is removed, regardless of its value; if a \fIvalue\fR is given then a pair is removed only if both key and value match\[char46] +.IP +It is not an error if the column does not contain the specified key or value or pair\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, this command does nothing if \fIrecord\fR does not exist\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBclear\fR \fItable record column\fR\[char46]\[char46]\[char46] +Sets each \fIcolumn\fR in \fIrecord\fR in \fItable\fR to the empty set or empty map, as appropriate\[char46] This command applies only to columns that are allowed to be empty\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, this command does nothing if \fIrecord\fR does not exist\[char46] +.TP +[\fB\-\-id=(@\fR\fIname\fR|\fIuuid\fR)] \fBcreate\fR \fItable column\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR\[char46]\[char46]\[char46] +Creates a new record in \fItable\fR and sets the initial values of each \fIcolumn\fR\[char46] Columns not explicitly set will receive their default values\[char46] Outputs the UUID of the new row\[char46] +.IP +If \fB@\fR\fIname\fR is specified, then the UUID for the new row may be referred to by that name elsewhere in the same \fB\e*(PN\fR invocation in contexts where a UUID is expected\[char46] Such references may precede or follow the \fBcreate\fR command\[char46] +.IP +If a valid \fIuuid\fR is specified, then it is used as the UUID of the new row\[char46] +.RS +.TP +Caution (ovs-vsctl as example) +Records in the Open vSwitch database are significant only when they can be reached directly or indirectly from the \fBOpen_vSwitch\fR table\[char46] Except for records in the \fBQoS\fR or \fBQueue\fR tables, records that are not reachable from the \fBOpen_vSwitch\fR table are automatically deleted from the database\[char46] This deletion happens immediately, without waiting for additional \fBovs\-vsctl\fR commands or other database activity\[char46] Thus, a \fBcreate\fR command must generally be accompanied by additional commands \fIwithin the same\fR \fBovs\-vsctl\fR \fIinvocation\fR to add a chain of references to the newly created record from the top-level \fBOpen_vSwitch\fR record\[char46] The \fBEXAMPLES\fR section gives some examples that show how to do this\[char46] +.RE +.TP +[\fB\-\-if\-exists\fR] \fBdestroy\fR \fItable record\fR\[char46]\[char46]\[char46] +Deletes each specified \fIrecord\fR from \fItable\fR\[char46] Unless \fB\-\-if\-exists\fR is specified, each \fIrecord\fRs must exist\[char46] +.TP +\fB\-\-all destroy\fR \fItable\fR +Deletes all records from the \fItable\fR\[char46] +.RS +.TP +Caution (ovs-vsctl as example) +The \fBdestroy\fR command is only useful for records in the \fBQoS\fR or \fBQueue\fR tables\[char46] Records in other tables are automatically deleted from the database when they become unreachable from the \fBOpen_vSwitch\fR table\[char46] This means that deleting the last reference to a record is sufficient for deleting the record itself\[char46] For records in these tables, \fBdestroy\fR is silently ignored\[char46] See the \fBEXAMPLES\fR section below for more information\[char46] +.RE +.TP +\fBwait\-until\fR \fItable record\fR [\fIcolumn\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR]\[char46]\[char46]\[char46] +Waits until \fItable\fR contains a record named \fIrecord\fR whose \fIcolumn\fR equals \fIvalue\fR or, if \fIkey\fR is specified, whose \fIcolumn\fR contains a \fIkey\fR with the specified \fIvalue\fR\[char46] This command supports the same operators and semantics described for the \fBfind\fR command above\[char46] +.IP +If no \fIcolumn\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR arguments are given, this command waits only until \fIrecord\fR exists\[char46] If more than one such argument is given, the command waits until all of them are satisfied\[char46] +.RS +.TP +Caution (ovs-vsctl as example) +Usually \fBwait\-until\fR should be placed at the beginning of a set of \fBovs\-vsctl\fR commands\[char46] For example, \fBwait\-until bridge br0 +\-\- get bridge br0 datapath_id\fR waits until a bridge named \fBbr0\fR is created, then prints its \fBdatapath_id\fR column, whereas \fBget bridge br0 datapath_id \-\- wait\-until bridge br0\fR will abort if no bridge named \fBbr0\fR exists when \fBovs\-vsctl\fR initially connects to the database\[char46] +.RE +.IP +Consider specifying \fB\-\-timeout=0\fR along with \fB\-\-wait\-until\fR, to prevent \fBovs\-vsctl\fR from terminating after waiting only at most 5 seconds\[char46] +.TP +\fBcomment\fR [\fIarg\fR]\[char46]\[char46]\[char46] +This command has no effect on behavior, but any database log record created by the command will include the command and its arguments\[char46] +.RE +.SH "ENVIRONMENT" +.TP +\fBOVN_NB_DAEMON\fR +If set, this should name the Unix domain socket for an \fBovn\-nbctl\fR server process\[char46] See \fBDaemon Mode\fR, above, for more information\[char46] +.TP +\fBOVN_NBCTL_OPTIONS\fR +If set, a set of options for \fBovn\-nbctl\fR to apply automatically, in the same form as on the command line\[char46] +.TP +\fBOVN_NB_DB\fR +If set, the default database to contact when the \fB\-\-db\fR option is not used\[char46] +.SH "EXIT STATUS" +.TP +0 +Successful program execution\[char46] +.TP +1 +Usage, syntax, or network error\[char46] +.SH "SEE ALSO" +\fBovn\-nb\fR(5), \fBovn\-appctl\fR(8)\[char46] diff --git a/src/static/support/dist-docs-branch-23.06/ovn-nbctl.8.html b/src/static/support/dist-docs-branch-23.06/ovn-nbctl.8.html new file mode 100644 index 00000000..e730675b --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-nbctl.8.html @@ -0,0 +1,1718 @@ +
+ovn-nbctl(8)                      OVN Manual                      ovn-nbctl(8)
+
+NAME
+       ovn-nbctl - Open Virtual Network northbound db management utility
+
+SYNOPSIS
+       ovn-nbctl [options] command [arg...]
+
+DESCRIPTION
+       The ovn-nbctl program configures the OVN_Northbound database by providā€
+       ing a high-level interface to its configuration database. See ovn-nb(5)
+       for comprehensive documentation of the database schema.
+
+       ovn-nbctl  connects  to  an  ovsdb-server  process  that  maintains  an
+       OVN_Northbound  configuration  database.  Using  this  connection,   it
+       queries  and possibly applies changes to the database, depending on the
+       supplied commands.
+
+       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 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ā€
+       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
+       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.
+
+       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 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
+       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
+       uses the daemon to execute its commands.
+
+       When the daemon is no longer needed, kill it and unset the  environment
+       variable, e.g.:
+
+             kill $(cat $OVN_RUNDIR/ovn-nbctl.pid)
+             unset OVN_NB_DAEMON
+
+
+       When using daemon mode, an alternative to the OVN_NB_DAEMON environment
+       variable  is  to  specify a path for the Unix socket. When starting the
+       ovn-nbctl daemon, specify the -u option with a full path to  the  locaā€
+       tion of the socket file. Here is an exmple:
+
+             ovn-nbctl --detach -u /tmp/mysock.ctl
+
+
+       Then  to connect to the running daemon, use the -u option with the full
+       path to the socket created when the daemon was started:
+
+             ovn-nbctl -u /tmp/mysock.ctl show
+
+
+     Daemon Commands
+
+       Daemon mode is internally implemented using the same mechanism used  by
+       ovn-appctl.  One  may  also  use ovn-appctl directly with the following
+       commands:
+
+              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  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.
+       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 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
+       command line override those in the environment.
+
+              --no-wait | --wait=none
+              --wait=sb
+              --wait=hv
+                   These options control whether and how ovn-nbctl  waits  for
+                   the OVN system to become up-to-date with changes made in an
+                   ovn-nbctl invocation.
+
+                   By default, or if --no-wait or --wait=none, ovn-nbctl exits
+                   immediately after confirming that changes have been commitā€
+                   ted to the northbound database, without waiting.
+
+                   With  --wait=sb,  before  ovn-nbctl  exits,  it  waits  for
+                   ovn-northd to bring the southbound database up-to-date with
+                   the northbound database updates.
+
+                   With --wait=hv, before  ovn-nbctl  exits,  it  additionally
+                   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
+                   means that, if none of the commands supplied  to  ovn-nbctl
+                   change the database, then the command does not wait at all.
+                   Use the sync command to override this behavior.
+
+              --db database
+                   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
+                   By default, or with --leader-only, when the database server
+                   is a clustered database, ovn-nbctl will avoid servers other
+                   than the cluster leader. This ensures that  any  data  that
+                   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
+                   database are always serialized even with --no-leader-only).
+                   Refer to Understanding Cluster Consistency in ovsdb(7)  for
+                   more information.
+
+              --shuffle-remotes
+              --no-shuffle-remotes
+                   By  default, or with --shuffle-remotes, when there are mulā€
+                   tiple remotes specified  in  the  OVSDB  connection  string
+                   specified  by  --db  or the OVN_NB_DB environment variable,
+                   the order of the remotes will be shuffled before the client
+                   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,
+                   which is particularly useful for testing.
+
+              --no-syslog
+                   By default, ovn-nbctl logs its arguments and the details of
+                   any changes that it makes to the system  log.  This  option
+                   disables this logging.
+
+                   This option is equivalent to --verbose=nbctl:syslog:warn.
+
+              --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
+                   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.
+
+              --dry-run
+                   Prevents ovn-nbctl from actually modifying the database.
+
+              -t secs
+              --timeout=secs
+                   By default, or with a secs of 0,  ovn-nbctl  waits  forever
+                   for  a  response from the database. This option limits runā€
+                   time to approximately secs seconds. If the timeout expires,
+                   ovn-nbctl will exit with a SIGALRM signal. (A timeout would
+                   normally happen only if the database cannot  be  contacted,
+                   or if the system is overloaded.)
+
+              --print-wait-time
+                   When  --wait is specified, the option --print-wait-time can
+                   be used to print the time spent on  waiting,  depending  on
+                   the  value  specified  in   --wait  option. If --wait=sb is
+                   specified, it prints "ovn-northd delay before  processing",
+                   which  is  the time between the Northbound DB update by the
+                   command and the moment when  ovn-northd  starts  processing
+                   the  update, and "ovn-northd completion", which is the time
+                   between the  Northbound  DB  update  and  the  moment  when
+                   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
+                   update.
+
+   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
+              specified, or if it does not begin with /, then it is created in
+              .
+
+              If --pidfile is not specified, no pidfile is created.
+
+       --overwrite-pidfile
+              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.
+
+              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
+              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
+              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ā€ā€
+              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ā€
+              tions without it.
+
+       --no-chdir
+              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.
+
+              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-
+              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.
+
+       --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
+              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
+              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
+              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
+            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
+                   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,  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
+                   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
+                   definition of each log level.
+
+            Case is not significant within spec.
+
+            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
+            word but has no effect.
+
+       -v
+       --verbose
+            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-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,
+            local4, local5, local6 or local7. If this option is not specified,
+            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
+            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.
+
+       --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ā€
+            name.
+
+       --syslog-method=method
+            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
+                   /dev/log UNIX domain socket.
+
+            ā€¢      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 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ā€
+       mands.
+
+              -f format
+              --format=format
+                   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
+                          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
+                          members with the noted values:
+
+                          caption
+                                 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
+                                 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-
+                                 level array are the cells that constitute the
+                                 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
+                   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:
+
+                   string (default)
+                          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
+                          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  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
+                   arrays are printed one per line, with indentation.
+
+                   This option does not affect JSON in tables, which is always
+                   printed compactly.
+
+              --bare
+                   Equivalent to --format=list --data=bare --no-headings.
+
+   PKI Options
+       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
+                   identity for outgoing SSL connections.
+
+              -c cert.pem
+              --certificate=cert.pem
+                   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
+                   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
+                   verify the certificate specified on -c or --certificate, or
+                   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
+                   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ā€
+                     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.
+
+                     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
+                     certificate as part of the SSL certificate chain. The SSL
+                     protocol  does not require the server to send the CA cerā€
+                     tificate.
+
+                     This option is mutually exclusive with -C and --ca-cert.
+
+   Other Options
+       -h
+       --help
+            Prints a brief help message to the console.
+
+       -V
+       --version
+            Prints version information to the console.
+
+COMMANDS
+       The following sections describe the commands that ovn-nbctl supports.
+
+   General Commands
+       init   Initializes the database, if it is empty. If  the  database  has
+              already been initialized, this command has no effect.
+
+       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
+              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  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
+              no ports.
+
+              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
+              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
+              --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
+       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 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, 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.
+
+                     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
+                     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]]
+              Adds QoS marking and metering rules to switch. direction must be
+              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  --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
+              deleted from the logical switch. If all the fields are supplied,
+              then a single  flow  that  matches  the  given  fields  will  be
+              deleted.
+
+              If  switch  and uuid are supplied, then the QoS rule with speciā€
+              fied uuid is deleted.
+
+       qos-list switch
+              Lists the QoS rules on switch.
+
+   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
+              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ā€
+              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
+              not supplied, the switch is free to select some reasonable value
+              depending on its configuration.
+
+              ovn-nbctl only supports adding a meter with a single  band,  but
+              the other commands support meters with multiple bands.
+
+              Names  that  start  with "__" (two underscores) are reserved for
+              internal use by OVN, so ovn-nbctl does not allow adding them.
+
+       meter-del [name]
+              Deletes meters. By default, all meters are deleted. If  name  is
+              supplied, only the meter with that name will be deleted.
+
+       meter-list
+              Lists all meters.
+
+   Logical Switch Port 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, 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
+              Creates on switch a logical switch port named  port  that  is  a
+              child  of  parent  that  is identified with VLAN ID tag_request,
+              which must be between 0 and 4095, inclusive. If  tag_request  is
+              0,  ovn-northd  generates  a  tag that is unique in the scope of
+              parent. This is useful in cases such  as  virtualized  container
+              environments  where  Open vSwitch does not have a direct connecā€
+              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,  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
+              --if-exists is specified.
+
+       lsp-list switch
+              Lists  all  the  logical  switch ports within switch on standard
+              output, one per line.
+
+       lsp-get-parent port
+              If set, get the parent port of port. If not set, print nothing.
+
+       lsp-get-tag port
+              If set, get the tag for port traffic. If not set, print nothing.
+
+       lsp-set-addresses port [address]...
+              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
+              more IP addresses
+                     OVN delivers packets for the  Ethernet  address  to  this
+                     port.
+
+              unknown
+                     OVN  delivers  unicast Ethernet packets whose destination
+                     MAC address is not in any logical portā€™s addresses column
+                     to ports with address unknown.
+
+              dynamic
+                     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
+                     addresses for this logical switch port should be obtained
+                     from  the  connected logical router port, as specified by
+                     router-port in lsp-set-options.
+
+              Multiple addresses may be set. If no address argument is  given,
+              port will have no addresses associated with it.
+
+       lsp-get-addresses port
+              Lists all the addresses associated with port on standard output,
+              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
+              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ā€ā€
+              ical_Switch_Port table for details.
+
+       lsp-get-port-security port
+              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
+              out of the port.
+
+       lsp-get-enabled port
+              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
+              following:
+
+              (empty string)
+                     A VM (or VIF) interface.
+
+              router A connection to a logical router.
+
+              localnet
+                     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 diā€
+                     rect connectivity to an existing network.
+
+              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
+                     hypervisor.
+
+              l2gateway
+                     A connection to a physical network.
+
+              vtep   A port to a logical switch on a VTEP gateway.
+
+       lsp-get-type port
+              Get the type for the logical port.
+
+       lsp-set-options port [key=value]...
+              Set type-specific key-value options for the logical port.
+
+       lsp-get-options port
+              Get the type-specific options for the logical port.
+
+       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
+              table.
+
+       lsp-get-dhcpv4-options port
+              Get the configured DHCPv4 options for the logical port.
+
+       lsp-set-dhcpv6-options port dhcp_options
+              Set the DHCPv6 options for the logical port. The dhcp_options is
+              a UUID referring to a set of DHCP options  in  the  DHCP_Options
+              table.
+
+       lsp-get-dhcpv6-options port
+              Get the configured DHCPv6 options for the logical port.
+
+       lsp-get-ls port
+              Get the logical switch which the port belongs to.
+
+       lsp-attach-mirror port m
+              Attaches the mirror m to the logical port port.
+
+       lsp-detach-mirror port m
+              Detaches the mirror m from the logical port port.
+
+   Forwarding Group Commands
+       [--liveness]fwd-group-add group switch vip vmac ports
+              Creates  a new forwarding group named group as the name with the
+              provided vip and vmac. vip should be a virtual  IP  address  and
+              vmac  should  be  a virtual MAC address to access the forwarding
+              group. ports are the logical switch port names that are  put  in
+              the forwarding group. Example for ports is lsp1 lsp2 ... Traffic
+              destined to virtual IP of the forwarding group will be load balā€
+              anced to all the child ports.
+
+              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 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
+              --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
+              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  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
+              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
+              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 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
+              --if-exists is specified.
+
+       lr-list
+              Lists all existing routers on standard output, one per line.
+
+   Logical Router Port Commands
+       [--may-exist] lrp-add router port mac network... [peer=peer]
+              Creates on router a new logical router port named port with Ethā€
+              ernet  address  mac  and one or more IP address/netmask for each
+              network.
+
+              The optional argument peer identifies a logical router port that
+              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 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
+              --if-exists is specified.
+
+       lrp-list router
+              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
+              out of the port.
+
+       lrp-get-enabled port
+              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ā€
+              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
+              by user. priority must be between 0 and 32767, inclusive.
+
+       lrp-del-gateway-chassis port chassis
+              Deletes  gateway  chassis  from  port. It is an error if gateway
+              chassis with chassis for port does not exist.
+
+       lrp-get-gateway-chassis port
+              Lists all the gateway chassis with priority within port on stanā€
+              dard output, one per line, ordered based on priority.
+
+   Logical Router Static Route Commands
+       [--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  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.
+
+              --policy  describes  the  policy used to make routing decisions.
+              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ā€
+              fix POLICY but different nexthop and port to be added.
+
+              The --ecmp-symmetric-reply option makes it so that traffic  that
+              arrives  over an ECMP route will have its reply traffic sent out
+              over that same  route.  Setting  --ecmp-symmetric-reply  implies
+              --ecmp so it is not necessary to set both.
+
+              --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
+              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ā€ā€
+              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
+       [port]]]
+              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.
+
+              It  is  an  error  if  there  is no matching route entry, unless
+              --if-exists is specified.
+
+       lr-route-list router
+              Lists the routes on router.
+
+   Logical Router Policy Commands
+       [--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.
+              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
+              in error.
+
+              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
+              pkt_mark=100 .
+
+       [--if-exists] lr-policy-del router [{priority | uuid} [match]]
+              Deletes polices from router. If only router is supplied, all the
+              polices from the logical router are deleted. If priority  and/or
+              match  are  also  specified, then all the polices that match the
+              conditions will be deleted from the logical router.
+
+              If router and uuid are supplied, then the policy with  specified
+              uuid  is  deleted. It is an error if uuid does not exist, unless
+              --if-exists is specified.
+
+       lr-policy-list router
+              Lists the polices on router.
+
+   NAT Commands
+       [--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
+              of an existing logical switch port where the logical_ip resides.
+              The external_mac is an Ethernet address.
+
+              When --stateless is specified then it implies that  we  will  be
+              not  use connection tracker, i.e internal ip and external ip are
+              1:1 mapped. This implies that --stateless is applicable only  to
+              dnat_and_snat  type  NAT  rules. An external ip with --stateless
+              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ā€
+              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
+              canā€™t  be  inferred  from the external_ip, it is an error to not
+              specify the GATEWAY_PORT.
+
+              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
+              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ā€
+              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
+              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ā€
+              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
+              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
+              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
+              external_ip.
+
+              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
+       [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
+              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
+              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
+              named lb, unless --may-exist is specified. With --add-duplicate,
+              the  command really creates a new load balancer with a duplicate
+              name.
+
+              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.
+
+              If  the  load balancer is created with --event option and it has
+              no active backends, whenever the lb receives traffic, the  event
+              is  reported  in the Controller_Event table in the SB db. Please
+              note --event option canā€™t be specified with --reject one.
+
+              The following example adds a load balancer.
+
+              lb-add                     lb0                      30.0.0.10:80
+              192.168.10.10:80,192.168.10.20:80,192.168.10.30:80 udp
+
+       [--if-exists] lb-del lb [vip]
+              Deletes  lb or the vip from lb. If vip is supplied, only the vip
+              will be deleted from the lb. If only the lb is supplied, the  lb
+              will be deleted. It is an error if vip does not already exist in
+              lb, unless --if-exists is specified.
+
+       lb-list [lb]
+              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
+              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
+              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
+              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
+              is specified.
+
+       lr-lb-list router
+              Lists the LBs for the given router.
+
+   DHCP Options commands
+       dhcp-options-create cidr [key=value]
+              Creates a new DHCP Options entry in the DHCP_Options table  with
+              the specified cidr and optional external-ids.
+
+       dhcp-options-list
+              Lists the DHCP Options entries.
+
+       dhcp-options-del dhcp-option
+              Deletes the DHCP Options entry referred by dhcp-option UUID.
+
+       dhcp-options-set-options dhcp-option [key=value]...
+              Set the DHCP Options for the dhcp-option UUID.
+
+       dhcp-options-get-options dhcp-option
+              Lists the DHCP Options for the dhcp-option UUID.
+
+   Port Group commands
+       pg-add group [port]...
+              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
+              group does not exist.
+
+       pg-del group
+              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
+              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-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
+              priority is updated. The chassis should be the name of the chasā€
+              sis in the OVN_Southbound.
+
+       ha-chassis-group-remove-chassis group chassis
+              Removes  the HA chassis chassis from the HA chassis group group.
+              It is an error if chassis does not exist.
+
+   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ā€ā€
+       cal_Router tables. Protocol packets for which  CoPP  is  enforced  when
+       sending packets to ovn-controller (if configured):
+
+              ā€¢      ARP
+
+              ā€¢      ND_NS
+
+              ā€¢      ND_NA
+
+              ā€¢      ND_RA
+
+              ā€¢      ND
+
+              ā€¢      DNS
+
+              ā€¢      IGMP
+
+              ā€¢      packets that require ARP resolution 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 TCP RST
+
+              ā€¢      packets that need to be replied to with DHCP_OPTS
+
+              ā€¢      packets that trigger a reject action
+
+              ā€¢      packets that trigger a SCTP abort action
+
+              ā€¢      controller_events
+
+              ā€¢      BFD
+
+              copp-add name proto meter
+                     Adds  the  control  proto to meter mapping to the control
+                     plane protection policy name. If no policy exists yet, it
+                     creates one. If a mapping already existed for proto, this
+                     will overwrite it.
+
+              copp-del name [proto]
+                     Removes the control proto mapping for  the  name  control
+                     plane  protection  policy. If proto is not specified, the
+                     whole control plane protection policy is destroyed.
+
+              copp-list name
+                     Display the current control plane protection  policy  for
+                     name.
+
+              ls-copp-add name switch
+                     Adds the control plane protection policy name to the logā€
+                     ical switch switch.
+
+              lr-copp-add name router
+                     Adds the control plane protection policy name to the logā€
+                     ical router router.
+
+   Mirror commands
+       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 , erspan or local.
+
+              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,
+              to-lport or both.
+
+              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.
+
+       mirror-list
+              Lists the mirrors.
+
+   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
+              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 adā€
+       ministrator to use ovn-nbctl to configure database connections.
+
+              get-connection
+                     Prints the configured connection(s).
+
+              del-connection
+                     Deletes the configured connection(s).
+
+              [--inactivity-probe=msecs] set-connection target...
+                     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
+              Prints the SSL configuration.
+
+       del-ssl
+              Deletes the current SSL configuration.
+
+       [--bootstrap] set-ssl private-key certificate ca-cert [ssl-protocol-
+       list [ssl-cipher-list]]
+              Sets the SSL configuration.
+
+   Database Commands
+       These commands query and modify the contents of ovsdb tables. They  are
+       a slight abstraction of the ovsdb interface and as such they operate at
+       a lower level than other ovn-nbctl commands.
+
+       Identifying Tables, Records, and Columns
+
+       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
+       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
+       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,
+       e.g. d or dhcp is sufficient to identify the DHCP_Options table.
+
+       Database Values
+
+       Each column in the database accepts a fixed type of data. The currently
+       defined basic types, and their representations, are:
+
+              integer
+                     A  decimal integer in the range -2**63 to 2**63-1, incluā€
+                     sive.
+
+              real   A floating-point number.
+
+              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ā€
+                     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
+                     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
+                     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  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 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
+              [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
+                     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 igā€
+                     nores any record that does not exist,  without  producing
+                     any output.
+
+              [--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ā€
+                     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
+                            value, respectively.
+
+                            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
+                            pairs, first all the keys are compared, and values
+                            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
+                            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 the flood-vlans column is
+                            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
+                            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
+                            {=}.)
+
+                     {not-in}
+                            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
+                     not those that lack an mtu key.
+
+                     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
+                     key.
+
+                     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
+                     invocation will be wrong.
+
+              [--if-exists] [--id=@name] get table record [column[:key]]...
+                     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
+                     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  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
+                     both are omitted, then get has no effect except to verify
+                     that record exists in table.
+
+                     --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 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
+                     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 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
+                     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ā€
+                     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
+                     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.
+
+                     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
+                     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
+                     record does not exist.
+
+              [--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
+                     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
+                     references may precede or follow the create command.
+
+                     If a valid uuid is specified, then it is used as the UUID
+                     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 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
+                            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
+                            some examples that show how to do this.
+
+              [--if-exists] destroy table record...
+                     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
+                            for more information.
+
+              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
+                     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
+                     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ā€ā€
+                            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
+                            ovs-vsctl initially connects to the database.
+
+                     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ā€
+                     mand and its arguments.
+
+ENVIRONMENT
+       OVN_NB_DAEMON
+              If set, this should name the Unix domain socket for an ovn-nbctl
+              server process. See Daemon Mode, above, for more information.
+
+       OVN_NBCTL_OPTIONS
+              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
+              not used.
+
+EXIT STATUS
+       0      Successful program execution.
+
+       1      Usage, syntax, or network error.
+
+SEE ALSO
+       ovn-nb(5), ovn-appctl(8).
+
+OVN 23.06.3                        ovn-nbctl                      ovn-nbctl(8)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-nbctl.8.pdf b/src/static/support/dist-docs-branch-23.06/ovn-nbctl.8.pdf new file mode 100644 index 00000000..e8038b20 Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-nbctl.8.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-nbctl.8.txt b/src/static/support/dist-docs-branch-23.06/ovn-nbctl.8.txt new file mode 100644 index 00000000..e8fece03 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-nbctl.8.txt @@ -0,0 +1,1716 @@ +ovn-nbctl(8) OVN Manual ovn-nbctl(8) + +NAME + ovn-nbctl - Open Virtual Network northbound db management utility + +SYNOPSIS + ovn-nbctl [options] command [arg...] + +DESCRIPTION + The ovn-nbctl program configures the OVN_Northbound database by providā€ + ing a high-level interface to its configuration database. See ovn-nb(5) + for comprehensive documentation of the database schema. + + ovn-nbctl connects to an ovsdb-server process that maintains an + OVN_Northbound configuration database. Using this connection, it + queries and possibly applies changes to the database, depending on the + supplied commands. + + 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 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ā€ + 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 + 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. + + 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 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 + 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 + uses the daemon to execute its commands. + + When the daemon is no longer needed, kill it and unset the environment + variable, e.g.: + + kill $(cat $OVN_RUNDIR/ovn-nbctl.pid) + unset OVN_NB_DAEMON + + + When using daemon mode, an alternative to the OVN_NB_DAEMON environment + variable is to specify a path for the Unix socket. When starting the + ovn-nbctl daemon, specify the -u option with a full path to the locaā€ + tion of the socket file. Here is an exmple: + + ovn-nbctl --detach -u /tmp/mysock.ctl + + + Then to connect to the running daemon, use the -u option with the full + path to the socket created when the daemon was started: + + ovn-nbctl -u /tmp/mysock.ctl show + + + Daemon Commands + + Daemon mode is internally implemented using the same mechanism used by + ovn-appctl. One may also use ovn-appctl directly with the following + commands: + + 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 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. + 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 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 + command line override those in the environment. + + --no-wait | --wait=none + --wait=sb + --wait=hv + These options control whether and how ovn-nbctl waits for + the OVN system to become up-to-date with changes made in an + ovn-nbctl invocation. + + By default, or if --no-wait or --wait=none, ovn-nbctl exits + immediately after confirming that changes have been commitā€ + ted to the northbound database, without waiting. + + With --wait=sb, before ovn-nbctl exits, it waits for + ovn-northd to bring the southbound database up-to-date with + the northbound database updates. + + With --wait=hv, before ovn-nbctl exits, it additionally + 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 + means that, if none of the commands supplied to ovn-nbctl + change the database, then the command does not wait at all. + Use the sync command to override this behavior. + + --db database + 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 + By default, or with --leader-only, when the database server + is a clustered database, ovn-nbctl will avoid servers other + than the cluster leader. This ensures that any data that + 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 + database are always serialized even with --no-leader-only). + Refer to Understanding Cluster Consistency in ovsdb(7) for + more information. + + --shuffle-remotes + --no-shuffle-remotes + By default, or with --shuffle-remotes, when there are mulā€ + tiple remotes specified in the OVSDB connection string + specified by --db or the OVN_NB_DB environment variable, + the order of the remotes will be shuffled before the client + 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, + which is particularly useful for testing. + + --no-syslog + By default, ovn-nbctl logs its arguments and the details of + any changes that it makes to the system log. This option + disables this logging. + + This option is equivalent to --verbose=nbctl:syslog:warn. + + --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 + 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. + + --dry-run + Prevents ovn-nbctl from actually modifying the database. + + -t secs + --timeout=secs + By default, or with a secs of 0, ovn-nbctl waits forever + for a response from the database. This option limits runā€ + time to approximately secs seconds. If the timeout expires, + ovn-nbctl will exit with a SIGALRM signal. (A timeout would + normally happen only if the database cannot be contacted, + or if the system is overloaded.) + + --print-wait-time + When --wait is specified, the option --print-wait-time can + be used to print the time spent on waiting, depending on + the value specified in --wait option. If --wait=sb is + specified, it prints "ovn-northd delay before processing", + which is the time between the Northbound DB update by the + command and the moment when ovn-northd starts processing + the update, and "ovn-northd completion", which is the time + between the Northbound DB update and the moment when + 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 + update. + + 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 + specified, or if it does not begin with /, then it is created in + . + + If --pidfile is not specified, no pidfile is created. + + --overwrite-pidfile + 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. + + 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 + 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 + 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ā€ā€ + 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ā€ + tions without it. + + --no-chdir + 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. + + 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- + 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. + + --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 + 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 + 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 + 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 + 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 + 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, 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 + 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 + definition of each log level. + + Case is not significant within spec. + + 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 + word but has no effect. + + -v + --verbose + 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-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, + local4, local5, local6 or local7. If this option is not specified, + 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 + 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. + + --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ā€ + name. + + --syslog-method=method + 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 + /dev/log UNIX domain socket. + + ā€¢ 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 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ā€ + mands. + + -f format + --format=format + 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 + 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 + members with the noted values: + + caption + 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 + 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- + level array are the cells that constitute the + 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 + 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: + + string (default) + 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 + 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 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 + arrays are printed one per line, with indentation. + + This option does not affect JSON in tables, which is always + printed compactly. + + --bare + Equivalent to --format=list --data=bare --no-headings. + + PKI Options + 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 + identity for outgoing SSL connections. + + -c cert.pem + --certificate=cert.pem + 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 + 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 + verify the certificate specified on -c or --certificate, or + 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 + 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ā€ + 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. + + 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 + certificate as part of the SSL certificate chain. The SSL + protocol does not require the server to send the CA cerā€ + tificate. + + This option is mutually exclusive with -C and --ca-cert. + + Other Options + -h + --help + Prints a brief help message to the console. + + -V + --version + Prints version information to the console. + +COMMANDS + The following sections describe the commands that ovn-nbctl supports. + + General Commands + init Initializes the database, if it is empty. If the database has + already been initialized, this command has no effect. + + 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 + 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 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 + no ports. + + 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 + 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 + --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 + 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 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, 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. + + 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 + 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]] + Adds QoS marking and metering rules to switch. direction must be + 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 --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 + deleted from the logical switch. If all the fields are supplied, + then a single flow that matches the given fields will be + deleted. + + If switch and uuid are supplied, then the QoS rule with speciā€ + fied uuid is deleted. + + qos-list switch + Lists the QoS rules on switch. + + 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 + 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ā€ + 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 + not supplied, the switch is free to select some reasonable value + depending on its configuration. + + ovn-nbctl only supports adding a meter with a single band, but + the other commands support meters with multiple bands. + + Names that start with "__" (two underscores) are reserved for + internal use by OVN, so ovn-nbctl does not allow adding them. + + meter-del [name] + Deletes meters. By default, all meters are deleted. If name is + supplied, only the meter with that name will be deleted. + + meter-list + Lists all meters. + + Logical Switch Port 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, 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 + Creates on switch a logical switch port named port that is a + child of parent that is identified with VLAN ID tag_request, + which must be between 0 and 4095, inclusive. If tag_request is + 0, ovn-northd generates a tag that is unique in the scope of + parent. This is useful in cases such as virtualized container + environments where Open vSwitch does not have a direct connecā€ + 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, 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 + --if-exists is specified. + + lsp-list switch + Lists all the logical switch ports within switch on standard + output, one per line. + + lsp-get-parent port + If set, get the parent port of port. If not set, print nothing. + + lsp-get-tag port + If set, get the tag for port traffic. If not set, print nothing. + + lsp-set-addresses port [address]... + 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 + more IP addresses + OVN delivers packets for the Ethernet address to this + port. + + unknown + OVN delivers unicast Ethernet packets whose destination + MAC address is not in any logical portā€™s addresses column + to ports with address unknown. + + dynamic + 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 + addresses for this logical switch port should be obtained + from the connected logical router port, as specified by + router-port in lsp-set-options. + + Multiple addresses may be set. If no address argument is given, + port will have no addresses associated with it. + + lsp-get-addresses port + Lists all the addresses associated with port on standard output, + 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 + 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ā€ā€ + ical_Switch_Port table for details. + + lsp-get-port-security port + 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 + out of the port. + + lsp-get-enabled port + 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 + following: + + (empty string) + A VM (or VIF) interface. + + router A connection to a logical router. + + localnet + 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 diā€ + rect connectivity to an existing network. + + 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 + hypervisor. + + l2gateway + A connection to a physical network. + + vtep A port to a logical switch on a VTEP gateway. + + lsp-get-type port + Get the type for the logical port. + + lsp-set-options port [key=value]... + Set type-specific key-value options for the logical port. + + lsp-get-options port + Get the type-specific options for the logical port. + + 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 + table. + + lsp-get-dhcpv4-options port + Get the configured DHCPv4 options for the logical port. + + lsp-set-dhcpv6-options port dhcp_options + Set the DHCPv6 options for the logical port. The dhcp_options is + a UUID referring to a set of DHCP options in the DHCP_Options + table. + + lsp-get-dhcpv6-options port + Get the configured DHCPv6 options for the logical port. + + lsp-get-ls port + Get the logical switch which the port belongs to. + + lsp-attach-mirror port m + Attaches the mirror m to the logical port port. + + lsp-detach-mirror port m + Detaches the mirror m from the logical port port. + + Forwarding Group Commands + [--liveness]fwd-group-add group switch vip vmac ports + Creates a new forwarding group named group as the name with the + provided vip and vmac. vip should be a virtual IP address and + vmac should be a virtual MAC address to access the forwarding + group. ports are the logical switch port names that are put in + the forwarding group. Example for ports is lsp1 lsp2 ... Traffic + destined to virtual IP of the forwarding group will be load balā€ + anced to all the child ports. + + 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 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 + --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 + 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 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 + 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 + 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 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 + --if-exists is specified. + + lr-list + Lists all existing routers on standard output, one per line. + + Logical Router Port Commands + [--may-exist] lrp-add router port mac network... [peer=peer] + Creates on router a new logical router port named port with Ethā€ + ernet address mac and one or more IP address/netmask for each + network. + + The optional argument peer identifies a logical router port that + 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 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 + --if-exists is specified. + + lrp-list router + 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 + out of the port. + + lrp-get-enabled port + 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ā€ + 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 + by user. priority must be between 0 and 32767, inclusive. + + lrp-del-gateway-chassis port chassis + Deletes gateway chassis from port. It is an error if gateway + chassis with chassis for port does not exist. + + lrp-get-gateway-chassis port + Lists all the gateway chassis with priority within port on stanā€ + dard output, one per line, ordered based on priority. + + Logical Router Static Route Commands + [--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 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. + + --policy describes the policy used to make routing decisions. + 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ā€ + fix POLICY but different nexthop and port to be added. + + The --ecmp-symmetric-reply option makes it so that traffic that + arrives over an ECMP route will have its reply traffic sent out + over that same route. Setting --ecmp-symmetric-reply implies + --ecmp so it is not necessary to set both. + + --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 + 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ā€ā€ + 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 + [port]]] + 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. + + It is an error if there is no matching route entry, unless + --if-exists is specified. + + lr-route-list router + Lists the routes on router. + + Logical Router Policy Commands + [--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. + 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 + in error. + + 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 + pkt_mark=100 . + + [--if-exists] lr-policy-del router [{priority | uuid} [match]] + Deletes polices from router. If only router is supplied, all the + polices from the logical router are deleted. If priority and/or + match are also specified, then all the polices that match the + conditions will be deleted from the logical router. + + If router and uuid are supplied, then the policy with specified + uuid is deleted. It is an error if uuid does not exist, unless + --if-exists is specified. + + lr-policy-list router + Lists the polices on router. + + NAT Commands + [--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 + of an existing logical switch port where the logical_ip resides. + The external_mac is an Ethernet address. + + When --stateless is specified then it implies that we will be + not use connection tracker, i.e internal ip and external ip are + 1:1 mapped. This implies that --stateless is applicable only to + dnat_and_snat type NAT rules. An external ip with --stateless + 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ā€ + 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 + canā€™t be inferred from the external_ip, it is an error to not + specify the GATEWAY_PORT. + + 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 + 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ā€ + 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 + 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ā€ + 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 + 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 + 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 + external_ip. + + 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 + [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 + 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 + 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 + named lb, unless --may-exist is specified. With --add-duplicate, + the command really creates a new load balancer with a duplicate + name. + + 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. + + If the load balancer is created with --event option and it has + no active backends, whenever the lb receives traffic, the event + is reported in the Controller_Event table in the SB db. Please + note --event option canā€™t be specified with --reject one. + + The following example adds a load balancer. + + lb-add lb0 30.0.0.10:80 + 192.168.10.10:80,192.168.10.20:80,192.168.10.30:80 udp + + [--if-exists] lb-del lb [vip] + Deletes lb or the vip from lb. If vip is supplied, only the vip + will be deleted from the lb. If only the lb is supplied, the lb + will be deleted. It is an error if vip does not already exist in + lb, unless --if-exists is specified. + + lb-list [lb] + 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 + 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 + 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 + 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 + is specified. + + lr-lb-list router + Lists the LBs for the given router. + + DHCP Options commands + dhcp-options-create cidr [key=value] + Creates a new DHCP Options entry in the DHCP_Options table with + the specified cidr and optional external-ids. + + dhcp-options-list + Lists the DHCP Options entries. + + dhcp-options-del dhcp-option + Deletes the DHCP Options entry referred by dhcp-option UUID. + + dhcp-options-set-options dhcp-option [key=value]... + Set the DHCP Options for the dhcp-option UUID. + + dhcp-options-get-options dhcp-option + Lists the DHCP Options for the dhcp-option UUID. + + Port Group commands + pg-add group [port]... + 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 + group does not exist. + + pg-del group + 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 + 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-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 + priority is updated. The chassis should be the name of the chasā€ + sis in the OVN_Southbound. + + ha-chassis-group-remove-chassis group chassis + Removes the HA chassis chassis from the HA chassis group group. + It is an error if chassis does not exist. + + 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ā€ā€ + cal_Router tables. Protocol packets for which CoPP is enforced when + sending packets to ovn-controller (if configured): + + ā€¢ ARP + + ā€¢ ND_NS + + ā€¢ ND_NA + + ā€¢ ND_RA + + ā€¢ ND + + ā€¢ DNS + + ā€¢ IGMP + + ā€¢ packets that require ARP resolution 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 TCP RST + + ā€¢ packets that need to be replied to with DHCP_OPTS + + ā€¢ packets that trigger a reject action + + ā€¢ packets that trigger a SCTP abort action + + ā€¢ controller_events + + ā€¢ BFD + + copp-add name proto meter + Adds the control proto to meter mapping to the control + plane protection policy name. If no policy exists yet, it + creates one. If a mapping already existed for proto, this + will overwrite it. + + copp-del name [proto] + Removes the control proto mapping for the name control + plane protection policy. If proto is not specified, the + whole control plane protection policy is destroyed. + + copp-list name + Display the current control plane protection policy for + name. + + ls-copp-add name switch + Adds the control plane protection policy name to the logā€ + ical switch switch. + + lr-copp-add name router + Adds the control plane protection policy name to the logā€ + ical router router. + + Mirror commands + 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 , erspan or local. + + 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, + to-lport or both. + + 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. + + mirror-list + Lists the mirrors. + + 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 + 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 adā€ + ministrator to use ovn-nbctl to configure database connections. + + get-connection + Prints the configured connection(s). + + del-connection + Deletes the configured connection(s). + + [--inactivity-probe=msecs] set-connection target... + 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 + Prints the SSL configuration. + + del-ssl + Deletes the current SSL configuration. + + [--bootstrap] set-ssl private-key certificate ca-cert [ssl-protocol- + list [ssl-cipher-list]] + Sets the SSL configuration. + + Database Commands + These commands query and modify the contents of ovsdb tables. They are + a slight abstraction of the ovsdb interface and as such they operate at + a lower level than other ovn-nbctl commands. + + Identifying Tables, Records, and Columns + + 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 + 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 + 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, + e.g. d or dhcp is sufficient to identify the DHCP_Options table. + + Database Values + + Each column in the database accepts a fixed type of data. The currently + defined basic types, and their representations, are: + + integer + A decimal integer in the range -2**63 to 2**63-1, incluā€ + sive. + + real A floating-point number. + + 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ā€ + 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 + 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 + 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 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 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 + [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 + 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 igā€ + nores any record that does not exist, without producing + any output. + + [--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ā€ + 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 + value, respectively. + + 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 + pairs, first all the keys are compared, and values + 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 + 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 the flood-vlans column is + 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 + 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 + {<=}.) + + {not-in} + 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 + not those that lack an mtu key. + + 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 + key. + + 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 + invocation will be wrong. + + [--if-exists] [--id=@name] get table record [column[:key]]... + 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 + 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 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 + both are omitted, then get has no effect except to verify + that record exists in table. + + --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 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 + 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 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 + 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ā€ + 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 + 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. + + 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 + 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 + record does not exist. + + [--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 + 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 + references may precede or follow the create command. + + If a valid uuid is specified, then it is used as the UUID + 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 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 + 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 + some examples that show how to do this. + + [--if-exists] destroy table record... + 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 + for more information. + + 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 + 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 + 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ā€ā€ + 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 + ovs-vsctl initially connects to the database. + + 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ā€ + mand and its arguments. + +ENVIRONMENT + OVN_NB_DAEMON + If set, this should name the Unix domain socket for an ovn-nbctl + server process. See Daemon Mode, above, for more information. + + OVN_NBCTL_OPTIONS + 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 + not used. + +EXIT STATUS + 0 Successful program execution. + + 1 Usage, syntax, or network error. + +SEE ALSO + ovn-nb(5), ovn-appctl(8). + +OVN 23.06.3 ovn-nbctl ovn-nbctl(8) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-northd.8 b/src/static/support/dist-docs-branch-23.06/ovn-northd.8 new file mode 100644 index 00000000..569d5b17 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-northd.8 @@ -0,0 +1,2808 @@ +'\" p +.\" -*- nroff -*- +.TH "ovn-northd" 8 "ovn-northd" "OVN 23\[char46]06\[char46]3" "OVN Manual" +.fp 5 L CR \\" Make fixed-width font available as \\fL. +.de TQ +. br +. ns +. TP "\\$1" +.. +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +.de SU +. PP +. I "\\$1" +.. +.PP +.SH "NAME" +.PP +.PP +ovn-northd and ovn-northd-ddlog \- Open Virtual Network central control daemon +.SH "SYNOPSIS" +.PP +\fBovn\-northd\fR [\fIoptions\fR] +.SH "DESCRIPTION" +.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 +The OVSDB database containing the OVN Northbound Database\[char46] If the \fBOVN_NB_DB\fR environment variable is set, its value is used as the default\[char46] Otherwise, the default is \fBunix:/ovnnb_db\[char46]sock\fR\[char46] +.TP +\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] +.SS "Daemon Options" +.TP +\fB\-\-pidfile\fR[\fB=\fR\fIpidfile\fR] +Causes a file (by default, \fB\fIprogram\fB\[char46]pid\fR) to be created indicating the PID of the running process\[char46] If the \fIpidfile\fR argument is not specified, or if it does not begin with \fB/\fR, then it is created in \fB\fR\[char46] +.IP +If \fB\-\-pidfile\fR is not specified, no pidfile is created\[char46] +.TP +\fB\-\-overwrite\-pidfile\fR +By default, when \fB\-\-pidfile\fR is specified and the specified pidfile already exists and is locked by a running process, the daemon refuses to start\[char46] Specify \fB\-\-overwrite\-pidfile\fR to cause it to instead overwrite the pidfile\[char46] +.IP +When \fB\-\-pidfile\fR is not specified, this option has no effect\[char46] +.TP +\fB\-\-detach\fR +Runs this program as a background process\[char46] 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 \fB\-\-no\-chdir\fR is specified)\[char46] After the child completes its initialization, the parent exits\[char46] +.TP +\fB\-\-monitor\fR +Creates an additional process to monitor this program\[char46] If it dies due to a signal that indicates a programming error (\fBSIGABRT\fR, \fBSIGALRM\fR, \fBSIGBUS\fR, \fBSIGFPE\fR, \fBSIGILL\fR, \fBSIGPIPE\fR, \fBSIGSEGV\fR, \fBSIGXCPU\fR, or \fBSIGXFSZ\fR) then the monitor process starts a new copy of it\[char46] If the daemon dies or exits for another reason, the monitor process exits\[char46] +.IP +This option is normally used with \fB\-\-detach\fR, but it also functions without it\[char46] +.TP +\fB\-\-no\-chdir\fR +By default, when \fB\-\-detach\fR is specified, the daemon changes its current working directory to the root directory after it detaches\[char46] Otherwise, invoking the daemon from a carelessly chosen directory would prevent the administrator from unmounting the file system that holds that directory\[char46] +.IP +Specifying \fB\-\-no\-chdir\fR suppresses this behavior, preventing the daemon from changing its current working directory\[char46] 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\[char46] +.IP +This option has no effect when \fB\-\-detach\fR is not specified\[char46] +.TP +\fB\-\-no\-self\-confinement\fR +By default this daemon will try to self-confine itself to work with files under well-known directories determined at build time\[char46] 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\[char46] Note that in contrast to other access control implementations that are typically enforced from kernel-space (e\[char46]g\[char46] 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 additional layer of security\[char46] +.TP +\fB\-\-user=\fR\fIuser\fR\fB:\fR\fIgroup\fR +Causes this program to run as a different user specified in \fIuser\fR\fB:\fR\fIgroup\fR, thus dropping most of the root privileges\[char46] Short forms \fIuser\fR and \fB:\fR\fIgroup\fR are also allowed, with current user or group assumed, respectively\[char46] Only daemons started by the root user accepts this argument\[char46] +.IP +On Linux, daemons will be granted \fBCAP_IPC_LOCK\fR and \fBCAP_NET_BIND_SERVICES\fR before dropping root privileges\[char46] Daemons that interact with a datapath, such as \fBovs\-vswitchd\fR, will be granted three additional capabilities, namely \fBCAP_NET_ADMIN\fR, \fBCAP_NET_BROADCAST\fR and \fBCAP_NET_RAW\fR\[char46] The capability change will apply even if the new user is root\[char46] +.IP +On Windows, this option is not currently supported\[char46] For security reasons, specifying this option will cause the daemon process not to start\[char46] +.SS "Logging Options" +.TP +\fB\-v\fR[\fIspec\fR] +.TQ .5in +\fB\-\-verbose=\fR[\fIspec\fR] +Sets logging levels\[char46] Without any \fIspec\fR, sets the log level for every module and destination to \fBdbg\fR\[char46] Otherwise, \fIspec\fR is a list of words separated by spaces or commas or colons, up to one from each category below: +.RS +.IP \(bu +A valid module name, as displayed by the \fBvlog/list\fR command on \fBovs\-appctl\fR(8), limits the log level change to the specified module\[char46] +.IP \(bu +\fBsyslog\fR, \fBconsole\fR, or \fBfile\fR, to limit the log level change to only to the system log, to the console, or to a file, respectively\[char46] (If \fB\-\-detach\fR is specified, the daemon closes its standard file descriptors, so logging to the console will have no effect\[char46]) +.IP +On Windows platform, \fBsyslog\fR is accepted as a word and is only useful along with the \fB\-\-syslog\-target\fR option (the word has no effect otherwise)\[char46] +.IP \(bu +\fBoff\fR, \fBemer\fR, \fBerr\fR, \fBwarn\fR, \fBinfo\fR, or \fBdbg\fR, to control the log level\[char46] Messages of the given severity or higher will be logged, and messages of lower severity will be filtered out\[char46] \fBoff\fR filters out all messages\[char46] See \fBovs\-appctl\fR(8) for a definition of each log level\[char46] +.RE +.IP +Case is not significant within \fIspec\fR\[char46] +.IP +Regardless of the log levels set for \fBfile\fR, logging to a file will not take place unless \fB\-\-log\-file\fR is also specified (see below)\[char46] +.IP +For compatibility with older versions of OVS, \fBany\fR is accepted as a word but has no effect\[char46] +.TP +\fB\-v\fR +.TQ .5in +\fB\-\-verbose\fR +Sets the maximum logging verbosity level, equivalent to \fB\-\-verbose=dbg\fR\[char46] +.TP +\fB\-vPATTERN:\fR\fIdestination\fR\fB:\fR\fIpattern\fR +.TQ .5in +\fB\-\-verbose=PATTERN:\fR\fIdestination\fR\fB:\fR\fIpattern\fR +Sets the log pattern for \fIdestination\fR to \fIpattern\fR\[char46] Refer to \fBovs\-appctl\fR(8) for a description of the valid syntax for \fIpattern\fR\[char46] +.TP +\fB\-vFACILITY:\fR\fIfacility\fR +.TQ .5in +\fB\-\-verbose=FACILITY:\fR\fIfacility\fR +Sets the RFC5424 facility of the log message\[char46] \fIfacility\fR can be one of \fBkern\fR, \fBuser\fR, \fBmail\fR, \fBdaemon\fR, \fBauth\fR, \fBsyslog\fR, \fBlpr\fR, \fBnews\fR, \fBuucp\fR, \fBclock\fR, \fBftp\fR, \fBntp\fR, \fBaudit\fR, \fBalert\fR, \fBclock2\fR, \fBlocal0\fR, \fBlocal1\fR, \fBlocal2\fR, \fBlocal3\fR, \fBlocal4\fR, \fBlocal5\fR, \fBlocal6\fR or \fBlocal7\fR\[char46] If this option is not specified, \fBdaemon\fR is used as the default for the local system syslog and \fBlocal0\fR is used while sending a message to the target provided via the \fB\-\-syslog\-target\fR option\[char46] +.TP +\fB\-\-log\-file\fR[\fB=\fR\fIfile\fR] +Enables logging to a file\[char46] If \fIfile\fR is specified, then it is used as the exact name for the log file\[char46] The default log file name used if \fIfile\fR is omitted is \fB/usr/local/var/log/ovn/\fIprogram\fB\[char46]log\fR\[char46] +.TP +\fB\-\-syslog\-target=\fR\fIhost\fR\fB:\fR\fIport\fR +Send syslog messages to UDP \fIport\fR on \fIhost\fR, in addition to the system syslog\[char46] The \fIhost\fR must be a numerical IP address, not a hostname\[char46] +.TP +\fB\-\-syslog\-method=\fR\fImethod\fR +Specify \fImethod\fR as how syslog messages should be sent to syslog daemon\[char46] The following forms are supported: +.RS +.IP \(bu +\fBlibc\fR, to use the libc \fBsyslog()\fR function\[char46] Downside of using this options is that libc adds fixed prefix to every message before it is actually sent to the syslog daemon over \fB/dev/log\fR UNIX domain socket\[char46] +.IP \(bu +\fBunix:\fIfile\fB\fR, to use a UNIX domain socket directly\[char46] It is possible to specify arbitrary message format with this option\[char46] However, \fBrsyslogd 8\[char46]9\fR and older versions use hard coded parser function anyway that limits UNIX domain socket use\[char46] If you want to use arbitrary message format with older \fBrsyslogd\fR versions, then use UDP socket to localhost IP address instead\[char46] +.IP \(bu +\fBudp:\fIip\fB:\fIport\fB\fR, to use a UDP socket\[char46] With this method it is possible to use arbitrary message format also with older \fBrsyslogd\fR\[char46] When sending syslog messages over UDP socket extra precaution needs to be taken into account, for example, 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\[char46] +.IP \(bu +\fBnull\fR, to discard all messages logged to syslog\[char46] +.RE +.IP +The default is taken from the \fBOVS_SYSLOG_METHOD\fR environment variable; if it is unset, the default is \fBlibc\fR\[char46] +.SS "PKI Options" +.PP +.PP +PKI configuration is required in order to use SSL for the connections to the Northbound and Southbound databases\[char46] +.RS +.TP +\fB\-p\fR \fIprivkey\[char46]pem\fR +.TQ .5in +\fB\-\-private\-key=\fR\fIprivkey\[char46]pem\fR +Specifies a PEM file containing the private key used as identity for outgoing SSL connections\[char46] +.TP +\fB\-c\fR \fIcert\[char46]pem\fR +.TQ .5in +\fB\-\-certificate=\fR\fIcert\[char46]pem\fR +Specifies a PEM file containing a certificate that certifies the private key specified on \fB\-p\fR or \fB\-\-private\-key\fR to be trustworthy\[char46] The certificate must be signed by the certificate authority (CA) that the peer in SSL connections will use to verify it\[char46] +.TP +\fB\-C\fR \fIcacert\[char46]pem\fR +.TQ .5in +\fB\-\-ca\-cert=\fR\fIcacert\[char46]pem\fR +Specifies a PEM file containing the CA certificate for verifying certificates presented to this program by SSL peers\[char46] (This may be the same certificate that SSL peers use to verify the certificate specified on \fB\-c\fR or \fB\-\-certificate\fR, or it may be a different one, depending on the PKI design in use\[char46]) +.TP +\fB\-C none\fR +.TQ .5in +\fB\-\-ca\-cert=none\fR +Disables verification of certificates presented by SSL peers\[char46] This introduces a security risk, because it means that certificates cannot be verified to be those of known trusted hosts\[char46] +.RE +.SS "Other Options" +.TP +\fB\-\-unixctl=\fIsocket\fB\fR +Sets the name of the control socket on which \fB\fIprogram\fB\fR listens for runtime management commands (see \fIRUNTIME MANAGEMENT COMMANDS,\fR below)\[char46] If \fIsocket\fR does not begin with \fB/\fR, it is interpreted as relative to \fB\fR\[char46] If \fB\-\-unixctl\fR is not used at all, the default socket is \fB/\fIprogram\fB\[char46]\fR\fIpid\fR\fB\[char46]ctl\fR, where \fIpid\fR is \fB\fIprogram\fB\fR\(cqs process ID\[char46] +.IP +On Windows a local named pipe is used to listen for runtime management commands\[char46] A file is created in the absolute path as pointed by \fIsocket\fR or if \fB\-\-unixctl\fR is not used at all, a file is created as \fB\fIprogram\fB\fR in the configured \fIOVS_RUNDIR\fR directory\[char46] The file exists just to mimic the behavior of a Unix domain socket\[char46] +.IP +Specifying \fBnone\fR for \fIsocket\fR disables the control socket feature\[char46] +.ST "" +.TP +\fB\-h\fR +.TQ .5in +\fB\-\-help\fR +Prints a brief help message to the console\[char46] +.TP +\fB\-V\fR +.TQ .5in +\fB\-\-version\fR +Prints version information to the console\[char46] +.SH "RUNTIME MANAGEMENT COMMANDS" +.PP +.PP +\fBovs\-appctl\fR can send commands to a running \fBovn\-northd\fR process\[char46] The currently supported commands are described below\[char46] +.RS +.TP +\fBexit\fR +Causes \fBovn\-northd\fR to gracefully terminate\[char46] +.TP +\fBpause\fR +Pauses \fBovn\-northd\fR\[char46] When it is paused, \fBovn\-northd\fR receives changes from the Northbound and Southbound database changes as usual, but it does not send any updates\[char46] A paused \fBovn\-northd\fR also drops database locks, which allows any other non-paused instance of \fBovn\-northd\fR to take over\[char46] +.TP +\fBresume\fR +Resumes the ovn-northd operation to process Northbound and Southbound database contents and generate logical flows\[char46] This will also instruct ovn-northd to aspire for the lock on SB DB\[char46] +.TP +\fBis\-paused\fR +Returns \(dqtrue\(dq if ovn-northd is currently paused, \(dqfalse\(dq otherwise\[char46] +.TP +\fBstatus\fR +Prints this server\(cqs status\[char46] Status will be \(dqactive\(dq if ovn-northd has acquired OVSDB lock on SB DB, \(dqstandby\(dq if it has not or \(dqpaused\(dq if this instance is paused\[char46] +.TP +\fBsb\-cluster\-state\-reset\fR +Reset southbound database cluster status when databases are destroyed and rebuilt\[char46] +.IP +If all databases in a clustered southbound database are removed from disk, then the stored index of all databases will be reset to zero\[char46] 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\[char46] 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\[char46] +.TP +\fBnb\-cluster\-state\-reset\fR +Reset northbound database cluster status when databases are destroyed and rebuilt\[char46] +.IP +This performs the same task as \fBsb\-cluster\-state\-reset\fR except for the northbound database client\[char46] +.TP +\fBset\-n\-threads N\fR +Set the number of threads used for building logical flows\[char46] When N is within [2\-256], parallelization is enabled\[char46] When N is 1 parallelization is disabled\[char46] When N is less than 1 or more than 256, an error is returned\[char46] If ovn-northd fails to start parallelization (e\[char46]g\[char46] fails to setup semaphores, parallelization is disabled and an error is returned\[char46] +.TP +\fBget\-n\-threads\fR +Return the number of threads used for building logical flows\[char46] +.TP +\fBinc\-engine/show\-stats\fR +Display \fBovn\-northd\fR engine counters\[char46] For each engine node the following counters have been added: +.RS +.IP \(bu +\fBrecompute\fR +.IP \(bu +\fBcompute\fR +.IP \(bu +\fBabort\fR +.RE +.TP +\fBinc\-engine/show\-stats \fIengine_node_name\fB \fIcounter_name\fB\fR +Display the \fBovn\-northd\fR engine counter(s) for the specified \fIengine_node_name\fR\[char46] \fIcounter_name\fR is optional and can be one of \fBrecompute\fR, \fBcompute\fR or \fBabort\fR\[char46] +.TP +\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 +You may run \fBovn\-northd\fR more than once in an OVN deployment\[char46] When connected to a standalone or clustered DB setup, OVN will automatically ensure that only one of them is active at a time\[char46] If multiple instances of \fBovn\-northd\fR are running and the active \fBovn\-northd\fR fails, one of the hot standby instances of \fBovn\-northd\fR will automatically take over\[char46] +.SS "Active\-Standby with multiple OVN DB servers" +.PP +.PP +You may run multiple OVN DB servers in an OVN deployment with: +.RS +.IP \(bu +OVN DB servers deployed in active/passive mode with one active and multiple passive ovsdb-servers\[char46] +.IP \(bu +\fBovn\-northd\fR also deployed on all these nodes, using unix ctl sockets to connect to the local OVN DB servers\[char46] +.RE +.PP +.PP +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\[char46] It results in unnecessary CPU usage\[char46] +.PP +.PP +With the help of runtime management command \fBpause\fR, you can pause \fBovn\-northd\fR on these nodes\[char46] When a passive node becomes master, you can use the runtime management command \fBresume\fR to resume the \fBovn\-northd\fR to process the DB changes\[char46] +.SH "LOGICAL FLOW TABLE STRUCTURE" +.PP +.PP +One of the main purposes of \fBovn\-northd\fR is to populate the \fBLogical_Flow\fR table in the \fBOVN_Southbound\fR database\[char46] This section describes how \fBovn\-northd\fR does this for switch and router logical datapaths\[char46] +.SS "Logical Switch Datapaths" +.ST "Ingress Table 0: Admission Control and Ingress Port Security check" +.PP +.PP +Ingress table 0 contains these logical flows: +.RS +.IP \(bu +Priority 100 flows to drop packets with VLAN tags or multicast Ethernet source addresses\[char46] +.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] +.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] +.IP \(bu +A priority 1 flow is added which matches on all packets for all the logical ports and applies the action \fBREGBIT_PORT_SEC_DROP\(dq = check_in_port_sec(); next;\fR to evaluate the port security\[char46] The action \fBcheck_in_port_sec\fR applies the port security rules defined in the \fBport_security\fR column of \fBLogical_Switch_Port\fR table\[char46] +.RE +.ST "Ingress Table 1: Ingress Port Security - Apply" +.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 +Ingress table 1 contains these logical flows: +.RS +.IP \(bu +A priority\-50 fallback flow that drops the packet if the register bit \fBREGBIT_PORT_SEC_DROP\fR is set to 1\[char46] +.IP \(bu +One priority\-0 fallback flow that matches all packets and advances to the next table\[char46] +.RE +.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 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 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 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 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] +.RE +.IP \(bu +One priority\-0 fallback flow that matches all packets and advances to the next table\[char46] +.RE +.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] +.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] +.ST "Ingress Table 5: Pre-LB" +.PP +.PP +This table prepares flows for possible stateful load balancing processing in ingress table \fBLB\fR and \fBStateful\fR\[char46] It contains a priority\-0 flow that simply moves traffic to the next table\[char46] Moreover it contains two priority\-110 flows to move multicast, IPv6 Neighbor Discovery and MLD traffic to the next table\[char46] It also contains two priority\-110 flows to move stateless traffic, i\[char46]e traffic for which \fBREGBIT_ACL_STATELESS\fR is set, to the next table\[char46] If load balancing rules with virtual IP addresses (and ports) are configured in \fBOVN_Northbound\fR database for a logical switch datapath, a priority\-100 flow is added with the match \fBip\fR to match on IP packets and sets the action \fBreg0[2] = 1; next;\fR to act as a hint for table \fBPre\-stateful\fR 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 \fBStateful\fR\[char46] If controller_event has been enabled and load balancing rules with empty backends have been added in \fBOVN_Northbound\fR, a 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 +.PP +.PP +Prior to \fBOVN 20\[char46]09\fR we were setting the \fBreg0[0] = 1\fR only if the IP destination matches the load balancer VIP\[char46] However this had few issues cases where a logical switch doesn\(cqt have any ACLs with \fBallow\-related\fR action\[char46] To understand the issue lets a take a TCP load balancer - \fB10\[char46]0\[char46]0\[char46]10:80=10\[char46]0\[char46]0\[char46]3:80\fR\[char46] If a logical port - p1 with IP - 10\[char46]0\[char46]0\[char46]5 opens a TCP connection with the VIP - 10\[char46]0\[char46]0\[char46]10, then the packet in the ingress pipeline of \(cqp1\(cq is sent to the p1\(cqs conntrack zone id and the packet is load balanced to the backend - 10\[char46]0\[char46]0\[char46]3\[char46] For the reply packet from the backend lport, it is not sent to the conntrack of backend lport\(cqs zone id\[char46] This is fine as long as the packet is valid\[char46] Suppose the backend lport sends an invalid TCP packet (like incorrect sequence number), the packet gets delivered to the lport \(cqp1\(cq without unDNATing the packet to the VIP - 10\[char46]0\[char46]0\[char46]10\[char46] And this causes the connection to be reset by the lport p1\(cqs VIF\[char46] +.PP +.PP +We can\(cqt fix this issue by adding a logical flow to drop ct\[char46]inv packets in the egress pipeline since it will drop all other connections not destined to the load balancers\[char46] To fix this issue, we send all the packets to the conntrack in the ingress pipeline if a load balancer is configured\[char46] We can now add a lflow to drop ct\[char46]inv packets\[char46] +.PP +.PP +This table also has priority\-120 flows that punt all IGMP/MLD packets to \fBovn\-controller\fR if the switch is an interconnect switch with multicast snooping enabled\[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] +.PP +.PP +This table also has a priority\-110 flow with the match \fBinport == \fII\fB\fR for all logical switch datapaths to move traffic to the next table\[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 enter from logical router datapath to logical switch datapath\[char46] +.ST "Ingress Table 6: Pre-stateful" +.PP +.PP +This table prepares flows for all possible stateful processing in next tables\[char46] It contains a priority\-0 flow that simply moves traffic to the next table\[char46] +.RS +.IP \(bu +Priority\-120 flows that send the packets to connection tracker using \fBct_lb_mark;\fR as the action so that the already established traffic destined to the load balancer VIP gets DNATted\[char46] These flows match each VIPs IP and port\[char46] For IPv4 traffic the flows also load the original destination IP and transport port in registers \fBreg1\fR and \fBreg2\fR\[char46] For IPv6 traffic the flows also load the original destination IP and transport port in registers \fBxxreg1\fR and \fBreg2\fR\[char46] +.IP \(bu +A priority\-110 flow sends the packets that don\(cqt match the above flows to connection tracker based on a hint provided by the previous tables (with a match for \fBreg0[2] == 1\fR) by using the \fBct_lb_mark;\fR action\[char46] +.IP \(bu +A priority\-100 flow sends the packets to connection tracker based on a hint provided by the previous tables (with a match for \fBreg0[0] == 1\fR) by using the \fBct_next;\fR action\[char46] +.RE +.ST "Ingress Table 7: \fBfrom\-lport\fI ACL hints" +.PP +.PP +This table consists of logical flows that set hints (\fBreg0\fR bits) to be used in the next stage, in the ACL processing table, if stateful ACLs or load balancers are configured\[char46] Multiple hints can be set for the same packet\[char46] The possible hints are: +.RS +.IP \(bu +\fBreg0[7]\fR: the packet might match an \fBallow\-related\fR ACL and might have to commit the connection to conntrack\[char46] +.IP \(bu +\fBreg0[8]\fR: the packet might match an \fBallow\-related\fR ACL but there will be no need to commit the connection to conntrack because it already exists\[char46] +.IP \(bu +\fBreg0[9]\fR: the packet might match a \fBdrop/reject\fR\[char46] +.IP \(bu +\fBreg0[10]\fR: the packet might match a \fBdrop/reject\fR ACL but the connection was previously allowed so it might have to be committed again with \fBct_label=1/1\fR\[char46] +.RE +.PP +.PP +The table contains the following flows: +.RS +.IP \(bu +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\[char46] +.RE +.RS +.IP \(bu +A priority\-7 flow that matches on packets that initiate a new session\[char46] This flow sets \fBreg0[7]\fR and \fBreg0[9]\fR and then advances to the next table\[char46] +.IP \(bu +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\[char46] This flow sets \fBreg0[7]\fR and \fBreg0[9]\fR and then advances to the next table\[char46] +.IP \(bu +A priority\-5 flow that matches untracked packets\[char46] This flow sets \fBreg0[8]\fR and \fBreg0[9]\fR and then advances to the next table\[char46] +.IP \(bu +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\[char46] This flow sets \fBreg0[8]\fR and \fBreg0[10]\fR and then advances to the next table\[char46] +.IP \(bu +A priority\-3 flow that matches on packets that are in not part of established sessions\[char46] This flow sets \fBreg0[9]\fR and then advances to the next table\[char46] +.IP \(bu +A priority\-2 flow that matches on packets that are part of an established session that has been marked as blocked\[char46] This flow sets \fBreg0[9]\fR and then advances to the next table\[char46] +.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 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 +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 +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\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 +\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 +\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 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: +.RS +.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 +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\-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 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 sets the drop bit for all traffic marked by the connection tracker as invalid\[char46] +.IP \(bu +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 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 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] +.RS +.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 +One priority\-0 fallback flow that matches all packets and advances to the next table\[char46] +.RE +.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] +.RS +.IP \(bu +For every qos_rules entry in a logical switch with metering 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 12: Load balancing affinity check" +.PP +.PP +Load balancing affinity check table contains the following logical flows: +.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\-100 flow is added\[char46] For IPv4 \fIVIPs\fR, the flow matches \fBct\[char46]new && ip && ip4\[char46]dst == \fIVIP\fB +&& \fIP\fB\[char46]dst == \fIPORT\fB\fR\[char46] For IPv6 \fIVIPs\fR, the flow matches \fBct\[char46]new && ip && +ip6\[char46]dst == \fIVIP\fB&& \fIP\fB && +\fIP\fB\[char46]dst == \fI PORT\fB\fR\[char46] The flow\(cqs action is \fBreg9[6] = chk_lb_aff(); next;\fR\[char46] +.IP \(bu +A priority 0 flow is added which matches on all packets and applies the action \fBnext;\fR\[char46] +.RE +.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 && +ip4\[char46]dst == \fIVIP\fB && \fIP\fB\[char46]dst == \fIPORT +\fB\fR\[char46] For IPv6 \fIVIPs\fR, the flow matches \fBreg9[6] == 1 && ct\[char46]new && ip && +ip6\[char46]dst == \fI VIP \fB&& \fIP\fB && +\fIP\fB\[char46]dst == \fI PORT\fB\fR\[char46] The flow\(cqs action is \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 +For all the configured load balancing rules for a switch in \fBOVN_Northbound\fR database that includes a L4 port \fIPORT\fR of protocol \fIP\fR and IP address \fIVIP\fR, a priority\-120 flow is added\[char46] For IPv4 \fIVIPs +\fR, the flow matches \fBct\[char46]new && ip && +ip4\[char46]dst == \fIVIP\fB && +\fIP\fB\[char46]dst == \fIPORT\fB\fR\[char46] For IPv6 \fIVIPs\fR, the flow matches \fBct\[char46]new && ip && ip6\[char46]dst == \fI +VIP \fB&& \fIP\fB && \fIP\fB\[char46]dst == \fI +PORT\fB\fR\[char46] The flow\(cqs action is \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] 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] For IPv4 traffic the flow also loads the original destination IP and transport port in registers \fBreg1\fR and \fBreg2\fR\[char46] For IPv6 traffic the flow also loads the original destination IP and transport port in registers \fBxxreg1\fR and \fBreg2\fR\[char46] The above flow is created even if the load balancer is attached to a logical router connected to the current logical switch and the \fBinstall_ls_lb_from_router\fR variable in \fBoptions\fR is set to true\[char46] +.IP \(bu +For all the configured load balancing rules for a switch in \fBOVN_Northbound\fR database that includes just an IP address \fIVIP\fR to match on, OVN adds a priority\-110 flow\[char46] For IPv4 \fIVIPs\fR, the flow matches \fBct\[char46]new && ip && +ip4\[char46]dst == \fIVIP\fB\fR\[char46] For IPv6 \fIVIPs\fR, the flow matches \fBct\[char46]new && ip && ip6\[char46]dst == \fI +VIP\fB\fR\[char46] The action on this flow is \fB +ct_lb_mark(\fIargs\fB)\fR, where \fIargs\fR contains comma separated IP addresses of the same address family as \fIVIP\fR\[char46] For IPv4 traffic the flow also loads the original destination IP and transport port in registers \fBreg1\fR and \fBreg2\fR\[char46] For IPv6 traffic the flow also loads the original destination IP and transport port in registers \fBxxreg1\fR and \fBreg2\fR\[char46] The above flow is created even if the load balancer is attached to a logical router connected to the current logical switch and the \fBinstall_ls_lb_from_router\fR variable in \fBoptions\fR is set to true\[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] +.RE +.ST "Ingress Table 14: Load balancing affinity learn" +.PP +.PP +Load balancing affinity learn table contains the following logical flows: +.RS +.IP \(bu +For all the configured load balancing rules for a switch in \fBOVN_Northbound\fR database where a positive affinity timeout \fIT\fR is specified in \fBoptions\fR column, that includes a L4 port \fIPORT\fR of protocol \fIP\fR and IP address \fIVIP\fR, a priority\-100 flow is added\[char46] For IPv4 \fIVIPs\fR, the flow matches \fBreg9[6] == 0 && ct\[char46]new && ip +&& ip4\[char46]dst == \fIVIP\fB && \fIP\fB\[char46]dst == +\fIPORT\fB\fR\[char46] For IPv6 \fIVIPs\fR, the flow matches \fBct\[char46]new && ip && ip6\[char46]dst == \fIVIP\fB +&& \fIP\fB && \fIP\fB\[char46]dst == \fIPORT\fB +\fR\[char46] The flow\(cqs action is \fBcommit_lb_aff(vip = +\fIVIP\fB:\fIPORT\fB, backend = \fIbackend ip\fB: +\fIbackend port\fB, proto = \fIP\fB, timeout = \fIT\fB); +\fR\[char46] +.IP \(bu +A priority 0 flow is added which matches on all packets and applies the action \fBnext;\fR\[char46] +.RE +.ST "Ingress Table 15: 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] +.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 +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 +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 +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 +A priority\-0 flow that simply moves traffic to the next table\[char46] +.RE +.ST "Ingress Table 17: Hairpin" +.RS +.IP \(bu +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 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 +\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 +\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 +\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 +.RS +.IP \(bu +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 +One priority\-0 fallback flow that matches all packets and advances to the next table\[char46] +.RE +.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 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 20: Stateful" +.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] +.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] +.IP \(bu +A priority\-0 flow that simply moves traffic to the next table\[char46] +.RE +.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] +.PP +.PP +ARP requests arrive from VMs from a logical switch inport of type default\[char46] For this case, the logical switch proxy ARP rules can be for other VMs or logical router ports\[char46] 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\[char46] 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\[char46] The configured MAC addresses must match as well\[char46] 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\[char46] 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\[char46] The MAC binding of a distributed logical router, once learned by an associated VM, is used for all that VM\(cqs communication needing routing\[char46] Hence, the action of a VM re-arping for the mac binding of the logical router port should be rare\[char46] +.PP +.PP +Logical switch ARP responder proxy ARP rules can also be hit when receiving ARP requests externally on a L2 gateway port\[char46] In this case, the hypervisor acting as an L2 gateway, responds to the ARP request on behalf of a destination VM\[char46] +.PP +.PP +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 +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 +.nf +\fB +.br +\fB\fR\fBinport == \fIP\fB && && ((arp\[char46]op == 1 && arp\[char46]spa == \fIVIP\fB && arp\[char46]tpa == \fIVIP\fB) || (arp\[char46]op == 2 && arp\[char46]spa == \fIVIP\fB))\fB\fR +.br +\fB\fR\fBinport == \fIP\fB && && ((nd_ns && ip6\[char46]dst == \fI{VIP, NS_MULTICAST_ADDR}\fB && nd\[char46]target == \fIVIP\fB) || (nd_na && nd\[char46]target == \fIVIP\fB))\fB\fR +.br +\fB \fR +.fi +.IP +and applies the action +.IP +.nf +\fB +.br +\fB\fR\fBbind_vport(\fIV\fB, inport);\fB\fR +.br +\fB \fR +.fi +.IP +and advances the packet to the next table\[char46] +.IP +Where \fIVIP\fR is the virtual ip configured in the column \fBoptions:virtual-ip\fR and NS_MULTICAST_ADDR is solicited-node multicast address corresponding to the VIP\[char46] +.IP \(bu +Priority\-50 flows that match ARP requests to each known IP address \fIA\fR of every logical switch port, and respond with ARP replies directly with corresponding Ethernet address \fIE\fR: +.IP +.nf +\fB +.br +\fBeth\[char46]dst = eth\[char46]src; +.br +\fBeth\[char46]src = \fR\fIE\fB\fR; +.br +\fBarp\[char46]op = 2; /* ARP reply\[char46] */ +.br +\fBarp\[char46]tha = arp\[char46]sha; +.br +\fBarp\[char46]sha = \fR\fIE\fB\fR; +.br +\fBarp\[char46]tpa = arp\[char46]spa; +.br +\fBarp\[char46]spa = \fR\fIA\fB\fR; +.br +\fBoutport = inport; +.br +\fBflags\[char46]loopback = 1; +.br +\fBoutput; +.br +\fB \fR +.fi +.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, for logical ports with \(cqunknown\(cq address set and for logical ports of a logical switch configured with \fBother_config:vlan\-passthru=true\fR\[char46] +.IP +The above ARP responder flows are added for the list of IPv4 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\-50 flows that match IPv6 ND neighbor solicitations to each known IP address \fIA\fR (and \fIA\fR\(cqs solicited node address) of every logical switch port except of type router, and respond with neighbor advertisements directly with corresponding Ethernet address \fIE\fR: +.IP +.nf +\fB +.br +\fBnd_na { +.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 +Priority\-50 flows that match IPv6 ND neighbor solicitations to each known IP address \fIA\fR (and \fIA\fR\(cqs solicited node address) of logical switch port of type router, and respond with neighbor advertisements directly with corresponding Ethernet address \fIE\fR: +.IP +.nf +\fB +.br +\fBnd_na_router { +.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 +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 +In place of \fBnext;\fR, it would be reasonable to use \fBdrop;\fR for the flows\(cq actions\[char46] If everything is working as it is configured, then this would produce equivalent results, since no host should reply to the request\[char46] But ARPing for one\(cqs own IP address is intended to detect situations where the network is not working as configured, so dropping the request would frustrate that intent\[char46] +.IP \(bu +For each \fISVC_MON_SRC_IP\fR defined in the value of the \fBip_port_mappings:ENDPOINT_IP\fR column of \fBLoad_Balancer\fR table, priority\-110 logical flow is added with the match \fBarp\[char46]tpa == \fISVC_MON_SRC_IP\fB +&& && arp\[char46]op == 1\fR and applies the action +.IP +.nf +\fB +.br +\fBeth\[char46]dst = eth\[char46]src; +.br +\fBeth\[char46]src = \fR\fIE\fB\fR; +.br +\fBarp\[char46]op = 2; /* ARP reply\[char46] */ +.br +\fBarp\[char46]tha = arp\[char46]sha; +.br +\fBarp\[char46]sha = \fR\fIE\fB\fR; +.br +\fBarp\[char46]tpa = arp\[char46]spa; +.br +\fBarp\[char46]spa = \fR\fIA\fB\fR; +.br +\fBoutport = inport; +.br +\fBflags\[char46]loopback = 1; +.br +\fBoutput; +.br +\fB \fR +.fi +.IP +where \fIE\fR is the service monitor source mac defined in the \fBoptions:svc_monitor_mac\fR column in the \fBNB_Global\fR table\[char46] This mac is used as the source mac in the service monitor packets for the load balancer endpoint IP health checks\[char46] +.IP +\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 +.IP +.nf +\fB +.br +\fBeth\[char46]dst = eth\[char46]src; +.br +\fBeth\[char46]src = \fR\fIE\fB\fR; +.br +\fBarp\[char46]op = 2; /* ARP reply\[char46] */ +.br +\fBarp\[char46]tha = arp\[char46]sha; +.br +\fBarp\[char46]sha = \fR\fIE\fB\fR; +.br +\fBarp\[char46]tpa = arp\[char46]spa; +.br +\fBarp\[char46]spa = \fR\fIA\fB\fR; +.br +\fBoutport = inport; +.br +\fBflags\[char46]loopback = 1; +.br +\fBoutput; +.br +\fB \fR +.fi +.IP +where \fIE\fR is the forwarding group\(cqs mac defined in the \fBvmac\fR\[char46] +.IP +\fIA\fR is used as either the destination ip for load balancing traffic to child ports or as nexthop to hosts behind the child ports\[char46] +.IP +These flows are required to respond to an ARP request if an ARP request is sent for the IP \fIvip\fR\[char46] +.IP \(bu +One priority\-0 fallback flow that matches all packets and advances to the next table\[char46] +.RE +.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] +.RS +.IP \(bu +A priority\-100 logical flow is added for these logical ports which matches the IPv4 packet with \fBudp\[char46]src\fR = 68 and \fBudp\[char46]dst\fR = 67 and applies the action \fBput_dhcp_opts\fR and advances the packet to the next table\[char46] +.IP +.nf +\fB +.br +\fBreg0[3] = put_dhcp_opts(offer_ip = \fR\fIip\fB\fR, \fR\fIoptions\fB\fR\[char46]\[char46]\[char46]); +.br +\fBnext; +.br +\fB \fR +.fi +.IP +For DHCPDISCOVER and DHCPREQUEST, this transforms the packet into a DHCP reply, adds the DHCP offer IP \fIip\fR and options to the packet, and stores 1 into reg0[3]\[char46] For other kinds of packets, it just stores 0 into reg0[3]\[char46] Either way, it continues to the next table\[char46] +.IP \(bu +A priority\-100 logical flow is added for these logical ports which matches the IPv6 packet with \fBudp\[char46]src\fR = 546 and \fBudp\[char46]dst\fR = 547 and applies the action \fBput_dhcpv6_opts\fR and advances the packet to the next table\[char46] +.IP +.nf +\fB +.br +\fBreg0[3] = put_dhcpv6_opts(ia_addr = \fR\fIip\fB\fR, \fR\fIoptions\fB\fR\[char46]\[char46]\[char46]); +.br +\fBnext; +.br +\fB \fR +.fi +.IP +For DHCPv6 Solicit/Request/Confirm packets, this transforms the packet into a DHCPv6 Advertise/Reply, adds the DHCPv6 offer IP \fIip\fR and options to the packet, and stores 1 into reg0[3]\[char46] For other kinds of packets, it just stores 0 into reg0[3]\[char46] Either way, it continues to the next table\[char46] +.IP \(bu +A priority\-0 flow that matches all packets to advances to table 16\[char46] +.RE +.ST "Ingress Table 23: DHCP responses" +.PP +.PP +This table implements DHCP responder for the DHCP replies generated by the previous table\[char46] +.RS +.IP \(bu +A priority 100 logical flow is added for the logical ports configured with DHCPv4 options which matches IPv4 packets with \fBudp\[char46]src == 68 +&& udp\[char46]dst == 67 && reg0[3] == 1\fR and responds back to the \fBinport\fR after applying these actions\[char46] If \fBreg0[3]\fR is set to 1, it means that the action \fBput_dhcp_opts\fR was successful\[char46] +.IP +.nf +\fB +.br +\fBeth\[char46]dst = eth\[char46]src; +.br +\fBeth\[char46]src = \fR\fIE\fB\fR; +.br +\fBip4\[char46]src = \fR\fIS\fB\fR; +.br +\fBudp\[char46]src = 67; +.br +\fBudp\[char46]dst = 68; +.br +\fBoutport = \fR\fIP\fB\fR; +.br +\fBflags\[char46]loopback = 1; +.br +\fBoutput; +.br +\fB \fR +.fi +.IP +where \fIE\fR is the server MAC address and \fIS\fR is the server IPv4 address defined in the DHCPv4 options\[char46] Note that \fBip4\[char46]dst\fR field is handled by \fBput_dhcp_opts\fR\[char46] +.IP +(This terminates ingress packet processing; the packet does not go to the next ingress table\[char46]) +.IP \(bu +A priority 100 logical flow is added for the logical ports configured with DHCPv6 options which matches IPv6 packets with \fBudp\[char46]src == 546 +&& udp\[char46]dst == 547 && reg0[3] == 1\fR and responds back to the \fBinport\fR after applying these actions\[char46] If \fBreg0[3]\fR is set to 1, it means that the action \fBput_dhcpv6_opts\fR was successful\[char46] +.IP +.nf +\fB +.br +\fBeth\[char46]dst = eth\[char46]src; +.br +\fBeth\[char46]src = \fR\fIE\fB\fR; +.br +\fBip6\[char46]dst = \fR\fIA\fB\fR; +.br +\fBip6\[char46]src = \fR\fIS\fB\fR; +.br +\fBudp\[char46]src = 547; +.br +\fBudp\[char46]dst = 546; +.br +\fBoutport = \fR\fIP\fB\fR; +.br +\fBflags\[char46]loopback = 1; +.br +\fBoutput; +.br +\fB \fR +.fi +.IP +where \fIE\fR is the server MAC address and \fIS\fR is the server IPv6 LLA address generated from the \fBserver_id\fR defined in the DHCPv6 options and \fIA\fR is the IPv6 address defined in the logical port\(cqs addresses column\[char46] +.IP +(This terminates packet processing; the packet does not go on the next ingress table\[char46]) +.IP \(bu +A priority\-0 flow that matches all packets to advances to table 17\[char46] +.RE +.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] +.RS +.IP \(bu +A priority\-100 logical flow for each logical switch datapath if it is configured with DNS records, which matches the IPv4 and IPv6 packets with \fBudp\[char46]dst\fR = 53 and applies the action \fBdns_lookup\fR and advances the packet to the next table\[char46] +.IP +.nf +\fB +.br +\fBreg0[4] = dns_lookup(); next; +.br +\fB \fR +.fi +.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 25 DNS Responses" +.PP +.PP +This table implements DNS responder for the DNS replies generated by the previous table\[char46] +.RS +.IP \(bu +A priority\-100 logical flow for each logical switch datapath if it is configured with DNS records, which matches the IPv4 and IPv6 packets with \fBudp\[char46]dst = 53 && reg0[4] == 1\fR and responds back to the \fBinport\fR after applying these actions\[char46] If \fBreg0[4]\fR is set to 1, it means that the action \fBdns_lookup\fR was successful\[char46] +.IP +.nf +\fB +.br +\fBeth\[char46]dst <\-> eth\[char46]src; +.br +\fBip4\[char46]src <\-> ip4\[char46]dst; +.br +\fBudp\[char46]dst = udp\[char46]src; +.br +\fBudp\[char46]src = 53; +.br +\fBoutport = \fR\fIP\fB\fR; +.br +\fBflags\[char46]loopback = 1; +.br +\fBoutput; +.br +\fB \fR +.fi +.IP +(This terminates ingress packet processing; the packet does not go to the next ingress table\[char46]) +.RE +.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] +.RS +.IP \(bu +A priority\-100 flow is added for each \fBexternal\fR logical port which doesn\(cqt reside on a chassis to drop the ARP/IPv6 NS request to the router IP(s) (of the logical switch) which matches on the \fBinport\fR of the \fBexternal\fR logical port and the valid \fBeth\[char46]src\fR address(es) of the \fBexternal\fR logical port\[char46] +.IP +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\[char46] All the other chassis, drops these packets\[char46] +.IP +A priority\-100 flow is added for each \fBexternal\fR logical port which doesn\(cqt reside on a chassis to drop any packet destined to the router mac - with the match \fBinport == \fIexternal\fB && +eth\[char46]src == \fIE\fB && eth\[char46]dst == \fIR\fB +&& !is_chassis_resident(\(dq\fIexternal\fB\(dq)\fR where \fIE\fR is the external port mac and \fIR\fR is the router port mac\[char46] +.IP \(bu +A priority\-0 flow that matches all packets to advances to table 20\[char46] +.RE +.ST "Ingress Table 27 Destination Lookup" +.PP +.PP +This table implements switching behavior\[char46] It contains these logical flows: +.RS +.IP \(bu +A priority\-110 flow with the match \fBeth\[char46]src == \fIE\fB\fR for all logical switch datapaths and applies the action \fBhandle_svc_check(inport)\fR\[char46] Where \fIE\fR is the service monitor mac defined in the \fBoptions:svc_monitor_mac\fR column of \fBNB_Global\fR table\[char46] +.IP \(bu +A priority\-100 flow that punts all IGMP/MLD packets to \fBovn\-controller\fR if multicast snooping is enabled on the logical switch\[char46] +.IP \(bu +Priority\-90 flows that forward registered IP multicast traffic to their corresponding multicast group, which \fBovn\-northd\fR creates based on learnt \fBIGMP_Group\fR entries\[char46] The flows also forward packets to the \fBMC_MROUTER_FLOOD\fR multicast group, which \fBovn\-nortdh\fR populates with all the logical ports that are connected to logical routers with \fBoptions\fR:mcast_relay=\(cqtrue\(cq\[char46] +.IP \(bu +A priority\-85 flow that forwards all IP multicast traffic destined to 224\[char46]0\[char46]0\[char46]X to the \fBMC_FLOOD_L2\fR multicast group, which \fBovn\-northd\fR populates with all non-router logical ports\[char46] +.IP \(bu +A priority\-85 flow that forwards all IP multicast traffic destined to reserved multicast IPv6 addresses (RFC 4291, 2\[char46]7\[char46]1, e\[char46]g\[char46], Solicited-Node multicast) to the \fBMC_FLOOD\fR multicast group, which \fBovn\-northd\fR populates with all enabled logical ports\[char46] +.IP \(bu +A priority\-80 flow that forwards all unregistered IP multicast traffic to the \fBMC_STATIC\fR multicast group, which \fBovn\-northd\fR populates with all the logical ports that have \fBoptions\fR \fB:mcast_flood=\(cqtrue\(cq\fR\[char46] The flow also forwards unregistered IP multicast traffic to the \fBMC_MROUTER_FLOOD\fR multicast group, which \fBovn\-northd\fR populates with all the logical ports connected to logical routers that have \fBoptions\fR \fB:mcast_relay=\(cqtrue\(cq\fR\[char46] +.IP \(bu +A priority\-80 flow that drops all unregistered IP multicast traffic if \fBother_config\fR \fB:mcast_snoop=\(cqtrue\(cq\fR and \fBother_config\fR \fB:mcast_flood_unregistered=\(cqfalse\(cq\fR and the switch is not connected to a logical router that has \fBoptions\fR \fB:mcast_relay=\(cqtrue\(cq\fR and the switch doesn\(cqt have any logical port with \fBoptions\fR \fB:mcast_flood=\(cqtrue\(cq\fR\[char46] +.IP \(bu +Priority\-80 flows for each IP address/VIP/NAT address owned by a router port connected to the switch\[char46] These flows match ARP requests and ND packets for the specific IP addresses\[char46] Matched packets are forwarded only to the router that owns the IP address and to the \fBMC_FLOOD_L2\fR multicast group which contains all non-router logical ports\[char46] +.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] +.IP +For the Ethernet address on a logical switch port of type \fBrouter\fR, when that logical switch port\(cqs \fBaddresses\fR column is set to \fBrouter\fR and the connected logical router port has a gateway chassis: +.RS +.IP \(bu +The flow for the connected logical router port\(cqs Ethernet address is only programmed on the gateway chassis\[char46] +.IP \(bu +If the logical router has rules specified in \fBnat\fR with \fBexternal_mac\fR, then those addresses are also used to populate the switch\(cqs destination lookup on the chassis where \fBlogical_port\fR is resident\[char46] +.RE +.IP +For the Ethernet address on a logical switch port of type \fBrouter\fR, when that logical switch port\(cqs \fBaddresses\fR column is set to \fBrouter\fR and the connected logical router port specifies a \fBreside\-on\-redirect\-chassis\fR and the logical router to which the connected logical router port belongs to has a distributed gateway LRP: +.RS +.IP \(bu +The flow for the connected logical router port\(cqs Ethernet address is only programmed on the gateway chassis\[char46] +.RE +.IP +For each forwarding group configured on the logical switch datapath, a priority\-50 flow that matches on \fBeth\[char46]dst == \fIVIP\fB +\fR with an action of \fBfwd_group(childports=\fIargs +\fB)\fR, where \fIargs\fR contains comma separated logical switch child ports to load balance to\[char46] If \fBliveness\fR is enabled, then action also includes \fB liveness=true\fR\[char46] +.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 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] +.RS +.IP \(bu +Priority 50 flow with the match \fBoutport == \fIP\fB\fR is added for each disabled Logical Switch Port \fBP\fR\[char46] This flow has action \fBdrop;\fR\[char46] +.IP \(bu +If the logical switch has logical ports with \(cqunknown\(cq addresses set, then the below logical flow is added +.RS +.IP \(bu +Priority 50 flow with the match \fBoutport == \(dqnone\(dq\fR then outputs them to the \fBMC_UNKNOWN\fR multicast group, which \fBovn\-northd\fR populates with all enabled logical ports that accept unknown destination packets\[char46] As a small optimization, if no logical ports accept unknown destination packets, \fBovn\-northd\fR omits this multicast group and logical flow\[char46] +.RE +.IP +If the logical switch has no logical ports with \(cqunknown\(cq address set, then the below logical flow is added +.RS +.IP \(bu +Priority 50 flow with the match \fBoutport == none\fR and drops the packets\[char46] +.RE +.IP \(bu +One priority\-0 fallback flow that outputs the packet to the egress stage with the outport learnt from \fBget_fdb\fR action\[char46] +.RE +.ST "Egress Table 0: \fBto\-lport\fI Pre-ACLs" +.PP +.PP +This is similar to ingress table \fBPre\-ACLs\fR except for \fBto\-lport\fR traffic\[char46] +.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\[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 1: Pre-LB" +.PP +.PP +This table is similar to ingress table \fBPre\-LB\fR\[char46] It contains a priority\-0 flow that simply moves traffic to the next table\[char46] Moreover it contains two priority\-110 flows to move multicast, IPv6 Neighbor Discovery and MLD traffic to the next table\[char46] If any load balancing rules exist for the datapath, a priority\-100 flow is added with a match of \fBip\fR and action of \fBreg0[2] = 1; next;\fR to act as a hint for table \fBPre\-stateful\fR 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\[char46] +.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 +This is similar to ingress table \fBPre\-stateful\fR\[char46] This table adds the below 3 logical flows\[char46] +.RS +.IP \(bu +A Priority\-120 flow that send the packets to connection tracker using \fBct_lb_mark;\fR as the action so that the already 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 \fBreg0[2] == 1\fR\[char46] If the packet was not DNATted earlier, then \fBct_lb_mark\fR functions like \fBct_next\fR\[char46] +.IP \(bu +A priority\-100 flow sends the packets to connection tracker based on a hint provided by the previous tables (with a match for \fBreg0[0] == 1\fR) by using the \fBct_next;\fR action\[char46] +.IP \(bu +A priority\-0 flow that matches all packets to advance to the next table\[char46] +.RE +.ST "Egress Table 3: \fBfrom\-lport\fI ACL hints" +.PP +.PP +This is similar to ingress table \fBACL hints\fR\[char46] +.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 +.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] 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] 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] This is indicated by setting the allow bit\[char46] +.RE +.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 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 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 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] +.RS +.IP \(bu +A priority 100 flow which matches on the multicast traffic and applies the action \fBREGBIT_PORT_SEC_DROP\(dq = 0; next;\(dq\fR to skip the out port security checks\[char46] +.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 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] +.PP +.PP +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] +.IP \(bu +A priority\-50 flow that drops the packet if the register bit \fBREGBIT_PORT_SEC_DROP\fR is set to 1\[char46] +.IP \(bu +A priority\-0 flow that outputs the packet to the \fBoutport\fR\[char46] +.RE +.SS "Logical Router Datapaths" +.PP +.PP +Logical router datapaths will only exist for \fBLogical_Router\fR rows in the \fBOVN_Northbound\fR database that do not have \fBenabled\fR set to \fBfalse\fR +.ST "Ingress Table 0: L2 Admission Control" +.PP +.PP +This table drops packets that the router shouldn\(cqt see at all based on their Ethernet headers\[char46] It contains the following flows: +.RS +.IP \(bu +Priority\-100 flows to drop packets with VLAN tags or multicast Ethernet source addresses\[char46] +.IP \(bu +For each enabled router port \fIP\fR with Ethernet address \fIE\fR, a priority\-50 flow that matches \fBinport == +\fIP\fB && (eth\[char46]mcast || eth\[char46]dst == +\fIE\fB\fR), stores the router port ethernet address and advances to next table, with action \fBxreg0[0\[char46]\[char46]47]=E; next;\fR\[char46] +.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 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 +&& eth\[char46]dst == \fIE\fB\fR, where \fIGW\fR is the logical router distributed gateway port corresponding to the NAT rule (specified or inferred), with action \fBxreg0[0\[char46]\[char46]47]=E; next;\fR\[char46] +.IP +This flow is only programmed on the gateway port instance on the chassis where the \fBlogical_port\fR specified in the NAT rule resides\[char46] +.IP \(bu +A priority\-0 logical flow that matches all packets not already handled (match \fB1\fR) and drops them (action \fBdrop;\fR)\[char46] +.RE +.PP +.PP +Other packets are implicitly dropped\[char46] +.ST "Ingress Table 1: Neighbor lookup" +.PP +.PP +For ARP and IPv6 Neighbor Discovery packets, this table looks into the \fBMAC_Binding\fR records to determine if OVN needs to learn the mac bindings\[char46] Following flows are added: +.RS +.IP \(bu +For each router port \fIP\fR that owns IP address \fIA\fR, which belongs to subnet \fIS\fR with prefix length \fIL\fR, if the option \fBalways_learn_from_arp_request\fR is \fBtrue\fR for this router, a priority\-100 flow is added which matches \fBinport == \fIP\fB && arp\[char46]spa == +\fIS\fB/\fIL\fB && arp\[char46]op == 1\fR (ARP request) with the following actions: +.IP +.nf +\fB +.br +\fBreg9[2] = lookup_arp(inport, arp\[char46]spa, arp\[char46]sha); +.br +\fBnext; +.br +\fB \fR +.fi +.IP +If the option \fBalways_learn_from_arp_request\fR is \fBfalse\fR, the following two flows are added\[char46] +.IP +A priority\-110 flow is added which matches \fBinport == +\fIP\fB && arp\[char46]spa == \fIS\fB/\fIL\fB +&& arp\[char46]tpa == \fIA\fB && arp\[char46]op == 1\fR (ARP request) with the following actions: +.IP +.nf +\fB +.br +\fBreg9[2] = lookup_arp(inport, arp\[char46]spa, arp\[char46]sha); +.br +\fBreg9[3] = 1; +.br +\fBnext; +.br +\fB \fR +.fi +.IP +A priority\-100 flow is added which matches \fBinport == +\fIP\fB && arp\[char46]spa == \fIS\fB/\fIL\fB +&& arp\[char46]op == 1\fR (ARP request) with the following actions: +.IP +.nf +\fB +.br +\fBreg9[2] = lookup_arp(inport, arp\[char46]spa, arp\[char46]sha); +.br +\fBreg9[3] = lookup_arp_ip(inport, arp\[char46]spa); +.br +\fBnext; +.br +\fB \fR +.fi +.IP +If the logical router port \fIP\fR is a distributed gateway router port, additional match \fBis_chassis_resident(cr\-\fIP\fB)\fR is added for all these flows\[char46] +.IP \(bu +A priority\-100 flow which matches on ARP reply packets and applies the actions if the option \fBalways_learn_from_arp_request\fR is \fBtrue\fR: +.IP +.nf +\fB +.br +\fBreg9[2] = lookup_arp(inport, arp\[char46]spa, arp\[char46]sha); +.br +\fBnext; +.br +\fB \fR +.fi +.IP +If the option \fBalways_learn_from_arp_request\fR is \fBfalse\fR, the above actions will be: +.IP +.nf +\fB +.br +\fBreg9[2] = lookup_arp(inport, arp\[char46]spa, arp\[char46]sha); +.br +\fBreg9[3] = 1; +.br +\fBnext; +.br +\fB \fR +.fi +.IP \(bu +A priority\-100 flow which matches on IPv6 Neighbor Discovery advertisement packet and applies the actions if the option \fBalways_learn_from_arp_request\fR is \fBtrue\fR: +.IP +.nf +\fB +.br +\fBreg9[2] = lookup_nd(inport, nd\[char46]target, nd\[char46]tll); +.br +\fBnext; +.br +\fB \fR +.fi +.IP +If the option \fBalways_learn_from_arp_request\fR is \fBfalse\fR, the above actions will be: +.IP +.nf +\fB +.br +\fBreg9[2] = lookup_nd(inport, nd\[char46]target, nd\[char46]tll); +.br +\fBreg9[3] = 1; +.br +\fBnext; +.br +\fB \fR +.fi +.IP \(bu +A priority\-100 flow which matches on IPv6 Neighbor Discovery solicitation packet and applies the actions if the option \fBalways_learn_from_arp_request\fR is \fBtrue\fR: +.IP +.nf +\fB +.br +\fBreg9[2] = lookup_nd(inport, ip6\[char46]src, nd\[char46]sll); +.br +\fBnext; +.br +\fB \fR +.fi +.IP +If the option \fBalways_learn_from_arp_request\fR is \fBfalse\fR, the above actions will be: +.IP +.nf +\fB +.br +\fBreg9[2] = lookup_nd(inport, ip6\[char46]src, nd\[char46]sll); +.br +\fBreg9[3] = lookup_nd_ip(inport, ip6\[char46]src); +.br +\fBnext; +.br +\fB \fR +.fi +.IP \(bu +A priority\-0 fallback flow that matches all packets and applies the action \fBreg9[2] = 1; next;\fR advancing the packet to the next table\[char46] +.RE +.ST "Ingress Table 2: Neighbor learning" +.PP +.PP +This table adds flows to learn the mac bindings from the ARP and IPv6 Neighbor Solicitation/Advertisement packets if it is needed according to the lookup results from the previous stage\[char46] +.PP +.PP +reg9[2] will be \fB1\fR if the \fBlookup_arp/lookup_nd\fR in the previous table was successful or skipped, meaning no need to learn mac binding from the packet\[char46] +.PP +.PP +reg9[3] will be \fB1\fR if the \fBlookup_arp_ip/lookup_nd_ip\fR in the previous table was successful or skipped, meaning it is ok to learn mac binding from the packet (if reg9[2] is 0)\[char46] +.RS +.IP \(bu +A priority\-100 flow with the match \fBreg9[2] == 1 || reg9[3] == +0\fR and advances the packet to the next table as there is no need to learn the neighbor\[char46] +.IP \(bu +A priority\-95 flow with the match \fBnd_ns && +(ip6\[char46]src == 0 || nd\[char46]sll == 0)\fR and applies the action \fBnext;\fR +.IP \(bu +A priority\-90 flow with the match \fBarp\fR and applies the action \fBput_arp(inport, arp\[char46]spa, arp\[char46]sha); next;\fR +.IP \(bu +A priority\-95 flow with the match \fBnd_na && +nd\[char46]tll == 0\fR and applies the action \fBput_nd(inport, nd\[char46]target, eth\[char46]src); next;\fR +.IP \(bu +A priority\-90 flow with the match \fBnd_na\fR and applies the action \fBput_nd(inport, nd\[char46]target, nd\[char46]tll); next;\fR +.IP \(bu +A priority\-90 flow with the match \fBnd_ns\fR and applies the action \fBput_nd(inport, ip6\[char46]src, nd\[char46]sll); next;\fR +.IP \(bu +A priority\-0 logical flow that matches all packets not already handled (match \fB1\fR) and drops them (action \fBdrop;\fR)\[char46] +.RE +.ST "Ingress Table 3: IP Input" +.PP +.PP +This table is the core of the logical router datapath functionality\[char46] It contains the following flows to implement very basic IP host functionality\[char46] +.RS +.IP \(bu +For each \fBdnat_and_snat\fR NAT rule on a distributed logical routers or gateway routers with gateway port configured with \fBoptions:gateway_mtu\fR to a valid integer value \fIM\fR, a priority\-160 flow with the match \fBinport == \fILRP\fB && REGBIT_PKT_LARGER +&& REGBIT_EGRESS_LOOPBACK == 0\fR, where \fILRP\fR is the logical router port and applies the following action for ipv4 and ipv6 respectively: +.IP +.nf +\fB +.br +\fBicmp4_error { +.br +\fB icmp4\[char46]type = 3; /* Destination Unreachable\[char46] */ +.br +\fB icmp4\[char46]code = 4; /* Frag Needed and DF was Set\[char46] */ +.br +\fB icmp4\[char46]frag_mtu = \fR\fIM\fB\fR; +.br +\fB eth\[char46]dst = eth\[char46]src; +.br +\fB eth\[char46]src = \fR\fIE\fB\fR; +.br +\fB ip4\[char46]dst = ip4\[char46]src; +.br +\fB ip4\[char46]src = \fR\fII\fB\fR; +.br +\fB ip\[char46]ttl = 255; +.br +\fB REGBIT_EGRESS_LOOPBACK = 1; +.br +\fB REGBIT_PKT_LARGER 0; +.br +\fB outport = \fR\fILRP\fB\fR; +.br +\fB flags\[char46]loopback = 1; +.br +\fB output; +.br +\fB}; +.br +\fB +.br +\fBicmp6_error { +.br +\fB icmp6\[char46]type = 2; +.br +\fB icmp6\[char46]code = 0; +.br +\fB icmp6\[char46]frag_mtu = \fR\fIM\fB\fR; +.br +\fB eth\[char46]dst = eth\[char46]src; +.br +\fB eth\[char46]src = \fR\fIE\fB\fR; +.br +\fB ip6\[char46]dst = ip6\[char46]src; +.br +\fB ip6\[char46]src = \fR\fII\fB\fR; +.br +\fB ip\[char46]ttl = 255; +.br +\fB REGBIT_EGRESS_LOOPBACK = 1; +.br +\fB REGBIT_PKT_LARGER 0; +.br +\fB outport = \fR\fILRP\fB\fR; +.br +\fB flags\[char46]loopback = 1; +.br +\fB output; +.br +\fB}; +.br +\fB \fR +.fi +.IP +where \fIE\fR and \fII\fR are the NAT rule external mac and IP respectively\[char46] +.IP \(bu +For distributed logical routers or gateway routers with gateway port configured with \fBoptions:gateway_mtu\fR to a valid integer value, a priority\-150 flow with the match \fBinport == +\fILRP\fB && REGBIT_PKT_LARGER && +REGBIT_EGRESS_LOOPBACK == 0\fR, where \fILRP\fR is the logical router port and applies the following action for ipv4 and ipv6 respectively: +.IP +.nf +\fB +.br +\fBicmp4_error { +.br +\fB icmp4\[char46]type = 3; /* Destination Unreachable\[char46] */ +.br +\fB icmp4\[char46]code = 4; /* Frag Needed and DF was Set\[char46] */ +.br +\fB icmp4\[char46]frag_mtu = \fR\fIM\fB\fR; +.br +\fB eth\[char46]dst = \fR\fIE\fB\fR; +.br +\fB ip4\[char46]dst = ip4\[char46]src; +.br +\fB ip4\[char46]src = \fR\fII\fB\fR; +.br +\fB ip\[char46]ttl = 255; +.br +\fB REGBIT_EGRESS_LOOPBACK = 1; +.br +\fB REGBIT_PKT_LARGER 0; +.br +\fB next(pipeline=ingress, table=0); +.br +\fB}; +.br +\fB +.br +\fBicmp6_error { +.br +\fB icmp6\[char46]type = 2; +.br +\fB icmp6\[char46]code = 0; +.br +\fB icmp6\[char46]frag_mtu = \fR\fIM\fB\fR; +.br +\fB eth\[char46]dst = \fR\fIE\fB\fR; +.br +\fB ip6\[char46]dst = ip6\[char46]src; +.br +\fB ip6\[char46]src = \fR\fII\fB\fR; +.br +\fB ip\[char46]ttl = 255; +.br +\fB REGBIT_EGRESS_LOOPBACK = 1; +.br +\fB REGBIT_PKT_LARGER 0; +.br +\fB next(pipeline=ingress, table=0); +.br +\fB}; +.br +\fB \fR +.fi +.IP \(bu +For each NAT entry of a distributed logical router (with distributed gateway router port(s)) of type \fBsnat\fR, a priority\-120 flow with the match \fBinport == \fIP\fB +&& ip4\[char46]src == \fIA\fB\fR advances the packet to the next pipeline, where \fIP\fR is the distributed logical router port corresponding to the NAT entry (specified or inferred) and \fIA\fR is the \fBexternal_ip\fR set in the NAT entry\[char46] If \fIA\fR is an IPv6 address, then \fBip6\[char46]src\fR is used for the match\[char46] +.IP +The above flow is required to handle the routing of the East/west NAT traffic\[char46] +.IP \(bu +For each BFD port the two following priority\-110 flows are added to manage BFD traffic: +.RS +.IP \(bu +if \fBip4\[char46]src\fR or \fBip6\[char46]src\fR is any IP address owned by the router port and \fBudp\[char46]dst == 3784 +\fR, the packet is advanced to the next pipeline stage\[char46] +.IP \(bu +if \fBip4\[char46]dst\fR or \fBip6\[char46]dst\fR is any IP address owned by the router port and \fBudp\[char46]dst == 3784 +\fR, the \fBhandle_bfd_msg\fR action is executed\[char46] +.RE +.IP \(bu +L3 admission control: Priority\-120 flows allows IGMP and MLD packets if the router has logical ports that have \fBoptions\fR \fB:mcast_flood=\(cqtrue\(cq\fR\[char46] +.IP \(bu +L3 admission control: A priority\-100 flow drops packets that match any of the following: +.RS +.IP \(bu +\fBip4\[char46]src[28\[char46]\[char46]31] == 0xe\fR (multicast source) +.IP \(bu +\fBip4\[char46]src == 255\[char46]255\[char46]255\[char46]255\fR (broadcast source) +.IP \(bu +\fBip4\[char46]src == 127\[char46]0\[char46]0\[char46]0/8 || ip4\[char46]dst == 127\[char46]0\[char46]0\[char46]0/8\fR (localhost source or destination) +.IP \(bu +\fBip4\[char46]src == 0\[char46]0\[char46]0\[char46]0/8 || ip4\[char46]dst == 0\[char46]0\[char46]0\[char46]0/8\fR (zero network source or destination) +.IP \(bu +\fBip4\[char46]src\fR or \fBip6\[char46]src\fR is any IP address owned by the router, unless the packet was recirculated due to egress loopback as indicated by \fBREGBIT_EGRESS_LOOPBACK\fR\[char46] +.IP \(bu +\fBip4\[char46]src\fR is the broadcast address of any IP network known to the router\[char46] +.RE +.IP \(bu +A priority\-100 flow parses DHCPv6 replies from IPv6 prefix delegation routers (\fBudp\[char46]src == 547 && +udp\[char46]dst == 546\fR)\[char46] The \fBhandle_dhcpv6_reply\fR is used to send IPv6 prefix delegation messages to the delegation router\[char46] +.IP \(bu +ICMP echo reply\[char46] These flows reply to ICMP echo requests received for the router\(cqs IP address\[char46] Let \fIA\fR be an IP address owned by a router port\[char46] Then, for each \fIA\fR that is an IPv4 address, a priority\-90 flow matches on \fBip4\[char46]dst == \fIA\fB\fR and \fBicmp4\[char46]type == 8 && icmp4\[char46]code == 0\fR (ICMP echo request)\[char46] For each \fIA\fR that is an IPv6 address, a priority\-90 flow matches on \fBip6\[char46]dst == \fIA\fB\fR and \fBicmp6\[char46]type == 128 && icmp6\[char46]code == 0\fR (ICMPv6 echo request)\[char46] The port of the router that receives the echo request does not matter\[char46] Also, the \fBip\[char46]ttl\fR of the echo request packet is not checked, so it complies with RFC 1812, section 4\[char46]2\[char46]2\[char46]9\[char46] Flows for ICMPv4 echo requests use the following actions: +.IP +.nf +\fB +.br +\fBip4\[char46]dst <\-> ip4\[char46]src; +.br +\fBip\[char46]ttl = 255; +.br +\fBicmp4\[char46]type = 0; +.br +\fBflags\[char46]loopback = 1; +.br +\fBnext; +.br +\fB \fR +.fi +.IP +Flows for ICMPv6 echo requests use the following actions: +.IP +.nf +\fB +.br +\fBip6\[char46]dst <\-> ip6\[char46]src; +.br +\fBip\[char46]ttl = 255; +.br +\fBicmp6\[char46]type = 129; +.br +\fBflags\[char46]loopback = 1; +.br +\fBnext; +.br +\fB \fR +.fi +.IP \(bu +Reply to ARP requests\[char46] +.IP +These flows reply to ARP requests for the router\(cqs own IP address\[char46] The ARP requests are handled only if the requestor\(cqs IP belongs to the same subnets of the logical router port\[char46] For each router port \fIP\fR that owns IP address \fIA\fR, which belongs to subnet \fIS\fR with prefix length \fIL\fR, and Ethernet address \fIE\fR, a priority\-90 flow matches \fBinport == \fIP\fB && +arp\[char46]spa == \fIS\fB/\fIL\fB && arp\[char46]op == 1 +&& arp\[char46]tpa == \fIA\fB\fR (ARP request) with the following actions: +.IP +.nf +\fB +.br +\fBeth\[char46]dst = eth\[char46]src; +.br +\fBeth\[char46]src = xreg0[0\[char46]\[char46]47]; +.br +\fBarp\[char46]op = 2; /* ARP reply\[char46] */ +.br +\fBarp\[char46]tha = arp\[char46]sha; +.br +\fBarp\[char46]sha = xreg0[0\[char46]\[char46]47]; +.br +\fBarp\[char46]tpa = arp\[char46]spa; +.br +\fBarp\[char46]spa = \fR\fIA\fB\fR; +.br +\fBoutport = inport; +.br +\fBflags\[char46]loopback = 1; +.br +\fBoutput; +.br +\fB \fR +.fi +.IP +For the gateway port on a distributed logical router (where one of the logical router ports specifies a gateway chassis), the above flows are only programmed on the gateway port instance on the gateway chassis\[char46] This behavior avoids generation of multiple ARP responses from different chassis, and allows upstream MAC learning to point to the gateway chassis\[char46] +.IP +For the logical router port with the option \fBreside\-on\-redirect\-chassis\fR 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 distributed gateway port)\[char46] This behavior avoids generation of multiple ARP responses from different chassis, and allows upstream MAC learning to point to the gateway chassis\[char46] +.IP \(bu +Reply to IPv6 Neighbor Solicitations\[char46] These flows reply to Neighbor Solicitation requests for the router\(cqs own IPv6 address and populate the logical router\(cqs mac binding table\[char46] +.IP +For each router port \fIP\fR that owns IPv6 address \fIA\fR, solicited node address \fIS\fR, and Ethernet address \fIE\fR, a priority\-90 flow matches \fBinport == \fIP\fB && +nd_ns && ip6\[char46]dst == {\fIA\fB, \fIE\fB} && +nd\[char46]target == \fIA\fB\fR with the following actions: +.IP +.nf +\fB +.br +\fBnd_na_router { +.br +\fB eth\[char46]src = xreg0[0\[char46]\[char46]47]; +.br +\fB ip6\[char46]src = \fR\fIA\fB\fR; +.br +\fB nd\[char46]target = \fR\fIA\fB\fR; +.br +\fB nd\[char46]tll = xreg0[0\[char46]\[char46]47]; +.br +\fB outport = inport; +.br +\fB flags\[char46]loopback = 1; +.br +\fB output; +.br +\fB}; +.br +\fB \fR +.fi +.IP +For the gateway port on a distributed logical router (where one of the logical router ports specifies a gateway chassis), the above flows replying to IPv6 Neighbor Solicitations are only programmed on the gateway port instance on the gateway chassis\[char46] This behavior avoids generation of multiple replies from different chassis, and allows upstream MAC learning to point to the gateway chassis\[char46] +.IP \(bu +These flows reply to ARP requests or IPv6 neighbor solicitation for the virtual IP addresses configured in the router for NAT (both DNAT and SNAT) or load balancing\[char46] +.IP +IPv4: For a configured NAT (both DNAT and SNAT) IP address or a load balancer IPv4 VIP \fIA\fR, for each router port \fIP\fR with Ethernet address \fIE\fR, a priority\-90 flow matches \fBarp\[char46]op == 1 && arp\[char46]tpa == \fIA\fB\fR (ARP request) with the following actions: +.IP +.nf +\fB +.br +\fBeth\[char46]dst = eth\[char46]src; +.br +\fBeth\[char46]src = xreg0[0\[char46]\[char46]47]; +.br +\fBarp\[char46]op = 2; /* ARP reply\[char46] */ +.br +\fBarp\[char46]tha = arp\[char46]sha; +.br +\fBarp\[char46]sha = xreg0[0\[char46]\[char46]47]; +.br +\fBarp\[char46]tpa <\-> arp\[char46]spa; +.br +\fBoutport = inport; +.br +\fBflags\[char46]loopback = 1; +.br +\fBoutput; +.br +\fB \fR +.fi +.IP +IPv4: For a configured load balancer IPv4 VIP, a similar flow is added with the additional match \fBinport == \fIP\fB\fR if the VIP is reachable from any logical router port of the logical router\[char46] +.IP +If the router port \fIP\fR is a distributed gateway router port, then the \fBis_chassis_resident(\fIP\fB)\fR is also added in the match condition for the load balancer IPv4 VIP \fIA\fR\[char46] +.IP +IPv6: For a configured NAT (both DNAT and SNAT) IP address or a load balancer IPv6 VIP \fIA\fR (if the VIP is reachable from any logical router port of the logical router), solicited node address \fIS\fR, for each router port \fIP\fR with Ethernet address \fIE\fR, a priority\-90 flow matches \fBinport == \fIP\fB && nd_ns && +ip6\[char46]dst == {\fIA\fB, \fIS\fB} && +nd\[char46]target == \fIA\fB\fR with the following actions: +.IP +.nf +\fB +.br +\fBeth\[char46]dst = eth\[char46]src; +.br +\fBnd_na { +.br +\fB eth\[char46]src = xreg0[0\[char46]\[char46]47]; +.br +\fB nd\[char46]tll = xreg0[0\[char46]\[char46]47]; +.br +\fB ip6\[char46]src = \fR\fIA\fB\fR; +.br +\fB nd\[char46]target = \fR\fIA\fB\fR; +.br +\fB outport = inport; +.br +\fB flags\[char46]loopback = 1; +.br +\fB output; +.br +\fB} +.br +\fB \fR +.fi +.IP +If the router port \fIP\fR is a distributed gateway router port, then the \fBis_chassis_resident(\fIP\fB)\fR is also added in the match condition for the load balancer IPv6 VIP \fIA\fR\[char46] +.IP +For the gateway port on a distributed logical router with NAT (where one of the logical router ports specifies a gateway chassis): +.RS +.IP \(bu +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\[char46] A priority\-91 drop flow is programmed on the other chassis when ARP requests/NS packets are received on the gateway port\[char46] This behavior avoids generation of multiple ARP responses from different chassis, and allows upstream MAC learning to point to the gateway chassis\[char46] +.IP \(bu +If the corresponding NAT rule can be handled in a distributed manner, then this flow is only programmed on the gateway port instance where the \fBlogical_port\fR specified in the NAT rule resides\[char46] +.IP +Some of the actions are different for this case, using the \fBexternal_mac\fR specified in the NAT rule rather than the gateway port\(cqs Ethernet address \fIE\fR: +.IP +.nf +\fB +.br +\fBeth\[char46]src = \fR\fIexternal_mac\fB\fR; +.br +\fBarp\[char46]sha = \fR\fIexternal_mac\fB\fR; +.br +\fB \fR +.fi +.IP +or in the case of IPv6 neighbor solicition: +.IP +.nf +\fB +.br +\fBeth\[char46]src = \fR\fIexternal_mac\fB\fR; +.br +\fBnd\[char46]tll = \fR\fIexternal_mac\fB\fR; +.br +\fB \fR +.fi +.IP +This behavior avoids generation of multiple ARP responses from different chassis, and allows upstream MAC learning to point to the correct chassis\[char46] +.RE +.IP \(bu +Priority\-85 flows which drops the ARP and IPv6 Neighbor Discovery packets\[char46] +.IP \(bu +A priority\-84 flow explicitly allows IPv6 multicast traffic that is supposed to reach the router pipeline (i\[char46]e\[char46], router solicitation and router advertisement packets)\[char46] +.IP \(bu +A priority\-83 flow explicitly drops IPv6 multicast traffic that is destined to reserved multicast groups\[char46] +.IP \(bu +A priority\-82 flow allows IP multicast traffic if \fBoptions\fR:mcast_relay=\(cqtrue\(cq, otherwise drops it\[char46] +.IP \(bu +UDP port unreachable\[char46] Priority\-80 flows generate ICMP port unreachable messages in reply to UDP datagrams directed to the router\(cqs IP address, except in the special case of gateways, which accept traffic directed to a router IP for load balancing and NAT purposes\[char46] +.IP +These flows should not match IP fragments with nonzero offset\[char46] +.IP \(bu +TCP reset\[char46] Priority\-80 flows generate TCP reset messages in reply to TCP datagrams directed to the router\(cqs IP address, except in the special case of gateways, which accept traffic directed to a router IP for load balancing and NAT purposes\[char46] +.IP +These flows should not match IP fragments with nonzero offset\[char46] +.IP \(bu +Protocol or address unreachable\[char46] Priority\-70 flows generate ICMP protocol or address unreachable messages for IPv4 and IPv6 respectively in reply to packets directed to the router\(cqs IP address on IP protocols other than UDP, TCP, and ICMP, except in the special case of gateways, which accept traffic directed to a router IP for load balancing purposes\[char46] +.IP +These flows should not match IP fragments with nonzero offset\[char46] +.IP \(bu +Drop other IP traffic to this router\[char46] 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\[char46] For each IP address \fIA\fR owned by the router, a priority\-60 flow matches \fBip4\[char46]dst == \fIA\fB\fR or \fBip6\[char46]dst == \fIA\fB\fR and drops the traffic\[char46] An exception is made and the above flow is not added if the router port\(cqs own IP address is used to SNAT packets passing through that router or if it is used as a load balancer VIP\[char46] +.RE +.PP +.PP +The flows above handle all of the traffic that might be directed to the router itself\[char46] The following flows (with lower priorities) handle the remaining traffic, potentially for forwarding: +.RS +.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 +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 +.nf +\fB +.br +\fBicmp4 { +.br +\fB icmp4\[char46]type = 11; /* Time exceeded\[char46] */ +.br +\fB icmp4\[char46]code = 0; /* TTL exceeded in transit\[char46] */ +.br +\fB ip4\[char46]dst = ip4\[char46]src; +.br +\fB ip4\[char46]src = \fR\fIA\fB\fR; +.br +\fB ip\[char46]ttl = 254; +.br +\fB next; +.br +\fB}; +.br +\fB +.br +\fBicmp6 { +.br +\fB icmp6\[char46]type = 3; /* Time exceeded\[char46] */ +.br +\fB icmp6\[char46]code = 0; /* TTL exceeded in transit\[char46] */ +.br +\fB ip6\[char46]dst = ip6\[char46]src; +.br +\fB ip6\[char46]src = \fR\fIA\fB\fR; +.br +\fB ip\[char46]ttl = 254; +.br +\fB next; +.br +\fB}; +.br +\fB \fR +.fi +.IP \(bu +TTL discard\[char46] A priority\-30 flow with match \fBip\[char46]ttl == {0, +1}\fR and actions \fBdrop;\fR drops other packets whose TTL has expired, that should not receive a ICMP error reply (i\[char46]e\[char46] fragments with nonzero offset)\[char46] +.IP \(bu +Next table\[char46] A priority\-0 flows match all packets that aren\(cqt already handled and uses actions \fBnext;\fR to feed them to the next table\[char46] +.RE +.ST "Ingress Table 4: UNSNAT" +.PP +.PP +This is for already established connections\(cq reverse traffic\[char46] i\[char46]e\[char46], SNAT has already been done in egress pipeline and now the packet has entered the ingress pipeline as part of a reply\[char46] It is unSNATted here\[char46] +.PP +.PP +Ingress Table 4: UNSNAT on Gateway and Distributed Routers +.RS +.IP \(bu +If the Router (Gateway or Distributed) is configured with load balancers, then below lflows are added: +.IP +For each IPv4 address \fIA\fR defined as load balancer VIP with the protocol \fIP\fR (and the protocol port \fIT\fR if defined) is also present as an \fBexternal_ip\fR in the NAT table, a priority\-120 logical flow is added with the match \fBip4 && ip4\[char46]dst == \fIA\fB && +\fIP\fB\fR with the action \fBnext;\fR to advance the packet to the next table\[char46] If the load balancer has protocol port \fBB\fR defined, then the match also has \fB\fIP\fB\[char46]dst == \fIB\fB\fR\[char46] +.IP +The above flows are also added for IPv6 load balancers\[char46] +.RE +.PP +.PP +Ingress Table 4: UNSNAT on Gateway Routers +.RS +.IP \(bu +If the Gateway router has been configured to force SNAT any previously DNATted packets to \fIB\fR, a priority\-110 flow matches \fBip && ip4\[char46]dst == \fIB\fB\fR or \fBip && ip6\[char46]dst == \fIB\fB\fR with an action \fBct_snat; \fR\[char46] +.IP +If the Gateway router is configured with \fBlb_force_snat_ip=router_ip\fR then for every logical router port \fIP\fR attached to the Gateway router with the router ip \fIB\fR, a priority\-110 flow is added with the match \fBinport == \fIP\fB && +ip4\[char46]dst == \fIB\fB\fR or \fBinport == \fIP\fB +&& ip6\[char46]dst == \fIB\fB\fR with an action \fBct_snat; \fR\[char46] +.IP +If the Gateway router has been configured to force SNAT any previously load-balanced packets to \fIB\fR, a priority\-100 flow matches \fBip && ip4\[char46]dst == \fIB\fB\fR or \fBip && ip6\[char46]dst == \fIB\fB\fR with an action \fBct_snat; \fR\[char46] +.IP +For each NAT configuration in the OVN Northbound database, that asks to change the source IP address of a packet from \fIA\fR to \fIB\fR, a priority\-90 flow matches \fBip && ip4\[char46]dst == \fIB\fB\fR or \fBip && ip6\[char46]dst == \fIB\fB\fR with an action \fBct_snat; \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 +A priority\-0 logical flow with match \fB1\fR has actions \fBnext;\fR\[char46] +.RE +.PP +.PP +Ingress Table 4: UNSNAT on Distributed Routers +.RS +.IP \(bu +For each configuration in the OVN Northbound database, that asks to change the source IP address of a packet from \fIA\fR to \fIB\fR, two priority\-100 flows are added\[char46] +.IP +If the NAT rule cannot be handled in a distributed manner, then the below priority\-100 flows are only programmed on the gateway chassis\[char46] +.RS +.IP \(bu +The first flow matches \fBip && +ip4\[char46]dst == \fIB\fB && inport == \fIGW\fB +\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] +.RE +.IP +A priority\-0 logical flow with match \fB1\fR has actions \fBnext;\fR\[char46] +.RE +.ST "Ingress Table 5: DEFRAG" +.PP +.PP +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 +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] +.PP +.PP +If load balancing rules are configured in \fBOVN_Northbound\fR database for a Gateway router, a priority 50 flow that matches \fBicmp || icmp6\fR with an action of \fBct_dnat;\fR, this allows potentially related ICMP traffic to pass through CT\[char46] +.ST "Ingress Table 6: Load balancing affinity check" +.PP +.PP +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 && +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 \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 +.ST "Ingress Table 7: DNAT" +.PP +.PP +Packets enter the pipeline with destination IP address that needs to be DNATted from a virtual IP address to a real IP address\[char46] Packets in the reverse direction needs to be unDNATed\[char46] +.PP +.PP +Ingress Table 7: Load balancing DNAT rules +.PP +.PP +Following load balancing DNAT flows are added for Gateway router or Router with gateway port\[char46] These flows are programmed only on the gateway chassis\[char46] These flows do not get programmed for load balancers with IPv6 \fIVIPs\fR\[char46] +.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 && 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 && 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 && 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, 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 +Ingress Table 7: DNAT on Gateway Routers +.RS +.IP \(bu +For each configuration in the OVN Northbound database, that asks to change the destination IP address of a packet from \fIA\fR to \fIB\fR, a priority\-100 flow matches \fBip && +ip4\[char46]dst == \fIA\fB\fR or \fBip && +ip6\[char46]dst == \fIA\fB\fR with an action \fBflags\[char46]loopback = 1; ct_dnat(\fIB\fB);\fR\[char46] If the Gateway router is configured to force SNAT any DNATed packet, the above action will be replaced by \fBflags\[char46]force_snat_for_dnat = 1; flags\[char46]loopback = 1; +ct_dnat(\fIB\fB);\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 \fBip4/6\[char46]dst= +(\fIB\fB)\fR\[char46] +.IP +If the NAT rule has \fBallowed_ext_ips\fR configured, then there is an additional match \fBip4\[char46]src == \fIallowed_ext_ips +\fB\fR\[char46] Similarly, for IPV6, match would be \fBip6\[char46]src == +\fIallowed_ext_ips\fB\fR\[char46] +.IP +If the NAT rule has \fBexempted_ext_ips\fR set, then there is an additional flow configured at priority 101\[char46] The flow matches if source ip is an \fBexempted_ext_ip\fR and the action is \fBnext; \fR\[char46] This flow is used to bypass the ct_dnat action for a packet originating from \fBexempted_ext_ips\fR\[char46] +.IP \(bu +A priority\-0 logical flow with match \fB1\fR has actions \fBnext;\fR\[char46] +.RE +.PP +.PP +Ingress Table 7: DNAT on Distributed Routers +.PP +.PP +On distributed routers, the DNAT table only handles packets with destination IP address that needs to be DNATted from a virtual IP address to a real IP address\[char46] The unDNAT processing in the reverse direction is handled in a separate table in the egress pipeline\[char46] +.RS +.IP \(bu +For each configuration in the OVN Northbound database, that asks to change the destination IP address of a packet from \fIA\fR to \fIB\fR, a priority\-100 flow matches \fBip && +ip4\[char46]dst == \fIB\fB && inport == \fIGW\fB\fR, where \fIGW\fR is the logical router gateway port corresponding to the NAT rule (specified or inferred), with an action \fBct_dnat(\fIB\fB);\fR\[char46] The match will include \fBip6\[char46]dst == \fIB\fB\fR in the IPv6 case\[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] +.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\[char46] +.IP +If the NAT rule has \fBallowed_ext_ips\fR configured, then there is an additional match \fBip4\[char46]src == \fIallowed_ext_ips +\fB\fR\[char46] Similarly, for IPV6, match would be \fBip6\[char46]src == +\fIallowed_ext_ips\fB\fR\[char46] +.IP +If the NAT rule has \fBexempted_ext_ips\fR set, then there is an additional flow configured at priority 101\[char46] The flow matches if source ip is an \fBexempted_ext_ip\fR and the action is \fBnext; \fR\[char46] This flow is used to bypass the ct_dnat action for a packet originating from \fBexempted_ext_ips\fR\[char46] +.IP +A priority\-0 logical flow with match \fB1\fR has actions \fBnext;\fR\[char46] +.RE +.ST "Ingress Table 8: Load balancing affinity learn" +.PP +.PP +Load balancing affinity learn 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 \fIT\fR 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 \fBreg9[6] == 0 && 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 \fBcommit_lb_aff(vip = \fIVIP\fB:\fIPORT\fB, backend = +\fIbackend ip\fB: \fIbackend port\fB, proto = \fIP\fB, +timeout = \fIT\fB);\fR\[char46] +.IP \(bu +A priority 0 flow is added which matches on all packets and applies the action \fBnext;\fR\[char46] +.RE +.ST "Ingress Table 9: ECMP symmetric reply processing" +.RS +.IP \(bu +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 action \fBct_commit { ct_label\[char46]ecmp_reply_eth = eth\[char46]src;\(dq +\(dq ct_mark\[char46]ecmp_reply_port = \fIK\fB;}; commit_ecmp_nh(); next; +\fR to commit the connection and storing \fBeth\[char46]src\fR and the ECMP reply port binding tunnel key \fIK\fR in the \fBct_label\fR and the traffic pattern to table \fB76\fR or \fB77\fR\[char46] +.RE +.ST "Ingress Table 10: IPv6 ND RA option processing" +.RS +.IP \(bu +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 \fBput_nd_ra_opts\fR and advances the packet to the next table\[char46] +.IP +.nf +\fB +.br +\fBreg0[5] = put_nd_ra_opts(\fR\fIoptions\fB\fR);next; +.br +\fB \fR +.fi +.IP +For a valid IPv6 ND RS packet, this transforms the packet into an IPv6 ND RA reply and sets the RA options to the packet and stores 1 into reg0[5]\[char46] For other kinds of packets, it just stores 0 into reg0[5]\[char46] Either way, it continues to the next table\[char46] +.IP \(bu +A priority\-0 logical flow with match \fB1\fR has actions \fBnext;\fR\[char46] +.RE +.ST "Ingress Table 11: IPv6 ND RA responder" +.PP +.PP +This table implements IPv6 ND RA responder for the IPv6 ND RA replies generated by the previous table\[char46] +.RS +.IP \(bu +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 \fBreg0[5] == 1\fR and responds back to the \fBinport\fR after applying these actions\[char46] If \fBreg0[5]\fR is set to 1, it means that the action \fBput_nd_ra_opts\fR was successful\[char46] +.IP +.nf +\fB +.br +\fBeth\[char46]dst = eth\[char46]src; +.br +\fBeth\[char46]src = \fR\fIE\fB\fR; +.br +\fBip6\[char46]dst = ip6\[char46]src; +.br +\fBip6\[char46]src = \fR\fII\fB\fR; +.br +\fBoutport = \fR\fIP\fB\fR; +.br +\fBflags\[char46]loopback = 1; +.br +\fBoutput; +.br +\fB \fR +.fi +.IP +where \fIE\fR is the MAC address and \fII\fR is the IPv6 link local address of the logical router port\[char46] +.IP +(This terminates packet processing in ingress pipeline; the packet does not go to the next ingress table\[char46]) +.IP \(bu +A priority\-0 logical flow with match \fB1\fR has actions \fBnext;\fR\[char46] +.RE +.ST "Ingress Table 12: IP Routing Pre" +.PP +.PP +If a packet arrived at this table from Logical Router Port \fIP\fR which has \fBoptions:route_table\fR value set, a logical flow with match \fBinport == \(dq\fIP\fB\(dq\fR with priority 100 and action setting unique-generated per-datapath 32-bit value (non-zero) in OVS register 7\[char46] This register\(cqs value is checked in next table\[char46] If packet didn\(cqt match any configured inport (\fI
\fR route table), register 7 value is set to 0\[char46] +.PP +.PP +This table contains the following logical flows: +.RS +.IP \(bu +Priority\-100 flow with match \fBinport == \(dqLRP_NAME\(dq\fR value and action, which set route table identifier in reg7\[char46] +.IP +A priority\-0 logical flow with match \fB1\fR has actions \fBreg7 = 0; next;\fR\[char46] +.RE +.ST "Ingress Table 13: IP Routing" +.PP +.PP +A packet that arrives at this table is an IP packet that should be routed to the address in \fBip4\[char46]dst\fR or \fBip6\[char46]dst\fR\[char46] This table implements IP routing, setting \fBreg0\fR (or \fBxxreg0\fR for IPv6) to the next-hop IP address (leaving \fBip4\[char46]dst\fR or \fBip6\[char46]dst\fR, the packet\(cqs final destination, unchanged) and advances to the next table for ARP resolution\[char46] It also sets \fBreg1\fR (or \fBxxreg1\fR) to the IP address owned by the selected router port (ingress table \fBARP Request\fR will generate an ARP request, if needed, with \fBreg0\fR as the target protocol address and \fBreg1\fR as the source protocol address)\[char46] +.PP +.PP +For ECMP routes, i\[char46]e\[char46] multiple static routes with same policy and prefix but different nexthops, the above actions are deferred to next table\[char46] This table, instead, is responsible for determine the ECMP group id and select a member id within the group based on 5-tuple hashing\[char46] It stores group id in \fBreg8[0\[char46]\[char46]15]\fR and member id in \fBreg8[16\[char46]\[char46]31]\fR\[char46] 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 symmetric replies\[char46] Instead, the stored values in conntrack is used to choose the destination\[char46] The \fBct_label\[char46]ecmp_reply_eth\fR tells the destination MAC address to which the packet should be sent\[char46] The \fBct_mark\[char46]ecmp_reply_port\fR tells the logical router port on which the packet should be sent\[char46] These values saved to the conntrack fields when the initial ingress traffic is received over the ECMP route and committed to conntrack\[char46] If \fBREGBIT_KNOWN_ECMP_NH\fR is set, the priority\-10300 flows in this stage set the \fBoutport\fR, while the \fBeth\[char46]dst\fR is set by flows at the ARP/ND Resolution stage\[char46] +.PP +.PP +This table contains the following logical flows: +.RS +.IP \(bu +Priority\-10550 flow that drops IPv6 Router Solicitation/Advertisement packets that were not processed in previous tables\[char46] +.IP \(bu +Priority\-10550 flows that drop IGMP and MLD packets with source MAC address owned by the router\[char46] These are used to prevent looping statically forwarded IGMP and MLD packets for which TTL is not decremented (it is always 1)\[char46] +.IP \(bu +Priority\-10500 flows that match IP multicast traffic destined to groups registered on any of the attached switches and sets \fBoutport\fR to the associated multicast group that will eventually flood the traffic to all interested attached logical switches\[char46] The flows also decrement TTL\[char46] +.IP \(bu +Priority\-10460 flows that match IGMP and MLD control packets, set \fBoutport\fR to the \fBMC_STATIC\fR multicast group, which \fBovn\-northd\fR populates with the logical ports that have \fBoptions\fR \fB:mcast_flood=\(cqtrue\(cq\fR\[char46] If no router ports are configured to flood multicast traffic the packets are dropped\[char46] +.IP \(bu +Priority\-10450 flow that matches unregistered IP multicast traffic decrements TTL and sets \fBoutport\fR to the \fBMC_STATIC\fR multicast group, which \fBovn\-northd\fR populates with the logical ports that have \fBoptions\fR \fB:mcast_flood=\(cqtrue\(cq\fR\[char46] If no router ports are configured to flood multicast traffic the packets are dropped\[char46] +.IP \(bu +IPv4 routing table\[char46] For each route to IPv4 network \fIN\fR with netmask \fIM\fR, on router port \fIP\fR with IP address \fIA\fR and Ethernet address \fIE\fR, a logical flow with match \fBip4\[char46]dst == +\fIN\fB/\fIM\fB\fR, whose priority is the number of 1-bits in \fIM\fR, has the following actions: +.IP +.nf +\fB +.br +\fBip\[char46]ttl\-\-; +.br +\fBreg8[0\[char46]\[char46]15] = 0; +.br +\fBreg0 = \fR\fIG\fB\fR; +.br +\fBreg1 = \fR\fIA\fB\fR; +.br +\fBeth\[char46]src = \fR\fIE\fB\fR; +.br +\fBoutport = \fR\fIP\fB\fR; +.br +\fBflags\[char46]loopback = 1; +.br +\fBnext; +.br +\fB \fR +.fi +.IP +(Ingress table 1 already verified that \fBip\[char46]ttl\-\-;\fR will not yield a TTL exceeded error\[char46]) +.IP +If the route has a gateway, \fIG\fR is the gateway IP address\[char46] Instead, if the route is from a configured static route, \fIG\fR is the next hop IP address\[char46] Else it is \fBip4\[char46]dst\fR\[char46] +.IP \(bu +IPv6 routing table\[char46] For each route to IPv6 network \fIN\fR with netmask \fIM\fR, on router port \fIP\fR with IP address \fIA\fR and Ethernet address \fIE\fR, a logical flow with match in CIDR notation \fBip6\[char46]dst == \fIN\fB/\fIM\fB\fR, whose priority is the integer value of \fIM\fR, has the following actions: +.IP +.nf +\fB +.br +\fBip\[char46]ttl\-\-; +.br +\fBreg8[0\[char46]\[char46]15] = 0; +.br +\fBxxreg0 = \fR\fIG\fB\fR; +.br +\fBxxreg1 = \fR\fIA\fB\fR; +.br +\fBeth\[char46]src = \fR\fIE\fB\fR; +.br +\fBoutport = inport; +.br +\fBflags\[char46]loopback = 1; +.br +\fBnext; +.br +\fB \fR +.fi +.IP +(Ingress table 1 already verified that \fBip\[char46]ttl\-\-;\fR will not yield a TTL exceeded error\[char46]) +.IP +If the route has a gateway, \fIG\fR is the gateway IP address\[char46] Instead, if the route is from a configured static route, \fIG\fR is the next hop IP address\[char46] Else it is \fBip6\[char46]dst\fR\[char46] +.IP +If the address \fIA\fR is in the link-local scope, the route will be limited to sending on the ingress port\[char46] +.IP +For each static route the \fBreg7 == id &&\fR is prefixed in logical flow match portion\[char46] For routes with \fBroute_table\fR value set a unique non-zero id is used\[char46] For routes within \fB
\fR route table (no route table set), this id value is 0\[char46] +.IP +For each \fIconnected\fR route (route to the LRP\(cqs subnet CIDR) the logical flow match portion has no \fBreg7 == id &&\fR prefix to have route to LRP\(cqs subnets in all routing tables\[char46] +.IP \(bu +For ECMP routes, they are grouped by policy and prefix\[char46] An unique id (non-zero) is assigned to each group, and each member is also assigned an unique id (non-zero) within each group\[char46] +.IP +For each IPv4/IPv6 ECMP group with group id \fIGID\fR and member ids \fIMID1\fR, \fIMID2\fR, \[char46]\[char46]\[char46], a logical flow with match in CIDR notation \fBip4\[char46]dst == \fIN\fB/\fIM\fB\fR, or \fBip6\[char46]dst == \fIN\fB/\fIM\fB\fR, whose priority is the integer value of \fIM\fR, has the following actions: +.IP +.nf +\fB +.br +\fBip\[char46]ttl\-\-; +.br +\fBflags\[char46]loopback = 1; +.br +\fBreg8[0\[char46]\[char46]15] = \fR\fIGID\fB\fR; +.br +\fBselect(reg8[16\[char46]\[char46]31], \fR\fIMID1\fB\fR, \fR\fIMID2\fB\fR, \[char46]\[char46]\[char46]); +.br +\fB \fR +.fi +.IP \(bu +A priority\-0 logical flow that matches all packets not already handled (match \fB1\fR) and drops them (action \fBdrop;\fR)\[char46] +.RE +.ST "Ingress Table 14: IP_ROUTING_ECMP" +.PP +.PP +This table implements the second part of IP routing for ECMP routes following the previous table\[char46] If a packet matched a ECMP group in the previous table, this table matches the group id and member id stored from the previous table, setting \fBreg0\fR (or \fBxxreg0\fR for IPv6) to the next-hop IP address (leaving \fBip4\[char46]dst\fR or \fBip6\[char46]dst\fR, the packet\(cqs final destination, unchanged) and advances to the next table for ARP resolution\[char46] It also sets \fBreg1\fR (or \fBxxreg1\fR) to the IP address owned by the selected router port (ingress table \fBARP Request\fR will generate an ARP request, if needed, with \fBreg0\fR as the target protocol address and \fBreg1\fR as the source protocol address)\[char46] +.PP +.PP +This processing is skipped for reply traffic being sent out of an ECMP route if the route was configured to use symmetric replies\[char46] +.PP +.PP +This table contains the following logical flows: +.RS +.IP \(bu +A priority\-150 flow that matches \fBreg8[0\[char46]\[char46]15] == 0\fR with action \fBnext;\fR directly bypasses packets of non-ECMP routes\[char46] +.IP \(bu +For each member with ID \fIMID\fR in each ECMP group with ID \fIGID\fR, a priority\-100 flow with match \fBreg8[0\[char46]\[char46]15] == \fIGID\fB && reg8[16\[char46]\[char46]31] == \fIMID\fB\fR has following actions: +.IP +.nf +\fB +.br +\fB[xx]reg0 = \fR\fIG\fB\fR; +.br +\fB[xx]reg1 = \fR\fIA\fB\fR; +.br +\fBeth\[char46]src = \fR\fIE\fB\fR; +.br +\fBoutport = \fR\fIP\fB\fR; +.br +\fB \fR +.fi +.IP \(bu +A priority\-0 logical flow that matches all packets not already handled (match \fB1\fR) and drops them (action \fBdrop;\fR)\[char46] +.RE +.ST "Ingress Table 15: Router policies" +.PP +.PP +This table adds flows for the logical router policies configured on the logical router\[char46] Please see the \fBOVN_Northbound\fR database \fBLogical_Router_Policy\fR table documentation in \fBovn\-nb\fR for supported actions\[char46] +.RS +.IP \(bu +For each router policy configured on the logical router, a logical flow is added with specified priority, match and actions\[char46] +.IP \(bu +If the policy action is \fBreroute\fR with 2 or more nexthops defined, then the logical flow is added with the following actions: +.IP +.nf +\fB +.br +\fBreg8[0\[char46]\[char46]15] = \fR\fIGID\fB\fR; +.br +\fBreg8[16\[char46]\[char46]31] = select(1,\[char46]\[char46]n); +.br +\fB \fR +.fi +.IP +where \fIGID\fR is the ECMP group id generated by \fBovn\-northd\fR for this policy and \fIn\fR is the number of nexthops\[char46] \fBselect\fR action selects one of the nexthop member id, stores it in the register \fBreg8[16\[char46]\[char46]31]\fR and advances the packet to the next stage\[char46] +.IP \(bu +If the policy action is \fBreroute\fR with just one nexhop, then the logical flow is added with the following actions: +.IP +.nf +\fB +.br +\fB[xx]reg0 = \fR\fIH\fB\fR; +.br +\fBeth\[char46]src = \fR\fIE\fB\fR; +.br +\fBoutport = \fR\fIP\fB\fR; +.br +\fBreg8[0\[char46]\[char46]15] = 0; +.br +\fBflags\[char46]loopback = 1; +.br +\fBnext; +.br +\fB \fR +.fi +.IP +where \fIH\fR is the \fBnexthop \fR defined in the router policy, \fIE\fR is the ethernet address of the logical router port from which the \fBnexthop\fR is reachable and \fIP\fR is the logical router port from which the \fBnexthop\fR is reachable\[char46] +.IP \(bu +If a router policy has the option \fBpkt_mark=\fIm\fB\fR set and if the action is \fBnot\fR drop, then the action also includes \fBpkt\[char46]mark = \fIm\fB\fR to mark the packet with the marker \fIm\fR\[char46] +.RE +.ST "Ingress Table 16: ECMP handling for router policies" +.PP +.PP +This table handles the ECMP for the router policies configured with multiple nexthops\[char46] +.RS +.IP \(bu +A priority\-150 flow is added to advance the packet to the next stage if the ECMP group id register \fBreg8[0\[char46]\[char46]15]\fR is 0\[char46] +.IP \(bu +For each ECMP reroute router policy with multiple nexthops, a priority\-100 flow is added for each nexthop \fIH\fR with the match \fBreg8[0\[char46]\[char46]15] == \fIGID\fB && +reg8[16\[char46]\[char46]31] == \fIM\fB\fR where \fIGID\fR is the router policy group id generated by \fBovn\-northd\fR and \fIM\fR is the member id of the nexthop \fIH\fR generated by \fBovn\-northd\fR\[char46] The following actions are added to the flow: +.IP +.nf +\fB +.br +\fB[xx]reg0 = \fR\fIH\fB\fR; +.br +\fBeth\[char46]src = \fR\fIE\fB\fR; +.br +\fBoutport = \fR\fIP\fB\fR +.br +\fB\(dqflags\[char46]loopback = 1; \(dq +.br +\fB\(dqnext;\(dq +.br +\fB \fR +.fi +.IP +where \fIH\fR is the \fBnexthop \fR defined in the router policy, \fIE\fR is the ethernet address of the logical router port from which the \fBnexthop\fR is reachable and \fIP\fR is the logical router port from which the \fBnexthop\fR is reachable\[char46] +.IP \(bu +A priority\-0 logical flow that matches all packets not already handled (match \fB1\fR) and drops them (action \fBdrop;\fR)\[char46] +.RE +.ST "Ingress Table 17: ARP/ND Resolution" +.PP +.PP +Any packet that reaches this table is an IP packet whose next-hop IPv4 address is in \fBreg0\fR or IPv6 address is in \fBxxreg0\fR\[char46] (\fBip4\[char46]dst\fR or \fBip6\[char46]dst\fR contains the final destination\[char46]) This table resolves the IP address in \fBreg0\fR (or \fBxxreg0\fR) into an output port in \fBoutport\fR and an Ethernet address in \fBeth\[char46]dst\fR, using the following flows: +.RS +.IP \(bu +A priority\-500 flow that matches IP multicast traffic that was allowed in the routing pipeline\[char46] For this kind of traffic the \fBoutport\fR was already set so the flow just advances to the next table\[char46] +.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] (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 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 +For each logical router port with an IPv4 address \fIA\fR and a mac address of \fIE\fR that is reachable via a different logical 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 logical router port with an IPv6 address \fIA\fR and a mac address of \fIE\fR that is reachable via a different logical 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 \(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, below two flows are programmed: +.IP +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] +.IP \(bu +Traffic with IP destination an address owned by the router should be dropped\[char46] Such traffic is normally dropped in ingress table \fBIP Input\fR except for IPs that are also shared with SNAT rules\[char46] However, if there was no unSNAT 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\[char46] +.IP +A priority\-2 logical flow with match \fBip4\[char46]dst = {\[char46]\[char46]}\fR matches on traffic destined to router owned IPv4 addresses which are also SNAT IPs\[char46] This flow has action \fBdrop;\fR\[char46] +.IP +A priority\-2 logical flow with match \fBip6\[char46]dst = {\[char46]\[char46]}\fR matches on traffic destined to router owned IPv6 addresses which are also SNAT IPs\[char46] This flow has action \fBdrop;\fR\[char46] +.IP +A priority\-0 logical that flow matches all packets not already handled (match \fB1\fR) and drops them (action \fBdrop;\fR)\[char46] +.IP \(bu +Dynamic MAC bindings\[char46] These flows resolve MAC-to-IP bindings that have become known dynamically through ARP or neighbor discovery\[char46] (The ingress table \fBARP Request\fR will issue an ARP or neighbor solicitation request for cases where the binding is not yet known\[char46]) +.IP +A priority\-0 logical flow with match \fBip4\fR has actions \fBget_arp(outport, reg0); next;\fR\[char46] +.IP +A priority\-0 logical flow with match \fBip6\fR has actions \fBget_nd(outport, xxreg0); next;\fR\[char46] +.IP \(bu +For a distributed gateway LRP with \fBredirect\-type\fR set to \fBbridged\fR, a priority\-50 flow will match \fBoutport == \(dqROUTER_PORT\(dq and !is_chassis_resident +(\(dqcr\-ROUTER_PORT\(dq)\fR has actions \fBeth\[char46]dst = \fIE\fB; +next;\fR, where \fIE\fR is the ethernet address of the logical router port\[char46] +.RE +.ST "Ingress Table 18: Check packet length" +.PP +.PP +For distributed logical routers or gateway routers with gateway port configured with \fBoptions:gateway_mtu\fR to a valid integer value, this table adds a priority\-50 logical flow with the match \fBoutport == \fIGW_PORT\fB\fR where \fIGW_PORT\fR is the gateway router port and applies the action \fBcheck_pkt_larger\fR and advances the packet to the next table\[char46] +.PP +.nf +\fB +.br +\fBREGBIT_PKT_LARGER = check_pkt_larger(\fR\fIL\fB\fR); next; +.br +\fB \fR +.fi +.PP +.PP +where \fIL\fR is the packet length to check for\[char46] If the packet is larger than \fIL\fR, it stores 1 in the register bit \fBREGBIT_PKT_LARGER\fR\[char46] The value of \fIL\fR is taken from \fBoptions:gateway_mtu\fR column of \fBLogical_Router_Port\fR row\[char46] +.PP +.PP +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] +.PP +.PP +This table adds one priority\-0 fallback flow that matches all packets and advances to the next table\[char46] +.ST "Ingress Table 19: Handle larger packets" +.PP +.PP +For distributed logical routers or gateway routers with gateway port configured with \fBoptions:gateway_mtu\fR to a valid integer value, this table adds the following priority\-150 logical flow for each logical router port with the match \fBinport == \fILRP\fB +&& outport == \fIGW_PORT\fB && REGBIT_PKT_LARGER +&& !REGBIT_EGRESS_LOOPBACK\fR, where \fILRP\fR is the logical router port and \fIGW_PORT\fR is the gateway port and applies the following action for ipv4 and ipv6 respectively: +.PP +.nf +\fB +.br +\fBicmp4 { +.br +\fB icmp4\[char46]type = 3; /* Destination Unreachable\[char46] */ +.br +\fB icmp4\[char46]code = 4; /* Frag Needed and DF was Set\[char46] */ +.br +\fB icmp4\[char46]frag_mtu = \fR\fIM\fB\fR; +.br +\fB eth\[char46]dst = \fR\fIE\fB\fR; +.br +\fB ip4\[char46]dst = ip4\[char46]src; +.br +\fB ip4\[char46]src = \fR\fII\fB\fR; +.br +\fB ip\[char46]ttl = 255; +.br +\fB REGBIT_EGRESS_LOOPBACK = 1; +.br +\fB REGBIT_PKT_LARGER = 0; +.br +\fB next(pipeline=ingress, table=0); +.br +\fB}; +.br +\fB +.br +\fBicmp6 { +.br +\fB icmp6\[char46]type = 2; +.br +\fB icmp6\[char46]code = 0; +.br +\fB icmp6\[char46]frag_mtu = \fR\fIM\fB\fR; +.br +\fB eth\[char46]dst = \fR\fIE\fB\fR; +.br +\fB ip6\[char46]dst = ip6\[char46]src; +.br +\fB ip6\[char46]src = \fR\fII\fB\fR; +.br +\fB ip\[char46]ttl = 255; +.br +\fB REGBIT_EGRESS_LOOPBACK = 1; +.br +\fB REGBIT_PKT_LARGER = 0; +.br +\fB next(pipeline=ingress, table=0); +.br +\fB}; +.br +\fB \fR +.fi +.RS +.IP \(bu +Where \fIM\fR is the (fragment MTU - 58) whose value is taken from \fBoptions:gateway_mtu\fR column of \fBLogical_Router_Port\fR row\[char46] +.IP \(bu +\fIE\fR is the Ethernet address of the logical router port\[char46] +.IP \(bu +\fII\fR is the IPv4/IPv6 address of the logical router port\[char46] +.RE +.PP +.PP +This table adds one priority\-0 fallback flow that matches all packets and advances to the next table\[char46] +.ST "Ingress Table 20: Gateway Redirect" +.PP +.PP +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 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 +For each \fBdnat_and_snat\fR NAT rule with \fBstateless=true\fR and \fBallowed_ext_ips\fR configured, a priority\-75 flow is programmed with match \fBip4\[char46]dst == \fIB\fB\fR and action \fBoutport = \fICR\fB; next;\fR where \fIB\fR is the NAT rule external IP and \fICR\fR is the \fBchassisredirect\fR port representing the instance of the logical router distributed gateway port on the gateway chassis\[char46] Moreover a priority\-70 flow is programmed with same match and action \fBdrop;\fR\[char46] For each \fBdnat_and_snat\fR NAT rule with \fBstateless=true\fR and \fBexempted_ext_ips\fR configured, a priority\-75 flow is programmed with match \fBip4\[char46]dst == \fIB\fB\fR and action \fBdrop;\fR where \fIB\fR is the NAT rule external IP\[char46] A similar flow is added for IPv6 traffic\[char46] +.IP \(bu +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 virtual port not claimed by any chassis yet\[char46] +.IP \(bu +A priority\-50 logical flow with match \fBoutport == \fIGW\fB\fR has actions \fBoutport = \fICR\fB; next;\fR, where \fIGW\fR is the logical router distributed gateway port and \fICR\fR is the \fBchassisredirect\fR port representing the instance of the logical router distributed gateway port on the gateway chassis\[char46] +.IP \(bu +A priority\-0 logical flow with match \fB1\fR has actions \fBnext;\fR\[char46] +.RE +.ST "Ingress Table 21: ARP Request" +.PP +.PP +In the common case where the Ethernet destination has been resolved, this table outputs the packet\[char46] Otherwise, it composes and sends an ARP or IPv6 Neighbor Solicitation request\[char46] It holds the following flows: +.RS +.IP \(bu +Unknown MAC address\[char46] A priority\-100 flow for IPv4 packets with match \fBeth\[char46]dst == 00:00:00:00:00:00\fR has the following actions: +.IP +.nf +\fB +.br +\fBarp { +.br +\fB eth\[char46]dst = ff:ff:ff:ff:ff:ff; +.br +\fB arp\[char46]spa = reg1; +.br +\fB arp\[char46]tpa = reg0; +.br +\fB arp\[char46]op = 1; /* ARP request\[char46] */ +.br +\fB output; +.br +\fB}; +.br +\fB \fR +.fi +.IP +Unknown MAC address\[char46] For each IPv6 static route associated with the router with the nexthop IP: \fIG\fR, a priority\-200 flow for IPv6 packets with match \fBeth\[char46]dst == 00:00:00:00:00:00 && +xxreg0 == \fIG\fB\fR with the following actions is added: +.IP +.nf +\fB +.br +\fBnd_ns { +.br +\fB eth\[char46]dst = \fR\fIE\fB\fR; +.br +\fB ip6\[char46]dst = \fR\fII\fB\fR +.br +\fB nd\[char46]target = \fR\fIG\fB\fR; +.br +\fB output; +.br +\fB}; +.br +\fB \fR +.fi +.IP +Where \fIE\fR is the multicast mac derived from the Gateway IP, \fII\fR is the solicited-node multicast address corresponding to the target address \fIG\fR\[char46] +.IP +Unknown MAC address\[char46] A priority\-100 flow for IPv6 packets with match \fBeth\[char46]dst == 00:00:00:00:00:00\fR has the following actions: +.IP +.nf +\fB +.br +\fBnd_ns { +.br +\fB nd\[char46]target = xxreg0; +.br +\fB output; +.br +\fB}; +.br +\fB \fR +.fi +.IP +(Ingress table \fBIP Routing\fR initialized \fBreg1\fR with the IP address owned by \fBoutport\fR and \fB(xx)reg0\fR with the next-hop IP address) +.IP +The IP packet that triggers the ARP/IPv6 NS request is dropped\[char46] +.IP \(bu +Known MAC address\[char46] A priority\-0 flow with match \fB1\fR has actions \fBoutput;\fR\[char46] +.RE +.ST "Egress Table 0: Check DNAT local" +.PP +.PP +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 +A priority\-0 logical flow with match \fB1\fR has actions \fBREGBIT_DST_NAT_IP_LOCAL = 0; next;\fR\[char46] +.RE +.ST "Egress Table 1: UNDNAT" +.PP +.PP +This is for already established connections\(cq reverse traffic\[char46] i\[char46]e\[char46], DNAT has already been done in ingress pipeline and now the packet has entered the egress pipeline as part of a reply\[char46] This traffic is unDNATed here\[char46] +.RS +.IP \(bu +A priority\-0 logical flow with match \fB1\fR has actions \fBnext;\fR\[char46] +.RE +.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;\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;\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\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 +.ST "Egress Table 2: Post UNDNAT" +.PP +.PP +.RS +.IP \(bu +A priority\-50 logical flow is added that commits any untracked flows from the previous table \fBlr_out_undnat\fR for Gateway routers\[char46] This flow matches on \fBct\[char46]new && ip\fR with action \fBct_commit { } ; next; \fR\[char46] +.IP \(bu +A priority\-0 logical flow with match \fB1\fR has actions \fBnext;\fR\[char46] +.RE +.ST "Egress Table 3: SNAT" +.PP +.PP +Packets that are configured to be SNATed get their source IP address changed based on the configuration in the OVN Northbound database\[char46] +.RS +.IP \(bu +A priority\-120 flow to advance the IPv6 Neighbor solicitation packet to next table to skip SNAT\[char46] In the case where ovn-controller injects an IPv6 Neighbor Solicitation packet (for \fBnd_ns\fR action) we don\(cqt want the packet to go through conntrack\[char46] +.RE +.PP +.PP +Egress Table 3: SNAT on Gateway Routers +.RS +.IP \(bu +If the Gateway router in the OVN Northbound database has been configured to force SNAT a packet (that has been previously DNATted) to \fIB\fR, a priority\-100 flow matches \fBflags\[char46]force_snat_for_dnat == 1 && ip\fR with an action \fBct_snat(\fIB\fB);\fR\[char46] +.IP \(bu +If a load balancer configured to skip snat has been applied to the Gateway router pipeline, a priority\-120 flow matches \fBflags\[char46]skip_snat_for_lb == 1 && ip\fR with an action \fBnext;\fR\[char46] +.IP \(bu +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\[char46]e \fBoptions\fR:lb_force_snat_ip=router_ip), then for each logical router port \fIP\fR attached to the Gateway router, a priority\-110 flow matches \fBflags\[char46]force_snat_for_lb == 1 && outport == \fIP\fB +\fR with an action \fBct_snat(\fIR\fB);\fR where \fIR\fR is the IP configured on the router port\[char46] If \fBR\fR is an IPv4 address then the match will also include \fBip4\fR and if it is an IPv6 address, then the match will also include \fBip6\fR\[char46] +.IP +If the logical router port \fIP\fR is configured with multiple IPv4 and multiple IPv6 addresses, only the first IPv4 and first IPv6 address is considered\[char46] +.IP \(bu +If the Gateway router in the OVN Northbound database has been configured to force SNAT a packet (that has been previously load-balanced) to \fIB\fR, a priority\-100 flow matches \fBflags\[char46]force_snat_for_lb == 1 && ip\fR with an action \fBct_snat(\fIB\fB);\fR\[char46] +.IP \(bu +For each configuration in the OVN Northbound database, that asks to change the source IP address of a packet from an IP address of \fIA\fR or to change the source IP address of a packet that belongs to network \fIA\fR to \fIB\fR, a flow matches \fBip && ip4\[char46]src == \fIA\fB && +(!ct\[char46]trk || !ct\[char46]rpl)\fR with an action \fBct_snat(\fIB\fB);\fR\[char46] The priority of the flow is calculated based on the mask of \fIA\fR, with matches having larger masks getting higher priorities\[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 +If the NAT rule has \fBallowed_ext_ips\fR configured, then there is an additional match \fBip4\[char46]dst == \fIallowed_ext_ips +\fB\fR\[char46] Similarly, for IPV6, match would be \fBip6\[char46]dst == +\fIallowed_ext_ips\fB\fR\[char46] +.IP \(bu +If the NAT rule has \fBexempted_ext_ips\fR set, then there is an additional flow configured at the priority + 1 of corresponding NAT rule\[char46] The flow matches if destination ip is an \fBexempted_ext_ip\fR and the action is \fBnext; +\fR\[char46] This flow is used to bypass the ct_snat action for a packet which is destinted to \fBexempted_ext_ips\fR\[char46] +.IP \(bu +A priority\-0 logical flow with match \fB1\fR has actions \fBnext;\fR\[char46] +.RE +.PP +.PP +Egress Table 3: SNAT on Distributed Routers +.RS +.IP \(bu +For each configuration in the OVN Northbound database, that asks to change the source IP address of a packet from an IP address of \fIA\fR or to change the source IP address of a packet that belongs to network \fIA\fR to \fIB\fR, two flows are added\[char46] The priority \fIP\fR of these flows are calculated based on the mask of \fIA\fR, with matches having larger masks getting higher priorities\[char46] +.IP +If the NAT rule cannot be handled in a distributed manner, then the below flows are only programmed on the gateway chassis increasing flow priority by 128 in order to be run first\[char46] +.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(\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] +.IP +If the NAT rule has \fBallowed_ext_ips\fR configured, then there is an additional match \fBip4\[char46]dst == \fIallowed_ext_ips +\fB\fR\[char46] Similarly, for IPV6, match would be \fBip6\[char46]dst == +\fIallowed_ext_ips\fB\fR\[char46] +.IP +If the NAT rule has \fBexempted_ext_ips\fR set, then there is an additional flow configured at the priority \fB\fIP\fB + 2 \fR of corresponding NAT rule\[char46] The flow matches if destination ip is an \fBexempted_ext_ip\fR and the action is \fBnext; +\fR\[char46] This flow is used to bypass the ct_snat action for a flow which is destinted to \fBexempted_ext_ips\fR\[char46] +.IP \(bu +A priority\-0 logical flow with match \fB1\fR has actions \fBnext;\fR\[char46] +.RE +.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] +.PP +.PP +While UNDNAT and SNAT processing have already occurred by this point, this traffic needs to be forced through egress loopback on this distributed gateway port instance, in order for UNSNAT and DNAT processing 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 destination\[char46] +.PP +.PP +This table has the following flows: +.RS +.IP \(bu +For each NAT rule in the OVN Northbound database on a distributed router, a priority\-100 logical flow with match \fBip4\[char46]dst == \fIE\fB && +outport == \fIGW\fB && +is_chassis_resident(\fIP\fB)\fR, where \fIE\fR is the external IP address specified in the NAT rule, \fIGW\fR is the distributed gateway port corresponding to the NAT rule (specified or inferred)\[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 following actions: +.IP +.nf +\fB +.br +\fBclone { +.br +\fB ct_clear; +.br +\fB inport = outport; +.br +\fB outport = \(dq\(dq; +.br +\fB flags = 0; +.br +\fB flags\[char46]loopback = 1; +.br +\fB reg0 = 0; +.br +\fB reg1 = 0; +.br +\fB \[char46]\[char46]\[char46] +.br +\fB reg9 = 0; +.br +\fB REGBIT_EGRESS_LOOPBACK = 1; +.br +\fB next(pipeline=ingress, table=0); +.br +\fB}; +.br +\fB \fR +.fi +.IP +\fBflags\[char46]loopback\fR is set since in_port is unchanged and the packet may return back to that port after NAT processing\[char46] \fBREGBIT_EGRESS_LOOPBACK\fR is set to indicate that egress loopback has occurred, in order to skip the source IP address check against the router address\[char46] +.IP \(bu +A priority\-0 logical flow with match \fB1\fR has actions \fBnext;\fR\[char46] +.RE +.ST "Egress Table 6: Delivery" +.PP +.PP +Packets that reach this table are ready for delivery\[char46] It contains: +.RS +.IP \(bu +Priority\-110 logical flows that match IP multicast packets 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 \fBoutput;\fR\[char46] +.IP \(bu +Priority\-100 logical flows that match packets on each enabled logical router port, with action \fBoutput;\fR\[char46] +.IP \(bu +A priority\-0 logical flow that matches all packets not already handled (match \fB1\fR) and drops them (action \fBdrop;\fR)\[char46] +.RE +.SH "DROP SAMPLING" +.PP +.PP +As described in the previous section, there are several places where ovn-northd might decided to drop a packet by explicitly creating a \fBLogical_Flow\fR with the \fBdrop;\fR action\[char46] +.PP +.PP +When debug drop-sampling has been cofigured in the OVN Northbound database, the ovn-northd will replace all the \fBdrop;\fR actions with a \fBsample(priority=65535, collector_set=\fIid\fB, +obs_domain=\fIobs_id\fB, obs_point=@cookie)\fR action, where: +.RS +.IP \(bu +\fIid\fR is the value the \fBdebug_drop_collector_set\fR option configured in the OVN Northbound\[char46] +.IP \(bu +\fIobs_id\fR has it\(cqs 8 most significant bits equal to the value of the \fBdebug_drop_domain_id\fR option in the OVN Northbound and it\(cqs 24 least significant bits equal to the datapath\(cqs tunnel key\[char46] +.RE diff --git a/src/static/support/dist-docs-branch-23.06/ovn-northd.8.html b/src/static/support/dist-docs-branch-23.06/ovn-northd.8.html new file mode 100644 index 00000000..87b3c5d0 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-northd.8.html @@ -0,0 +1,3725 @@ +
+ovn-northd(8)                     OVN Manual                     ovn-northd(8)
+
+NAME
+       ovn-northd  and ovn-northd-ddlog - 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 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 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 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  opā€
+              tion  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
+              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
+              cost of increasing CPU usage).
+
+              This option will cause ovn-northd to use N threads when building
+              logical flows, when N is within [2-256]. If N is 1, parallelizaā€
+              tion is disabled (default behavior). If N is less than 1, then N
+              is set to 1,  parallelization  is  disabled  and  a  warning  is
+              logged.  If  N  is  more  than 256, then N is set to 256, paralā€
+              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
+              specified, or if it does not begin with /, then it is created in
+              .
+
+              If --pidfile is not specified, no pidfile is created.
+
+       --overwrite-pidfile
+              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.
+
+              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
+              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
+              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ā€ā€
+              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ā€
+              tions without it.
+
+       --no-chdir
+              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.
+
+              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-
+              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.
+
+       --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
+              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
+              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
+              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
+            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
+                   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, 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
+                   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
+                   definition of each log level.
+
+            Case is not significant within spec.
+
+            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
+            word but has no effect.
+
+       -v
+       --verbose
+            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-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,
+            local4, local5, local6 or local7. If this option is not specified,
+            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
+            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.
+
+       --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ā€
+            name.
+
+       --syslog-method=method
+            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
+                   /dev/log UNIX domain socket.
+
+            ā€¢      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  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
+       to the Northbound and Southbound databases.
+
+              -p privkey.pem
+              --private-key=privkey.pem
+                   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ā€
+                   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
+                   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
+                   verify the certificate specified on -c or --certificate, or
+                   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
+                   trusted hosts.
+
+   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
+              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ā€
+              agement commands. A file is created  in  the  absolute  path  as
+              pointed  by socket or if --unixctl is not used at all, a file is
+              created as program in the configured OVS_RUNDIR  directory.  The
+              file exists just to mimic the behavior of a Unix domain socket.
+
+              Specifying none for socket disables the control socket feature.
+
+
+
+       -h
+       --help
+            Prints a brief help message to the console.
+
+       -V
+       --version
+            Prints version information to the console.
+
+RUNTIME MANAGEMENT COMMANDS
+       ovs-appctl  can send commands to a running ovn-northd process. The curā€
+       rently supported commands are described below.
+
+              exit   Causes ovn-northd to gracefully terminate.
+
+              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
+                     paused ovn-northd also drops database locks, which allows
+                     any other non-paused instance of ovn-northd to take over.
+
+              resume Resumes the ovn-northd operation  to  process  Northbound
+                     and  Southbound  database  contents  and generate logical
+                     flows. This will also instruct ovn-northd to  aspire  for
+                     the lock on SB DB.
+
+              is-paused
+                     Returns "true" if ovn-northd is currently paused, "false"
+                     otherwise.
+
+              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.
+
+              sb-cluster-state-reset
+                     Reset southbound database cluster status  when  databases
+                     are destroyed and rebuilt.
+
+                     If  all  databases in a clustered southbound database are
+                     removed from disk, then the stored index of all databases
+                     will be reset to zero. This will cause ovn-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
+                     are destroyed and rebuilt.
+
+                     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 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
+                     flows.
+
+              inc-engine/show-stats
+                     Display ovn-northd engine counters. For each engine  node
+                     the following counters have been added:
+
+                     ā€¢      recompute
+
+                     ā€¢      compute
+
+                     ā€¢      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
+                     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  enā€
+                   abled  (even if it was later disabled), the output also inā€
+                   cludes a CPU time profile. See Profiling inside the  tutorā€
+                   ial  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
+       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
+                     active and multiple passive ovsdb-servers.
+
+              ā€¢      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,  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
+       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
+       ovn-northd does this for switch and router logical datapaths.
+
+   Logical Switch Datapaths
+     Ingress Table 0: Admission Control and Ingress Port Security check
+
+       Ingress table 0 contains these logical flows:
+
+              ā€¢      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
+                     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 acā€
+                     tion  next(pipeline=ingress, table=S_SWITCH_IN_L2_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ā€ā€
+                     BIT_PORT_SEC_DROP" = check_in_port_sec(); next; to evaluā€
+                     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
+
+       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
+                     register bit REGBIT_PORT_SEC_DROP is set to 1.
+
+              ā€¢      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 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 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
+                            action  reg0[11]  =  lookup_fdb(inport,  eth.src);
+                            next;
+
+              ā€¢      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 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 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 &&&&
+                            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 adā€
+                            vances the packet to the next table.
+
+              ā€¢      One priority-0 fallback flow that matches all packets and
+                     advances to the next table.
+
+     Ingress Table 4: from-lport Pre-ACLs
+
+       This table prepares flows  for  possible  stateful  ACL  processing  in
+       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 "alā€
+       low-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ā€
+       umn of NB_Global table.
+
+     Ingress Table 5: Pre-LB
+
+       This table prepares flows for possible stateful load balancing processā€
+       ing in ingress table LB and Stateful. 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. 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 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  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
+       cases  where  a logical switch doesnā€™t have any ACLs with allow-related
+       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
+       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
+       the  backend lport sends an invalid TCP packet (like incorrect sequence
+       number), the packet gets delivered to the lport ā€™p1ā€™ without  unDNATing
+       the packet to the VIP - 10.0.0.10. And this causes the connection to be
+       reset by the lport p1ā€™s VIF.
+
+       We canā€™t fix this issue by adding a logical flow to drop ct.inv packets
+       in  the  egress  pipeline  since it will drop all other connections not
+       destined to the load balancers. To fix this  issue,  we  send  all  the
+       packets  to the conntrack in the ingress pipeline if a load balancer is
+       configured. We can now add a lflow to drop ct.inv packets.
+
+       This table also has priority-120 flows that punt all  IGMP/MLD  packets
+       to  ovn-controller  if the switch is an interconnect switch with multiā€
+       cast snooping enabled.
+
+       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ā€
+       umn of NB_Global table.
+
+       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
+       connection tracking of packets which enter from logical router datapath
+       to logical switch datapath.
+
+     Ingress Table 6: Pre-stateful
+
+       This  table prepares flows for all possible stateful processing in next
+       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  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
+                     reg2.  For  IPv6 traffic the flows also load the original
+                     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
+                     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
+                     tracker  based  on a hint provided by the previous tables
+                     (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
+       same packet. The possible hints are:
+
+              ā€¢      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ā€
+                     ntrack because it already exists.
+
+              ā€¢      reg0[9]: the packet might match a drop/reject.
+
+              ā€¢      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
+                     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
+                     advances to the next table.
+
+              ā€¢      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
+                     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
+                     next table.
+
+              ā€¢      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
+                     reg0[10] and then advances to the next table.
+
+              ā€¢      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
+                     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
+                     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 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
+       room for OVN default flows at both higher and lower priorities.
+
+              ā€¢      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.
+
+              ā€¢      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:
+
+              ā€¢      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 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-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
+                     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 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
+                     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 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ā€
+                     tioned in the QoS table.
+
+              ā€¢      One priority-0 fallback flow that matches all packets and
+                     advances to the next table.
+
+     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
+                     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-100 flow is added. For IPv4 VIPs,  the  flow  matches
+                     ct.new &&&& ip &&&& ip4.dst == VIP &&&& P.dst == PORT. For IPv6
+                     VIPs, the flow matches ct.new &&&& ip &&&& ip6.dst == VIP&&&& P
+                     &&&&  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
+                     and applies the action next;.
+
+     Ingress Table 13: LB
+
+              ā€¢      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
+                     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
+                     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  &&&&
+                     ip4.dst  == VIP &&&& P.dst == PORT. For IPv6 VIPs, the flow
+                     matches ct.new &&&& ip &&&& ip6.dst == VIP &&&& P &&&&  P.dst  ==
+                     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
+                     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
+                     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.
+
+              ā€¢      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  reā€
+                     ceived for this load-balancer. Please note using --reject
+                     option will disable empty_lb SB controller event for this
+                     load balancer.
+
+     Ingress Table 14: Load balancing affinity learn
+
+       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
+                     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
+                     reg9[6] == 0 &&&& ct.new &&&& ip &&&& ip4.dst == VIP  &&&&  P.dst
+                     ==  PORT. For IPv6 VIPs, the flow matches ct.new &&&& ip &&&&
+                     ip6.dst == VIP &&&& P &&&& P.dst == PORT . The flowā€™s  action
+                     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
+                     and applies the action next;.
+
+     Ingress Table 15: Pre-Hairpin
+
+              ā€¢      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
+                     source  IP)  or  not  by  executing the actions reg0[6] =
+                     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
+                     table.
+
+     Ingress Table 16: Nat-Hairpin
+
+              ā€¢      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,
+                     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,
+                     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
+                     to the next table.
+
+              ā€¢      A  priority-0  flow that simply moves traffic to the next
+                     table.
+
+     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)
+
+                     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.
+
+              ā€¢      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-
+                     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
+                     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 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
+       by locally responding to ARP requests without the need to send to other
+       hypervisors. One common case is when the inport is a logical port assoā€
+       ciated with a VIF and the broadcast is responded to on the local hyperā€
+       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  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.
+       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
+       rare.
+
+       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 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:
+
+              ā€¢      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
+
+                     inport == P &&&& &&&& ((arp.op == 1 &&&& arp.spa == VIP &&&& arp.tpa == VIP) || (arp.op == 2 &&&& arp.spa == VIP))
+                     inport == P &&&& &&&& ((nd_ns &&&& ip6.dst == {VIP, NS_MULTICAST_ADDR} &&&& nd.target == VIP) || (nd_na &&&& nd.target == VIP))
+
+
+                     and applies the action
+
+                     bind_vport(V, inport);
+
+
+                     and advances the packet to the next table.
+
+                     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
+                     IP address A of every logical switch  port,  and  respond
+                     with ARP replies directly with corresponding Ethernet adā€
+                     dress E:
+
+                     eth.dst = eth.src;
+                     eth.src = E;
+                     arp.op = 2; /* ARP reply. */
+                     arp.tha = arp.sha;
+                     arp.sha = E;
+                     arp.tpa = arp.spa;
+                     arp.spa = A;
+                     outport = inport;
+                     flags.loopback = 1;
+                     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
+                     of NB_Global table of the Northbound database), for logiā€
+                     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
+                     IPv4  addresses if defined in options:arp_proxy column of
+                     Logical_Switch_Port table for  logical  switch  ports  of
+                     type router.
+
+              ā€¢      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
+                     with corresponding Ethernet address E:
+
+                     nd_na {
+                         eth.src = E;
+                         ip6.src = A;
+                         nd.target = A;
+                         nd.tll = E;
+                         outport = inport;
+                         flags.loopback = 1;
+                         output;
+                     };
+
+
+                     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 {
+                         eth.src = E;
+                         ip6.src = A;
+                         nd.target = A;
+                         nd.tll = E;
+                         outport = inport;
+                         flags.loopback = 1;
+                         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
+                     of NB_Global table of the Northbound database), for logiā€
+                     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
+                     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 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;
+                     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ā€
+                     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
+                     the action
+
+                     eth.dst = eth.src;
+                     eth.src = E;
+                     arp.op = 2; /* ARP reply. */
+                     arp.tha = arp.sha;
+                     arp.sha = E;
+                     arp.tpa = arp.spa;
+                     arp.spa = A;
+                     outport = inport;
+                     flags.loopback = 1;
+                     output;
+
+
+                     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.
+
+                     SVC_MON_SRC_IP  is  used  as the source ip in the service
+                     monitor IPv4 packets for the load  balancer  endpoint  IP
+                     health checks.
+
+                     These  flows  are  required if an ARP request is sent for
+                     the IP SVC_MON_SRC_IP.
+
+                     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
+
+                     eth.dst = eth.src;
+                     eth.src = E;
+                     arp.op = 2; /* ARP reply. */
+                     arp.tha = arp.sha;
+                     arp.sha = E;
+                     arp.tpa = arp.spa;
+                     arp.spa = A;
+                     outport = inport;
+                     flags.loopback = 1;
+                     output;
+
+
+                     where E is the forwarding  groupā€™s  mac  defined  in  the
+                     vmac.
+
+                     A is used as either the destination ip for load balancing
+                     traffic  to child ports or as nexthop to hosts behind the
+                     child ports.
+
+                     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
+                     advances to the next table.
+
+     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
+                     ports which matches the IPv4 packet with udp.src = 68 and
+                     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;
+
+
+                     For  DHCPDISCOVER  and  DHCPREQUEST,  this transforms the
+                     packet into a DHCP reply, adds the DHCP offer IP  ip  and
+                     options  to  the  packet,  and stores 1 into reg0[3]. For
+                     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
+                     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.
+
+                     reg0[3] = put_dhcpv6_opts(ia_addr = ip, options...);
+                     next;
+
+
+                     For DHCPv6 Solicit/Request/Confirm packets,  this  transā€
+                     forms  the packet into a DHCPv6 Advertise/Reply, adds the
+                     DHCPv6 offer IP ip and options to the packet, and  stores
+                     1  into  reg0[3].  For  other  kinds  of packets, it just
+                     stores 0 into reg0[3]. Either way, it  continues  to  the
+                     next table.
+
+              ā€¢      A priority-0 flow that matches all packets to advances to
+                     table 16.
+
+     Ingress Table 23: DHCP responses
+
+       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
+                     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
+                     put_dhcp_opts was successful.
+
+                     eth.dst = eth.src;
+                     eth.src = E;
+                     ip4.src = S;
+                     udp.src = 67;
+                     udp.dst = 68;
+                     outport = P;
+                     flags.loopback = 1;
+                     output;
+
+
+                     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
+                     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]
+                     == 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.
+
+                     eth.dst = eth.src;
+                     eth.src = E;
+                     ip6.dst = A;
+                     ip6.src = S;
+                     udp.src = 547;
+                     udp.dst = 546;
+                     outport = P;
+                     flags.loopback = 1;
+                     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
+                     the logical portā€™s addresses column.
+
+                     (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
+                     table 17.
+
+     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
+                     the action dns_lookup and advances the packet to the next
+                     table.
+
+                     reg0[4] = dns_lookup(); next;
+
+
+                     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
+                     continues to the next table.
+
+     Ingress Table 25 DNS Responses
+
+       This  table  implements  DNS responder for the DNS replies generated by
+       the previous table.
+
+              ā€¢      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
+                     actions. If reg0[4] is set to 1, it means that the action
+                     dns_lookup was successful.
+
+                     eth.dst ->gt;>gt; eth.src;
+                     ip4.src ->gt;>gt; ip4.dst;
+                     udp.dst = udp.src;
+                     udp.src = 53;
+                     outport = P;
+                     flags.loopback = 1;
+                     output;
+
+
+                     (This terminates ingress packet  processing;  the  packet
+                     does not go to the next ingress table.)
+
+     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
+                     switch) which matches on the inport of the external logiā€
+                     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.
+                     All the other chassis, drops these packets.
+
+                     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 == 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
+                     table 20.
+
+     Ingress Table 27 Destination Lookup
+
+       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ā€ā€
+                     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
+                     ovn-controller  if  multicast  snooping is enabled on the
+                     logical switch.
+
+              ā€¢      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
+                     multicast group, which ovn-nortdh populates with all  the
+                     logical  ports that are connected to logical routers with
+                     options:mcast_relay=ā€™trueā€™.
+
+              ā€¢      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 enā€
+                     abled logical ports.
+
+              ā€¢      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 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
+                     router  that  owns  the IP address and to the MC_FLOOD_L2
+                     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  reā€
+                     quest/ND  packets.  These  packets  are  flooded  to  the
+                     MC_FLOOD_L2 which contains all non-router logical ports.
+
+              ā€¢      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 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
+                     has a gateway chassis:
+
+                     ā€¢      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
+                            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 to which the connected logical router port belongs
+                     to has a distributed gateway LRP:
+
+                     ā€¢      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
+                     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
+                     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
+                     it stores none in the outport.
+
+     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
+       contains the following flows.
+
+              ā€¢      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ā€™
+                     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
+                            group, which ovn-northd populates with all enabled
+                            logical  ports  that  accept  unknown  destination
+                            packets.  As  a  small optimization, if no logical
+                            ports   accept   unknown   destination    packets,
+                            ovn-northd  omits this multicast group and logical
+                            flow.
+
+                     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
+                            and drops the packets.
+
+              ā€¢      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
+
+       This is similar to ingress table Pre-ACLs except for to-lport 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ā€
+       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. 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 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  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ā€
+       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  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  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; acā€
+                     tion.
+
+              ā€¢      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 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].
+
+       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
+                     port which has DHCPv4 options defined to allow the DHCPv4
+                     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
+                     match udp.dst = 53 to allow the DNS reply packet from the
+                     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ā€ā€
+                     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. This is indicated by setting  the  allow
+                     bit.
+
+     Egress Table 5: to-lport ACL action
+
+       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 7: to-lport QoS Meter
+
+       This is similar to  ingress  table  QoS  meter  except  they  apply  to
+       to-lport QoS rules.
+
+     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 9: Egress Port Security - check
+
+       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ā€
+                     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
+                     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
+                     on the addresses defined in the port_security  column  of
+                     Logical_Switch_Port table before delivering the packet to
+                     the outport.
+
+     Egress Table 10: Egress Port Security - Apply
+
+       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ā€ā€
+       BIT_PORT_SEC_DROP is set to 1.
+
+       The following flows are added.
+
+              ā€¢      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;".
+
+                     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
+                     bit REGBIT_PORT_SEC_DROP is set to 1.
+
+              ā€¢      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
+       OVN_Northbound database that do not have enabled set to false
+
+     Ingress Table 0: L2 Admission Control
+
+       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ā€
+                     ticast Ethernet source addresses.
+
+              ā€¢      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;
+                     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
+                     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
+                     reach LR services (LBs, NAT).
+
+                     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: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
+                     already handled (match 1) and drops them (action drop;).
+
+       Other packets are implicitly dropped.
+
+     Ingress Table 1: Neighbor lookup
+
+       For  ARP and IPv6 Neighbor Discovery packets, this table looks into the
+       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 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:
+
+                     reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
+                     next;
+
+
+                     If the option always_learn_from_arp_request is false, the
+                     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  reā€
+                     quest) with the following actions:
+
+                     reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
+                     reg9[3] = 1;
+                     next;
+
+
+                     A priority-100 flow is added which matches inport == P &&&&
+                     arp.spa == S/L &&&& arp.op == 1 (ARP request) with the folā€
+                     lowing actions:
+
+                     reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
+                     reg9[3] = lookup_arp_ip(inport, arp.spa);
+                     next;
+
+
+                     If  the  logical  router  port P is a distributed gateway
+                     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    alā€ā€
+                     ways_learn_from_arp_request is true:
+
+                     reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
+                     next;
+
+
+                     If the option always_learn_from_arp_request is false, the
+                     above actions will be:
+
+                     reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
+                     reg9[3] = 1;
+                     next;
+
+
+              ā€¢      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);
+                     next;
+
+
+                     If the option always_learn_from_arp_request is false, the
+                     above actions will be:
+
+                     reg9[2] = lookup_nd(inport, nd.target, nd.tll);
+                     reg9[3] = 1;
+                     next;
+
+
+              ā€¢      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:
+
+                     reg9[2] = lookup_nd(inport, ip6.src, nd.sll);
+                     next;
+
+
+                     If the option always_learn_from_arp_request is false, the
+                     above actions will be:
+
+                     reg9[2] = lookup_nd(inport, ip6.src, nd.sll);
+                     reg9[3] = lookup_nd_ip(inport, ip6.src);
+                     next;
+
+
+              ā€¢      A priority-0 fallback flow that matches all  packets  and
+                     applies  the  action  reg9[2]  =  1;  next; advancing the
+                     packet to the next table.
+
+     Ingress Table 2: Neighbor learning
+
+       This table adds flows to learn the mac bindings from the ARP  and  IPv6
+       Neighbor  Solicitation/Advertisement  packets if it is needed according
+       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
+       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  ||
+                     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
+                     || nd.sll == 0) and applies the action 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
+                     and   applies   the   action   put_nd(inport,  nd.target,
+                     eth.src); next;
+
+              ā€¢      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
+                     action put_nd(inport, ip6.src, nd.sll); next;
+
+              ā€¢      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ā€
+       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 acā€
+                     tion for ipv4 and ipv6 respectively:
+
+                     icmp4_error {
+                         icmp4.type = 3; /* Destination Unreachable. */
+                         icmp4.code = 4;  /* Frag Needed and DF was Set. */
+                         icmp4.frag_mtu = M;
+                         eth.dst = eth.src;
+                         eth.src = E;
+                         ip4.dst = ip4.src;
+                         ip4.src = I;
+                         ip.ttl = 255;
+                         REGBIT_EGRESS_LOOPBACK = 1;
+                         REGBIT_PKT_LARGER 0;
+                         outport = LRP;
+                         flags.loopback = 1;
+                         output;
+                     };
+                     icmp6_error {
+                         icmp6.type = 2;
+                         icmp6.code = 0;
+                         icmp6.frag_mtu = M;
+                         eth.dst = eth.src;
+                         eth.src = E;
+                         ip6.dst = ip6.src;
+                         ip6.src = I;
+                         ip.ttl = 255;
+                         REGBIT_EGRESS_LOOPBACK = 1;
+                         REGBIT_PKT_LARGER 0;
+                         outport = LRP;
+                         flags.loopback = 1;
+                         output;
+                     };
+
+
+                     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  apā€
+                     plies  the  following  action  for  ipv4 and ipv6 respecā€
+                     tively:
+
+                     icmp4_error {
+                         icmp4.type = 3; /* Destination Unreachable. */
+                         icmp4.code = 4;  /* Frag Needed and DF was Set. */
+                         icmp4.frag_mtu = M;
+                         eth.dst = E;
+                         ip4.dst = ip4.src;
+                         ip4.src = I;
+                         ip.ttl = 255;
+                         REGBIT_EGRESS_LOOPBACK = 1;
+                         REGBIT_PKT_LARGER 0;
+                         next(pipeline=ingress, table=0);
+                     };
+                     icmp6_error {
+                         icmp6.type = 2;
+                         icmp6.code = 0;
+                         icmp6.frag_mtu = M;
+                         eth.dst = E;
+                         ip6.dst = ip6.src;
+                         ip6.src = I;
+                         ip.ttl = 255;
+                         REGBIT_EGRESS_LOOPBACK = 1;
+                         REGBIT_PKT_LARGER 0;
+                         next(pipeline=ingress, table=0);
+                     };
+
+
+              ā€¢      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
+                     ip6.src is used for the match.
+
+                     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
+                     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
+                            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ā€ā€
+                            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 opā€ā€
+                     tions :mcast_flood=ā€™ā€™trueā€™ā€™.
+
+              ā€¢      L3  admission  control: A priority-100 flow drops packets
+                     that match any of the following:
+
+                     ā€¢      ip4.src[28..31] == 0xe (multicast source)
+
+                     ā€¢      ip4.src == 255.255.255.255 (broadcast source)
+
+                     ā€¢      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
+                            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ā€ā€
+                            BIT_EGRESS_LOOPBACK.
+
+                     ā€¢      ip4.src is the broadcast address of any IP network
+                            known to the router.
+
+              ā€¢      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 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;
+                     ip.ttl = 255;
+                     icmp4.type = 0;
+                     flags.loopback = 1;
+                     next;
+
+
+                     Flows for ICMPv6 echo requests use the following actions:
+
+                     ip6.dst ->gt;>gt; ip6.src;
+                     ip.ttl = 255;
+                     icmp6.type = 129;
+                     flags.loopback = 1;
+                     next;
+
+
+              ā€¢      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 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 ==
+                     P &&&& arp.spa == S/L &&&& arp.op == 1 &&&& arp.tpa ==  A  (ARP
+                     request) with the following actions:
+
+                     eth.dst = eth.src;
+                     eth.src = xreg0[0..47];
+                     arp.op = 2; /* ARP reply. */
+                     arp.tha = arp.sha;
+                     arp.sha = xreg0[0..47];
+                     arp.tpa = arp.spa;
+                     arp.spa = A;
+                     outport = inport;
+                     flags.loopback = 1;
+                     output;
+
+
+                     For  the  gateway  port  on  a distributed logical router
+                     (where one of the logical router ports specifies a  gateā€
+                     way  chassis), the above flows are only programmed on the
+                     gateway port instance on the gateway chassis. This behavā€
+                     ior avoids generation of multiple ARP responses from difā€
+                     ferent chassis, and allows upstream MAC learning to point
+                     to the gateway chassis.
+
+                     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, 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 {
+                         eth.src = xreg0[0..47];
+                         ip6.src = A;
+                         nd.target = A;
+                         nd.tll = xreg0[0..47];
+                         outport = inport;
+                         flags.loopback = 1;
+                         output;
+                     };
+
+
+                     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
+                     router for NAT (both DNAT and SNAT) or load balancing.
+
+                     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];
+                     arp.op = 2; /* ARP reply. */
+                     arp.tha = arp.sha;
+                     arp.sha = xreg0[0..47];
+                     arp.tpa ->gt;>gt; arp.spa;
+                     outport = inport;
+                     flags.loopback = 1;
+                     output;
+
+
+                     IPv4: For a configured load balancer IPv4 VIP, a  similar
+                     flow  is  added  with the additional match inport == P if
+                     the VIP is reachable from any logical router port of  the
+                     logical router.
+
+                     If  the  router  port  P  is a distributed gateway router
+                     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 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 {
+                         eth.src = xreg0[0..47];
+                         nd.tll = xreg0[0..47];
+                         ip6.src = A;
+                         nd.target = A;
+                         outport = inport;
+                         flags.loopback = 1;
+                         output;
+                     }
+
+
+                     If  the  router  port  P  is a distributed gateway router
+                     port, then the is_chassis_resident(P) is  also  added  in
+                     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
+                     gateway chassis):
+
+                     ā€¢      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 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
+                            rather than the gateway portā€™s Ethernet address E:
+
+                            eth.src = external_mac;
+                            arp.sha = external_mac;
+
+
+                            or in the case of IPv6 neighbor solicition:
+
+                            eth.src = external_mac;
+                            nd.tll = external_mac;
+
+
+                            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
+                     Discovery packets.
+
+              ā€¢      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ā€
+                     fic that is destined to reserved multicast groups.
+
+              ā€¢      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  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 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
+                     offset.
+
+              ā€¢      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
+                     UDP,  TCP,  and ICMP, except in the special case of gateā€
+                     ways, which accept traffic directed to a  router  IP  for
+                     load balancing purposes.
+
+                     These  flows  should  not match IP fragments with nonzero
+                     offset.
+
+              ā€¢      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
+                     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
+                     match  eth.bcast drops traffic destined to the local Ethā€
+                     ernet  broadcast  address.  By  definition  this  traffic
+                     should not be forwarded.
+
+              ā€¢      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. */
+                         icmp4.code = 0;  /* TTL exceeded in transit. */
+                         ip4.dst = ip4.src;
+                         ip4.src = A;
+                         ip.ttl = 254;
+                         next;
+                     };
+                     icmp6 {
+                         icmp6.type = 3; /* Time exceeded. */
+                         icmp6.code = 0;  /* TTL exceeded in transit. */
+                         ip6.dst = ip6.src;
+                         ip6.src = A;
+                         ip.ttl = 254;
+                         next;
+                     };
+
+
+              ā€¢      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
+                     arenā€™t already handled and uses  actions  next;  to  feed
+                     them to the next table.
+
+     Ingress Table 4: UNSNAT
+
+       This  is  for  already  established connectionsā€™ reverse traffic. i.e.,
+       SNAT has already been done in egress pipeline and now  the  packet  has
+       entered the ingress pipeline as part of a reply. It is unSNATted here.
+
+       Ingress Table 4: UNSNAT on Gateway and Distributed Routers
+
+              ā€¢      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
+                     packet to the next table. If the load balancer has protoā€
+                     col port B defined, then the match also has P.dst == B.
+
+                     The above flows are also added for IPv6 load balancers.
+
+       Ingress Table 4: UNSNAT on Gateway Routers
+
+              ā€¢      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; .
+
+                     If    the    Gateway    router    is    configured   with
+                     lb_force_snat_ip=router_ip then for every logical  router
+                     port  P attached to the Gateway router with the router ip
+                     B, a priority-110 flow is added with the match inport  ==
+                     P  &&&& ip4.dst == B or inport == P &&&& ip6.dst == B with an
+                     action ct_snat; .
+
+                     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
+                     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
+                     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
+                     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ā€
+                     grammed on the gateway chassis.
+
+                     ā€¢      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)
+                             where cr-GW is the chassis resident port of GW.
+
+                     A priority-0 logical flow with match 1 has actions next;.
+
+     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
+       the next table.
+
+       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
+       the ECMP route. So for instance, a route  with  a  destination  routing
+       policy  will  instead match if the source IP address matches the static
+       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
+       sending it to the next table.
+
+       If load balancing rules are configured in OVN_Northbound database for a
+       Gateway  router,  a priority 50 flow that matches icmp || icmp6 with an
+       action of ct_dnat;, this allows potentially  related  ICMP  traffic  to
+       pass through CT.
+
+     Ingress Table 6: Load balancing affinity check
+
+       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 &&&& 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
+
+       Packets enter the pipeline with destination IP address that needs to be
+       DNATted from a virtual IP address to a real IP address. Packets in  the
+       reverse direction needs to be unDNATed.
+
+       Ingress Table 7: Load balancing DNAT rules
+
+       Following  load  balancing  DNAT  flows are added for Gateway router or
+       Router with gateway port. These flows are programmed only on the  gateā€
+       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 &&&& 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
+                     associated to the empty_lb logical flow
+
+              ā€¢      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 &&&& 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; 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
+                     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  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ā€ā€
+                     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, 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,
+                     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 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
+                     there is an additional match ip4.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
+                     matches if source ip is an exempted_ext_ip and the action
+                     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;.
+
+       Ingress Table 7: DNAT on Distributed Routers
+
+       On distributed routers, the DNAT table only handles packets with destiā€
+       nation IP address that needs to be DNATted from a virtual IP address to
+       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,
+                     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
+                     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
+                     on the gateway chassis.
+
+                     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  == 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
+                     matches if source ip is an exempted_ext_ip and the action
+                     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;.
+
+     Ingress Table 8: Load balancing affinity learn
+
+       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
+                     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 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
+                     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ā€ā€
+                     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
+                     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
+                     next table.
+
+                     reg0[5] = put_nd_ra_opts(options);next;
+
+
+                     For a valid IPv6 ND RS packet, this transforms the packet
+                     into  an  IPv6 ND RA reply and sets the RA options to the
+                     packet and stores 1 into  reg0[5].  For  other  kinds  of
+                     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;.
+
+     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
+                     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
+                     reg0[5]   is   set   to  1,  it  means  that  the  action
+                     put_nd_ra_opts was successful.
+
+                     eth.dst = eth.src;
+                     eth.src = E;
+                     ip6.dst = ip6.src;
+                     ip6.src = I;
+                     outport = P;
+                     flags.loopback = 1;
+                     output;
+
+
+                     where E is the MAC address and I is the IPv6  link  local
+                     address of the logical router port.
+
+                     (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;.
+
+     Ingress Table 12: IP Routing Pre
+
+       If a packet arrived at this table from Logical Router Port P which  has
+       options:route_table  value set, a logical flow with match inport == "P"
+       with priority 100  and  action  setting  unique-generated  per-datapath
+       32-bit  value  (non-zero)  in  OVS register 7. This registerā€™s value is
+       checked in next table. If packet didnā€™t  match  any  configured  inport
+       (<lt;main>gt; route table), register 7 value is set to 0.
+
+       This table contains the following logical flows:
+
+              ā€¢      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 =
+                     0; next;.
+
+     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
+       (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
+       (ingress  table  ARP  Request  will generate an ARP request, if needed,
+       with reg0 as the target protocol address and reg1 as the source  protoā€
+       col address).
+
+       For  ECMP routes, i.e. multiple static routes with same policy and preā€
+       fix but different nexthops, the above actions are deferred to next  taā€
+       ble.  This  table, instead, is responsible for determine the ECMP group
+       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
+       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
+       at the ARP/ND Resolution stage.
+
+       This table contains the following logical flows:
+
+              ā€¢      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
+                     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ā€
+                     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 inā€
+                     terested attached logical switches. The flows also decreā€
+                     ment TTL.
+
+              ā€¢      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
+                     configured to flood multicast  traffic  the  packets  are
+                     dropped.
+
+              ā€¢      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
+                     flood multicast traffic the packets are dropped.
+
+              ā€¢      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ā€
+                     lowing actions:
+
+                     ip.ttl--;
+                     reg8[0..15] = 0;
+                     reg0 = G;
+                     reg1 = A;
+                     eth.src = E;
+                     outport = P;
+                     flags.loopback = 1;
+                     next;
+
+
+                     (Ingress table 1 already verified that ip.ttl--; will not
+                     yield a TTL exceeded error.)
+
+                     If  the route has a gateway, G is the gateway IP address.
+                     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ā€
+                     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:
+
+                     ip.ttl--;
+                     reg8[0..15] = 0;
+                     xxreg0 = G;
+                     xxreg1 = A;
+                     eth.src = E;
+                     outport = inport;
+                     flags.loopback = 1;
+                     next;
+
+
+                     (Ingress table 1 already verified that ip.ttl--; will not
+                     yield a TTL exceeded error.)
+
+                     If the route has a gateway, G is the gateway IP  address.
+                     Instead,  if the route is from a configured static route,
+                     G is the next hop IP address. Else it is ip6.dst.
+
+                     If the address A is in the link-local  scope,  the  route
+                     will be limited to sending on the ingress port.
+
+                     For  each  static  route the reg7 == id &&&& is prefixed in
+                     logical flow match portion. For routes  with  route_table
+                     value set a unique non-zero id is used. For routes within
+                     main>gt;>gt; route table (no route table set), this id value is
+                     0.
+
+                     For each connected route (route to the LRPā€™s subnet CIDR)
+                     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)
+                     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 acā€
+                     tions:
+
+                     ip.ttl--;
+                     flags.loopback = 1;
+                     reg8[0..15] = GID;
+                     select(reg8[16..31], MID1, MID2, ...);
+
+
+              ā€¢      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
+
+       This  table  implements  the  second part of IP routing for ECMP routes
+       following the previous table. If a packet matched a ECMP group  in  the
+       previous  table,  this  table matches the group id and member id stored
+       from the previous table, setting reg0 (or xxreg0 for IPv6) to the next-
+       hop IP address (leaving ip4.dst or ip6.dst, the packetā€™s final destinaā€
+       tion, 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 (ingress table ARP Request will generate an ARP request, if
+       needed, with reg0 as the target protocol address and reg1 as the source
+       protocol address).
+
+       This processing is skipped for reply traffic being sent out of an  ECMP
+       route if the route was configured to use symmetric replies.
+
+       This table contains the following logical flows:
+
+              ā€¢      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
+                     GID, a priority-100 flow with match reg8[0..15] == GID &&&&
+                     reg8[16..31] == MID has following actions:
+
+                     [xx]reg0 = G;
+                     [xx]reg1 = A;
+                     eth.src = E;
+                     outport = P;
+
+
+              ā€¢      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ā€ā€
+       cal_Router_Policy table documentation in ovn-nb for supported actions.
+
+              ā€¢      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
+                     defined,  then the logical flow is added with the followā€
+                     ing actions:
+
+                     reg8[0..15] = GID;
+                     reg8[16..31] = select(1,..n);
+
+
+                     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
+                     next stage.
+
+              ā€¢      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;
+                     outport = P;
+                     reg8[0..15] = 0;
+                     flags.loopback = 1;
+                     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
+                     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
+                     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
+       multiple nexthops.
+
+              ā€¢      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ā€
+                     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
+                     the flow:
+
+                     [xx]reg0 = H;
+                     eth.src = E;
+                     outport = P
+                     "flags.loopback = 1; "
+                     "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
+                     router port from which the nexthop is reachable.
+
+              ā€¢      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
+       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
+                     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
+                     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.  (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 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ā€
+                     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ā€
+                     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
+                     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, 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 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ā€ā€
+                     cal_port column of NAT table, a priority-90 flow with the
+                     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
+                     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 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 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  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
+                     where the binding is not yet known.)
+
+                     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
+                     get_nd(outport, xxreg0); next;.
+
+              ā€¢      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.
+
+     Ingress Table 18: Check packet length
+
+       For  distributed  logical  routers or gateway routers with gateway port
+       configured with options:gateway_mtu to a valid integer value, this  taā€
+       ble  adds  a priority-50 logical flow with the match outport == GW_PORT
+       where GW_PORT is  the  gateway  router  port  and  applies  the  action
+       check_pkt_larger and advances the packet to the next table.
+
+       REGBIT_PKT_LARGER = check_pkt_larger(L); next;
+
+
+       where L is the packet length to check for. If the packet is larger than
+       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 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
+       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
+       action for ipv4 and ipv6 respectively:
+
+       icmp4 {
+           icmp4.type = 3; /* Destination Unreachable. */
+           icmp4.code = 4;  /* Frag Needed and DF was Set. */
+           icmp4.frag_mtu = M;
+           eth.dst = E;
+           ip4.dst = ip4.src;
+           ip4.src = I;
+           ip.ttl = 255;
+           REGBIT_EGRESS_LOOPBACK = 1;
+           REGBIT_PKT_LARGER = 0;
+           next(pipeline=ingress, table=0);
+       };
+       icmp6 {
+           icmp6.type = 2;
+           icmp6.code = 0;
+           icmp6.frag_mtu = M;
+           eth.dst = E;
+           ip6.dst = ip6.src;
+           ip6.src = I;
+           ip.ttl = 255;
+           REGBIT_EGRESS_LOOPBACK = 1;
+           REGBIT_PKT_LARGER = 0;
+           next(pipeline=ingress, table=0);
+       };
+
+
+              ā€¢      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.
+
+              ā€¢      I is the IPv4/IPv6 address of the logical router port.
+
+       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.
+       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  &&
+                     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
+                     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
+                     chassisredirect port representing  the  instance  of  the
+                     logical  router  distributed  gateway port on the gateway
+                     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
+                     similar flow is added for IPv6 traffic.
+
+              ā€¢      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ā€
+                     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ā€ā€
+                     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;.
+
+     Ingress Table 21: ARP Request
+
+       In the common case where the Ethernet destination  has  been  resolved,
+       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
+                     with match eth.dst == 00:00:00:00:00:00 has the following
+                     actions:
+
+                     arp {
+                         eth.dst = ff:ff:ff:ff:ff:ff;
+                         arp.spa = reg1;
+                         arp.tpa = reg0;
+                         arp.op = 1;  /* ARP request. */
+                         output;
+                     };
+
+
+                     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 acā€
+                     tions is added:
+
+                     nd_ns {
+                         eth.dst = E;
+                         ip6.dst = I
+                         nd.target = G;
+                         output;
+                     };
+
+
+                     Where E is the multicast mac derived from the Gateway IP,
+                     I is the solicited-node multicast  address  corresponding
+                     to the target address G.
+
+                     Unknown MAC address. A priority-100 flow for IPv6 packets
+                     with match eth.dst == 00:00:00:00:00:00 has the following
+                     actions:
+
+                     nd_ns {
+                         nd.target = xxreg0;
+                         output;
+                     };
+
+
+                     (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
+                     dropped.
+
+              ā€¢      Known MAC address. A priority-0 flow with match 1 has acā€
+                     tions output;.
+
+     Egress Table 0: Check DNAT local
+
+       This table checks if the packet  needs  to  be  DNATed  in  the  router
+       ingress  table  lr_in_dnat  after  it  is SNATed and looped back to the
+       ingress pipeline. This check is done only for routers  configured  with
+       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.
+
+              ā€¢      A priority-0 logical flow with match 1 has  actions  REGā€ā€
+                     BIT_DST_NAT_IP_LOCAL = 0; next;.
+
+     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ā€
+       NATed here.
+
+              ā€¢      A priority-0 logical flow with match 1 has actions next;.
+
+     Egress Table 1: UNDNAT on Gateway Routers
+
+              ā€¢      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  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;.
+                     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.
+
+                     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 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;.
+
+     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ā€
+                     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
+                     to go through conntrack.
+
+       Egress Table 3: SNAT on Gateway Routers
+
+              ā€¢      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 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
+                     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
+                     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  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  ==  alā€
+                     lowed_ext_ips.
+
+              ā€¢      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
+                     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;.
+
+       Egress Table 3: SNAT on Distributed Routers
+
+              ā€¢      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, two
+                     flows are added. The priority P of these flows are calcuā€
+                     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
+                     to be run first.
+
+                     ā€¢      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(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,
+                     then  there  is an additional action (for both the flows)
+                     eth.src = EA;, where EA is the ethernet  address  associā€
+                     ated  with  the IP address A in the NAT rule. This allows
+                     upstream MAC learning to point to the correct chassis.
+
+                     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  == 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;.
+
+     Egress Table 4: Post SNAT
+
+       Packets reaching this table are processed according to the flows below:
+
+              ā€¢      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.
+
+       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
+       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
+                     distributed  router,  a  priority-100  logical  flow with
+                     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
+                     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 following actions:
+
+                     clone {
+                         ct_clear;
+                         inport = outport;
+                         outport = "";
+                         flags = 0;
+                         flags.loopback = 1;
+                         reg0 = 0;
+                         reg1 = 0;
+                         ...
+                         reg9 = 0;
+                         REGBIT_EGRESS_LOOPBACK = 1;
+                         next(pipeline=ingress, table=0);
+                     };
+
+
+                     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 adā€
+                     dress check against the router address.
+
+              ā€¢      A priority-0 logical flow with match 1 has actions next;.
+
+     Egress Table 6: Delivery
+
+       Packets that reach this table are ready for delivery. It contains:
+
+              ā€¢      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 enā€
+                     abled logical router port, with action output;.
+
+              ā€¢      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ā€ā€
+       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,
+       obs_point=@cookie) action, where:
+
+              ā€¢      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
+                     the datapathā€™s tunnel key.
+
+OVN 23.06.3                       ovn-northd                     ovn-northd(8)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-northd.8.pdf b/src/static/support/dist-docs-branch-23.06/ovn-northd.8.pdf new file mode 100644 index 00000000..f4d2c323 Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-northd.8.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-northd.8.txt b/src/static/support/dist-docs-branch-23.06/ovn-northd.8.txt new file mode 100644 index 00000000..51b3aa1b --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-northd.8.txt @@ -0,0 +1,3723 @@ +ovn-northd(8) OVN Manual ovn-northd(8) + +NAME + ovn-northd and ovn-northd-ddlog - 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 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 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 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 opā€ + tion 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 + 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 + cost of increasing CPU usage). + + This option will cause ovn-northd to use N threads when building + logical flows, when N is within [2-256]. If N is 1, parallelizaā€ + tion is disabled (default behavior). If N is less than 1, then N + is set to 1, parallelization is disabled and a warning is + logged. If N is more than 256, then N is set to 256, paralā€ + 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 + specified, or if it does not begin with /, then it is created in + . + + If --pidfile is not specified, no pidfile is created. + + --overwrite-pidfile + 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. + + 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 + 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 + 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ā€ā€ + 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ā€ + tions without it. + + --no-chdir + 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. + + 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- + 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. + + --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 + 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 + 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 + 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 + 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 + 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, 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 + 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 + definition of each log level. + + Case is not significant within spec. + + 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 + word but has no effect. + + -v + --verbose + 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-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, + local4, local5, local6 or local7. If this option is not specified, + 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 + 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. + + --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ā€ + name. + + --syslog-method=method + 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 + /dev/log UNIX domain socket. + + ā€¢ 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 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 + to the Northbound and Southbound databases. + + -p privkey.pem + --private-key=privkey.pem + 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ā€ + 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 + 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 + verify the certificate specified on -c or --certificate, or + 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 + trusted hosts. + + 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 + 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ā€ + agement commands. A file is created in the absolute path as + pointed by socket or if --unixctl is not used at all, a file is + created as program in the configured OVS_RUNDIR directory. The + file exists just to mimic the behavior of a Unix domain socket. + + Specifying none for socket disables the control socket feature. + + + + -h + --help + Prints a brief help message to the console. + + -V + --version + Prints version information to the console. + +RUNTIME MANAGEMENT COMMANDS + ovs-appctl can send commands to a running ovn-northd process. The curā€ + rently supported commands are described below. + + exit Causes ovn-northd to gracefully terminate. + + 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 + paused ovn-northd also drops database locks, which allows + any other non-paused instance of ovn-northd to take over. + + resume Resumes the ovn-northd operation to process Northbound + and Southbound database contents and generate logical + flows. This will also instruct ovn-northd to aspire for + the lock on SB DB. + + is-paused + Returns "true" if ovn-northd is currently paused, "false" + otherwise. + + 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. + + sb-cluster-state-reset + Reset southbound database cluster status when databases + are destroyed and rebuilt. + + If all databases in a clustered southbound database are + removed from disk, then the stored index of all databases + will be reset to zero. This will cause ovn-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 + are destroyed and rebuilt. + + 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 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 + flows. + + inc-engine/show-stats + Display ovn-northd engine counters. For each engine node + the following counters have been added: + + ā€¢ recompute + + ā€¢ compute + + ā€¢ 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 + 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 enā€ + abled (even if it was later disabled), the output also inā€ + cludes a CPU time profile. See Profiling inside the tutorā€ + ial 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 + 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 + active and multiple passive ovsdb-servers. + + ā€¢ 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, 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 + 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 + ovn-northd does this for switch and router logical datapaths. + + Logical Switch Datapaths + Ingress Table 0: Admission Control and Ingress Port Security check + + Ingress table 0 contains these logical flows: + + ā€¢ 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 + 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 acā€ + tion next(pipeline=ingress, table=S_SWITCH_IN_L2_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ā€ā€ + BIT_PORT_SEC_DROP" = check_in_port_sec(); next; to evaluā€ + 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 + + 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 + register bit REGBIT_PORT_SEC_DROP is set to 1. + + ā€¢ 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 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 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 + action reg0[11] = lookup_fdb(inport, eth.src); + next; + + ā€¢ 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 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 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 && + 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 adā€ + vances the packet to the next table. + + ā€¢ One priority-0 fallback flow that matches all packets and + advances to the next table. + + Ingress Table 4: from-lport Pre-ACLs + + This table prepares flows for possible stateful ACL processing in + 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 "alā€ + low-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ā€ + umn of NB_Global table. + + Ingress Table 5: Pre-LB + + This table prepares flows for possible stateful load balancing processā€ + ing in ingress table LB and Stateful. 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. 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 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 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 + cases where a logical switch doesnā€™t have any ACLs with allow-related + 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 + 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 + the backend lport sends an invalid TCP packet (like incorrect sequence + number), the packet gets delivered to the lport ā€™p1ā€™ without unDNATing + the packet to the VIP - 10.0.0.10. And this causes the connection to be + reset by the lport p1ā€™s VIF. + + We canā€™t fix this issue by adding a logical flow to drop ct.inv packets + in the egress pipeline since it will drop all other connections not + destined to the load balancers. To fix this issue, we send all the + packets to the conntrack in the ingress pipeline if a load balancer is + configured. We can now add a lflow to drop ct.inv packets. + + This table also has priority-120 flows that punt all IGMP/MLD packets + to ovn-controller if the switch is an interconnect switch with multiā€ + cast snooping enabled. + + 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ā€ + umn of NB_Global table. + + 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 + connection tracking of packets which enter from logical router datapath + to logical switch datapath. + + Ingress Table 6: Pre-stateful + + This table prepares flows for all possible stateful processing in next + 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 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 + reg2. For IPv6 traffic the flows also load the original + 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 + 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 + tracker based on a hint provided by the previous tables + (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 + same packet. The possible hints are: + + ā€¢ 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ā€ + ntrack because it already exists. + + ā€¢ reg0[9]: the packet might match a drop/reject. + + ā€¢ 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 + 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 + advances to the next table. + + ā€¢ 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 + 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 + next table. + + ā€¢ 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 + reg0[10] and then advances to the next table. + + ā€¢ 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 + 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 + 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 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 + room for OVN default flows at both higher and lower priorities. + + ā€¢ 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. + + ā€¢ 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: + + ā€¢ 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 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-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 + 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 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 + 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 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ā€ + tioned in the QoS table. + + ā€¢ One priority-0 fallback flow that matches all packets and + advances to the next table. + + 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 + 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-100 flow is added. For IPv4 VIPs, the flow matches + ct.new && ip && ip4.dst == VIP && P.dst == PORT. For IPv6 + VIPs, the flow matches ct.new && ip && ip6.dst == VIP&& P + && 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 + and applies the action next;. + + Ingress Table 13: LB + + ā€¢ 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 + 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 + 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 && + ip4.dst == VIP && P.dst == PORT. For IPv6 VIPs, the flow + matches ct.new && ip && ip6.dst == VIP && P && P.dst == + 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 + 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 + 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. + + ā€¢ 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 reā€ + ceived for this load-balancer. Please note using --reject + option will disable empty_lb SB controller event for this + load balancer. + + Ingress Table 14: Load balancing affinity learn + + 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 + 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 + reg9[6] == 0 && ct.new && ip && ip4.dst == VIP && P.dst + == PORT. For IPv6 VIPs, the flow matches ct.new && ip && + ip6.dst == VIP && P && P.dst == PORT . The flowā€™s action + 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 + and applies the action next;. + + Ingress Table 15: Pre-Hairpin + + ā€¢ 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 + source IP) or not by executing the actions reg0[6] = + 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 + table. + + Ingress Table 16: Nat-Hairpin + + ā€¢ 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, + 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, + 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 + to the next table. + + ā€¢ A priority-0 flow that simply moves traffic to the next + table. + + 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) + + 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. + + ā€¢ 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- + 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 + 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 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 + by locally responding to ARP requests without the need to send to other + hypervisors. One common case is when the inport is a logical port assoā€ + ciated with a VIF and the broadcast is responded to on the local hyperā€ + 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 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. + 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 + rare. + + 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 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: + + ā€¢ 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 + + inport == P && && ((arp.op == 1 && arp.spa == VIP && arp.tpa == VIP) || (arp.op == 2 && arp.spa == VIP)) + inport == P && && ((nd_ns && ip6.dst == {VIP, NS_MULTICAST_ADDR} && nd.target == VIP) || (nd_na && nd.target == VIP)) + + + and applies the action + + bind_vport(V, inport); + + + and advances the packet to the next table. + + 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 + IP address A of every logical switch port, and respond + with ARP replies directly with corresponding Ethernet adā€ + dress E: + + eth.dst = eth.src; + eth.src = E; + arp.op = 2; /* ARP reply. */ + arp.tha = arp.sha; + arp.sha = E; + arp.tpa = arp.spa; + arp.spa = A; + outport = inport; + flags.loopback = 1; + 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 + of NB_Global table of the Northbound database), for logiā€ + 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 + IPv4 addresses if defined in options:arp_proxy column of + Logical_Switch_Port table for logical switch ports of + type router. + + ā€¢ 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 + with corresponding Ethernet address E: + + nd_na { + eth.src = E; + ip6.src = A; + nd.target = A; + nd.tll = E; + outport = inport; + flags.loopback = 1; + output; + }; + + + 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 { + eth.src = E; + ip6.src = A; + nd.target = A; + nd.tll = E; + outport = inport; + flags.loopback = 1; + 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 + of NB_Global table of the Northbound database), for logiā€ + 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 + 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 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; + 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ā€ + 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 + the action + + eth.dst = eth.src; + eth.src = E; + arp.op = 2; /* ARP reply. */ + arp.tha = arp.sha; + arp.sha = E; + arp.tpa = arp.spa; + arp.spa = A; + outport = inport; + flags.loopback = 1; + output; + + + 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. + + SVC_MON_SRC_IP is used as the source ip in the service + monitor IPv4 packets for the load balancer endpoint IP + health checks. + + These flows are required if an ARP request is sent for + the IP SVC_MON_SRC_IP. + + 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 + + eth.dst = eth.src; + eth.src = E; + arp.op = 2; /* ARP reply. */ + arp.tha = arp.sha; + arp.sha = E; + arp.tpa = arp.spa; + arp.spa = A; + outport = inport; + flags.loopback = 1; + output; + + + where E is the forwarding groupā€™s mac defined in the + vmac. + + A is used as either the destination ip for load balancing + traffic to child ports or as nexthop to hosts behind the + child ports. + + 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 + advances to the next table. + + 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 + ports which matches the IPv4 packet with udp.src = 68 and + 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; + + + For DHCPDISCOVER and DHCPREQUEST, this transforms the + packet into a DHCP reply, adds the DHCP offer IP ip and + options to the packet, and stores 1 into reg0[3]. For + 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 + 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. + + reg0[3] = put_dhcpv6_opts(ia_addr = ip, options...); + next; + + + For DHCPv6 Solicit/Request/Confirm packets, this transā€ + forms the packet into a DHCPv6 Advertise/Reply, adds the + DHCPv6 offer IP ip and options to the packet, and stores + 1 into reg0[3]. For other kinds of packets, it just + stores 0 into reg0[3]. Either way, it continues to the + next table. + + ā€¢ A priority-0 flow that matches all packets to advances to + table 16. + + Ingress Table 23: DHCP responses + + 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 + 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 + put_dhcp_opts was successful. + + eth.dst = eth.src; + eth.src = E; + ip4.src = S; + udp.src = 67; + udp.dst = 68; + outport = P; + flags.loopback = 1; + output; + + + 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 + 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] + == 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. + + eth.dst = eth.src; + eth.src = E; + ip6.dst = A; + ip6.src = S; + udp.src = 547; + udp.dst = 546; + outport = P; + flags.loopback = 1; + 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 + the logical portā€™s addresses column. + + (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 + table 17. + + 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 + the action dns_lookup and advances the packet to the next + table. + + reg0[4] = dns_lookup(); next; + + + 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 + continues to the next table. + + Ingress Table 25 DNS Responses + + This table implements DNS responder for the DNS replies generated by + the previous table. + + ā€¢ 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 + actions. If reg0[4] is set to 1, it means that the action + dns_lookup was successful. + + eth.dst <-> eth.src; + ip4.src <-> ip4.dst; + udp.dst = udp.src; + udp.src = 53; + outport = P; + flags.loopback = 1; + output; + + + (This terminates ingress packet processing; the packet + does not go to the next ingress table.) + + 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 + switch) which matches on the inport of the external logiā€ + 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. + All the other chassis, drops these packets. + + 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 == 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 + table 20. + + Ingress Table 27 Destination Lookup + + 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ā€ā€ + 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 + ovn-controller if multicast snooping is enabled on the + logical switch. + + ā€¢ 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 + multicast group, which ovn-nortdh populates with all the + logical ports that are connected to logical routers with + options:mcast_relay=ā€™trueā€™. + + ā€¢ 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 enā€ + abled logical ports. + + ā€¢ 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 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 + router that owns the IP address and to the MC_FLOOD_L2 + 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 reā€ + quest/ND packets. These packets are flooded to the + MC_FLOOD_L2 which contains all non-router logical ports. + + ā€¢ 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 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 + has a gateway chassis: + + ā€¢ 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 + 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 to which the connected logical router port belongs + to has a distributed gateway LRP: + + ā€¢ 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 + 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 + 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 + it stores none in the outport. + + 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 + contains the following flows. + + ā€¢ 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ā€™ + 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 + group, which ovn-northd populates with all enabled + logical ports that accept unknown destination + packets. As a small optimization, if no logical + ports accept unknown destination packets, + ovn-northd omits this multicast group and logical + flow. + + 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 + and drops the packets. + + ā€¢ 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 + + This is similar to ingress table Pre-ACLs except for to-lport 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ā€ + 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. 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 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 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ā€ + 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 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 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; acā€ + tion. + + ā€¢ 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 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]. + + 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 + port which has DHCPv4 options defined to allow the DHCPv4 + 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 + match udp.dst = 53 to allow the DNS reply packet from the + 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ā€ā€ + 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. This is indicated by setting the allow + bit. + + Egress Table 5: to-lport ACL action + + 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 7: to-lport QoS Meter + + This is similar to ingress table QoS meter except they apply to + to-lport QoS rules. + + 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 9: Egress Port Security - check + + 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ā€ + 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 + 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 + on the addresses defined in the port_security column of + Logical_Switch_Port table before delivering the packet to + the outport. + + Egress Table 10: Egress Port Security - Apply + + 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ā€ā€ + BIT_PORT_SEC_DROP is set to 1. + + The following flows are added. + + ā€¢ 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;". + + 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 + bit REGBIT_PORT_SEC_DROP is set to 1. + + ā€¢ 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 + OVN_Northbound database that do not have enabled set to false + + Ingress Table 0: L2 Admission Control + + 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ā€ + ticast Ethernet source addresses. + + ā€¢ 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; + 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 + 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 + reach LR services (LBs, NAT). + + 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: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 + already handled (match 1) and drops them (action drop;). + + Other packets are implicitly dropped. + + Ingress Table 1: Neighbor lookup + + For ARP and IPv6 Neighbor Discovery packets, this table looks into the + 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 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: + + reg9[2] = lookup_arp(inport, arp.spa, arp.sha); + next; + + + If the option always_learn_from_arp_request is false, the + 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 reā€ + quest) with the following actions: + + reg9[2] = lookup_arp(inport, arp.spa, arp.sha); + reg9[3] = 1; + next; + + + A priority-100 flow is added which matches inport == P && + arp.spa == S/L && arp.op == 1 (ARP request) with the folā€ + lowing actions: + + reg9[2] = lookup_arp(inport, arp.spa, arp.sha); + reg9[3] = lookup_arp_ip(inport, arp.spa); + next; + + + If the logical router port P is a distributed gateway + 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 alā€ā€ + ways_learn_from_arp_request is true: + + reg9[2] = lookup_arp(inport, arp.spa, arp.sha); + next; + + + If the option always_learn_from_arp_request is false, the + above actions will be: + + reg9[2] = lookup_arp(inport, arp.spa, arp.sha); + reg9[3] = 1; + next; + + + ā€¢ 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); + next; + + + If the option always_learn_from_arp_request is false, the + above actions will be: + + reg9[2] = lookup_nd(inport, nd.target, nd.tll); + reg9[3] = 1; + next; + + + ā€¢ 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: + + reg9[2] = lookup_nd(inport, ip6.src, nd.sll); + next; + + + If the option always_learn_from_arp_request is false, the + above actions will be: + + reg9[2] = lookup_nd(inport, ip6.src, nd.sll); + reg9[3] = lookup_nd_ip(inport, ip6.src); + next; + + + ā€¢ A priority-0 fallback flow that matches all packets and + applies the action reg9[2] = 1; next; advancing the + packet to the next table. + + Ingress Table 2: Neighbor learning + + This table adds flows to learn the mac bindings from the ARP and IPv6 + Neighbor Solicitation/Advertisement packets if it is needed according + 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 + 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 || + 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 + || nd.sll == 0) and applies the action 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 + and applies the action put_nd(inport, nd.target, + eth.src); next; + + ā€¢ 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 + action put_nd(inport, ip6.src, nd.sll); next; + + ā€¢ 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ā€ + 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 acā€ + tion for ipv4 and ipv6 respectively: + + icmp4_error { + icmp4.type = 3; /* Destination Unreachable. */ + icmp4.code = 4; /* Frag Needed and DF was Set. */ + icmp4.frag_mtu = M; + eth.dst = eth.src; + eth.src = E; + ip4.dst = ip4.src; + ip4.src = I; + ip.ttl = 255; + REGBIT_EGRESS_LOOPBACK = 1; + REGBIT_PKT_LARGER 0; + outport = LRP; + flags.loopback = 1; + output; + }; + icmp6_error { + icmp6.type = 2; + icmp6.code = 0; + icmp6.frag_mtu = M; + eth.dst = eth.src; + eth.src = E; + ip6.dst = ip6.src; + ip6.src = I; + ip.ttl = 255; + REGBIT_EGRESS_LOOPBACK = 1; + REGBIT_PKT_LARGER 0; + outport = LRP; + flags.loopback = 1; + output; + }; + + + 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 apā€ + plies the following action for ipv4 and ipv6 respecā€ + tively: + + icmp4_error { + icmp4.type = 3; /* Destination Unreachable. */ + icmp4.code = 4; /* Frag Needed and DF was Set. */ + icmp4.frag_mtu = M; + eth.dst = E; + ip4.dst = ip4.src; + ip4.src = I; + ip.ttl = 255; + REGBIT_EGRESS_LOOPBACK = 1; + REGBIT_PKT_LARGER 0; + next(pipeline=ingress, table=0); + }; + icmp6_error { + icmp6.type = 2; + icmp6.code = 0; + icmp6.frag_mtu = M; + eth.dst = E; + ip6.dst = ip6.src; + ip6.src = I; + ip.ttl = 255; + REGBIT_EGRESS_LOOPBACK = 1; + REGBIT_PKT_LARGER 0; + next(pipeline=ingress, table=0); + }; + + + ā€¢ 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 + ip6.src is used for the match. + + 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 + 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 + 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ā€ā€ + 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 opā€ā€ + tions :mcast_flood=ā€ā€™trueā€ā€™. + + ā€¢ L3 admission control: A priority-100 flow drops packets + that match any of the following: + + ā€¢ ip4.src[28..31] == 0xe (multicast source) + + ā€¢ ip4.src == 255.255.255.255 (broadcast source) + + ā€¢ 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 + 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ā€ā€ + BIT_EGRESS_LOOPBACK. + + ā€¢ ip4.src is the broadcast address of any IP network + known to the router. + + ā€¢ 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 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; + ip.ttl = 255; + icmp4.type = 0; + flags.loopback = 1; + next; + + + Flows for ICMPv6 echo requests use the following actions: + + ip6.dst <-> ip6.src; + ip.ttl = 255; + icmp6.type = 129; + flags.loopback = 1; + next; + + + ā€¢ 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 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 == + P && arp.spa == S/L && arp.op == 1 && arp.tpa == A (ARP + request) with the following actions: + + eth.dst = eth.src; + eth.src = xreg0[0..47]; + arp.op = 2; /* ARP reply. */ + arp.tha = arp.sha; + arp.sha = xreg0[0..47]; + arp.tpa = arp.spa; + arp.spa = A; + outport = inport; + flags.loopback = 1; + output; + + + For the gateway port on a distributed logical router + (where one of the logical router ports specifies a gateā€ + way chassis), the above flows are only programmed on the + gateway port instance on the gateway chassis. This behavā€ + ior avoids generation of multiple ARP responses from difā€ + ferent chassis, and allows upstream MAC learning to point + to the gateway chassis. + + 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, 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 { + eth.src = xreg0[0..47]; + ip6.src = A; + nd.target = A; + nd.tll = xreg0[0..47]; + outport = inport; + flags.loopback = 1; + output; + }; + + + 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 + router for NAT (both DNAT and SNAT) or load balancing. + + 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]; + arp.op = 2; /* ARP reply. */ + arp.tha = arp.sha; + arp.sha = xreg0[0..47]; + arp.tpa <-> arp.spa; + outport = inport; + flags.loopback = 1; + output; + + + IPv4: For a configured load balancer IPv4 VIP, a similar + flow is added with the additional match inport == P if + the VIP is reachable from any logical router port of the + logical router. + + If the router port P is a distributed gateway router + 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 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 { + eth.src = xreg0[0..47]; + nd.tll = xreg0[0..47]; + ip6.src = A; + nd.target = A; + outport = inport; + flags.loopback = 1; + output; + } + + + If the router port P is a distributed gateway router + port, then the is_chassis_resident(P) is also added in + 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 + gateway chassis): + + ā€¢ 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 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 + rather than the gateway portā€™s Ethernet address E: + + eth.src = external_mac; + arp.sha = external_mac; + + + or in the case of IPv6 neighbor solicition: + + eth.src = external_mac; + nd.tll = external_mac; + + + 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 + Discovery packets. + + ā€¢ 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ā€ + fic that is destined to reserved multicast groups. + + ā€¢ 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 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 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 + offset. + + ā€¢ 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 + UDP, TCP, and ICMP, except in the special case of gateā€ + ways, which accept traffic directed to a router IP for + load balancing purposes. + + These flows should not match IP fragments with nonzero + offset. + + ā€¢ 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 + 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 + match eth.bcast drops traffic destined to the local Ethā€ + ernet broadcast address. By definition this traffic + should not be forwarded. + + ā€¢ 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. */ + icmp4.code = 0; /* TTL exceeded in transit. */ + ip4.dst = ip4.src; + ip4.src = A; + ip.ttl = 254; + next; + }; + icmp6 { + icmp6.type = 3; /* Time exceeded. */ + icmp6.code = 0; /* TTL exceeded in transit. */ + ip6.dst = ip6.src; + ip6.src = A; + ip.ttl = 254; + next; + }; + + + ā€¢ 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 + arenā€™t already handled and uses actions next; to feed + them to the next table. + + Ingress Table 4: UNSNAT + + This is for already established connectionsā€™ reverse traffic. i.e., + SNAT has already been done in egress pipeline and now the packet has + entered the ingress pipeline as part of a reply. It is unSNATted here. + + Ingress Table 4: UNSNAT on Gateway and Distributed Routers + + ā€¢ 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 + packet to the next table. If the load balancer has protoā€ + col port B defined, then the match also has P.dst == B. + + The above flows are also added for IPv6 load balancers. + + Ingress Table 4: UNSNAT on Gateway Routers + + ā€¢ 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; . + + If the Gateway router is configured with + lb_force_snat_ip=router_ip then for every logical router + port P attached to the Gateway router with the router ip + B, a priority-110 flow is added with the match inport == + P && ip4.dst == B or inport == P && ip6.dst == B with an + action ct_snat; . + + 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 + 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 + 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 + 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ā€ + grammed on the gateway chassis. + + ā€¢ 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) + where cr-GW is the chassis resident port of GW. + + A priority-0 logical flow with match 1 has actions next;. + + 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 + the next table. + + 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 + the ECMP route. So for instance, a route with a destination routing + policy will instead match if the source IP address matches the static + 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 + sending it to the next table. + + If load balancing rules are configured in OVN_Northbound database for a + Gateway router, a priority 50 flow that matches icmp || icmp6 with an + action of ct_dnat;, this allows potentially related ICMP traffic to + pass through CT. + + Ingress Table 6: Load balancing affinity check + + 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 && 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 + + Packets enter the pipeline with destination IP address that needs to be + DNATted from a virtual IP address to a real IP address. Packets in the + reverse direction needs to be unDNATed. + + Ingress Table 7: Load balancing DNAT rules + + Following load balancing DNAT flows are added for Gateway router or + Router with gateway port. These flows are programmed only on the gateā€ + 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 && 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 + associated to the empty_lb logical flow + + ā€¢ 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 && 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; 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 + 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 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ā€ā€ + 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, 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, + 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 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 + there is an additional match ip4.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 + matches if source ip is an exempted_ext_ip and the action + 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;. + + Ingress Table 7: DNAT on Distributed Routers + + On distributed routers, the DNAT table only handles packets with destiā€ + nation IP address that needs to be DNATted from a virtual IP address to + 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, + 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 + 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 + on the gateway chassis. + + 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 == 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 + matches if source ip is an exempted_ext_ip and the action + 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;. + + Ingress Table 8: Load balancing affinity learn + + 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 + 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 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 + 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ā€ā€ + 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 + 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 + next table. + + reg0[5] = put_nd_ra_opts(options);next; + + + For a valid IPv6 ND RS packet, this transforms the packet + into an IPv6 ND RA reply and sets the RA options to the + packet and stores 1 into reg0[5]. For other kinds of + 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;. + + 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 + 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 + reg0[5] is set to 1, it means that the action + put_nd_ra_opts was successful. + + eth.dst = eth.src; + eth.src = E; + ip6.dst = ip6.src; + ip6.src = I; + outport = P; + flags.loopback = 1; + output; + + + where E is the MAC address and I is the IPv6 link local + address of the logical router port. + + (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;. + + Ingress Table 12: IP Routing Pre + + If a packet arrived at this table from Logical Router Port P which has + options:route_table value set, a logical flow with match inport == "P" + with priority 100 and action setting unique-generated per-datapath + 32-bit value (non-zero) in OVS register 7. This registerā€™s value is + checked in next table. If packet didnā€™t match any configured inport + (
route table), register 7 value is set to 0. + + This table contains the following logical flows: + + ā€¢ 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 = + 0; next;. + + 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 + (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 + (ingress table ARP Request will generate an ARP request, if needed, + with reg0 as the target protocol address and reg1 as the source protoā€ + col address). + + For ECMP routes, i.e. multiple static routes with same policy and preā€ + fix but different nexthops, the above actions are deferred to next taā€ + ble. This table, instead, is responsible for determine the ECMP group + 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 + 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 + at the ARP/ND Resolution stage. + + This table contains the following logical flows: + + ā€¢ 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 + 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ā€ + 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 inā€ + terested attached logical switches. The flows also decreā€ + ment TTL. + + ā€¢ 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 + configured to flood multicast traffic the packets are + dropped. + + ā€¢ 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 + flood multicast traffic the packets are dropped. + + ā€¢ 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ā€ + lowing actions: + + ip.ttl--; + reg8[0..15] = 0; + reg0 = G; + reg1 = A; + eth.src = E; + outport = P; + flags.loopback = 1; + next; + + + (Ingress table 1 already verified that ip.ttl--; will not + yield a TTL exceeded error.) + + If the route has a gateway, G is the gateway IP address. + 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ā€ + 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: + + ip.ttl--; + reg8[0..15] = 0; + xxreg0 = G; + xxreg1 = A; + eth.src = E; + outport = inport; + flags.loopback = 1; + next; + + + (Ingress table 1 already verified that ip.ttl--; will not + yield a TTL exceeded error.) + + If the route has a gateway, G is the gateway IP address. + Instead, if the route is from a configured static route, + G is the next hop IP address. Else it is ip6.dst. + + If the address A is in the link-local scope, the route + will be limited to sending on the ingress port. + + For each static route the reg7 == id && is prefixed in + logical flow match portion. For routes with route_table + value set a unique non-zero id is used. For routes within +
route table (no route table set), this id value is + 0. + + For each connected route (route to the LRPā€™s subnet CIDR) + 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) + 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 acā€ + tions: + + ip.ttl--; + flags.loopback = 1; + reg8[0..15] = GID; + select(reg8[16..31], MID1, MID2, ...); + + + ā€¢ 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 + + This table implements the second part of IP routing for ECMP routes + following the previous table. If a packet matched a ECMP group in the + previous table, this table matches the group id and member id stored + from the previous table, setting reg0 (or xxreg0 for IPv6) to the next- + hop IP address (leaving ip4.dst or ip6.dst, the packetā€™s final destinaā€ + tion, 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 (ingress table ARP Request will generate an ARP request, if + needed, with reg0 as the target protocol address and reg1 as the source + protocol address). + + This processing is skipped for reply traffic being sent out of an ECMP + route if the route was configured to use symmetric replies. + + This table contains the following logical flows: + + ā€¢ 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 + GID, a priority-100 flow with match reg8[0..15] == GID && + reg8[16..31] == MID has following actions: + + [xx]reg0 = G; + [xx]reg1 = A; + eth.src = E; + outport = P; + + + ā€¢ 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ā€ā€ + cal_Router_Policy table documentation in ovn-nb for supported actions. + + ā€¢ 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 + defined, then the logical flow is added with the followā€ + ing actions: + + reg8[0..15] = GID; + reg8[16..31] = select(1,..n); + + + 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 + next stage. + + ā€¢ 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; + outport = P; + reg8[0..15] = 0; + flags.loopback = 1; + 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 + 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 + 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 + multiple nexthops. + + ā€¢ 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ā€ + 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 + the flow: + + [xx]reg0 = H; + eth.src = E; + outport = P + "flags.loopback = 1; " + "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 + router port from which the nexthop is reachable. + + ā€¢ 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 + 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 + 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 + 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. (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 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ā€ + 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ā€ + 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 + 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, 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 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ā€ā€ + cal_port column of NAT table, a priority-90 flow with the + 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 + 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 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 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 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 + where the binding is not yet known.) + + 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 + get_nd(outport, xxreg0); next;. + + ā€¢ 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. + + Ingress Table 18: Check packet length + + For distributed logical routers or gateway routers with gateway port + configured with options:gateway_mtu to a valid integer value, this taā€ + ble adds a priority-50 logical flow with the match outport == GW_PORT + where GW_PORT is the gateway router port and applies the action + check_pkt_larger and advances the packet to the next table. + + REGBIT_PKT_LARGER = check_pkt_larger(L); next; + + + where L is the packet length to check for. If the packet is larger than + 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 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 + 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 + action for ipv4 and ipv6 respectively: + + icmp4 { + icmp4.type = 3; /* Destination Unreachable. */ + icmp4.code = 4; /* Frag Needed and DF was Set. */ + icmp4.frag_mtu = M; + eth.dst = E; + ip4.dst = ip4.src; + ip4.src = I; + ip.ttl = 255; + REGBIT_EGRESS_LOOPBACK = 1; + REGBIT_PKT_LARGER = 0; + next(pipeline=ingress, table=0); + }; + icmp6 { + icmp6.type = 2; + icmp6.code = 0; + icmp6.frag_mtu = M; + eth.dst = E; + ip6.dst = ip6.src; + ip6.src = I; + ip.ttl = 255; + REGBIT_EGRESS_LOOPBACK = 1; + REGBIT_PKT_LARGER = 0; + next(pipeline=ingress, table=0); + }; + + + ā€¢ 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. + + ā€¢ I is the IPv4/IPv6 address of the logical router port. + + 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. + 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 && + 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 + 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 + chassisredirect port representing the instance of the + logical router distributed gateway port on the gateway + 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 + similar flow is added for IPv6 traffic. + + ā€¢ 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ā€ + 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ā€ā€ + 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;. + + Ingress Table 21: ARP Request + + In the common case where the Ethernet destination has been resolved, + 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 + with match eth.dst == 00:00:00:00:00:00 has the following + actions: + + arp { + eth.dst = ff:ff:ff:ff:ff:ff; + arp.spa = reg1; + arp.tpa = reg0; + arp.op = 1; /* ARP request. */ + output; + }; + + + 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 acā€ + tions is added: + + nd_ns { + eth.dst = E; + ip6.dst = I + nd.target = G; + output; + }; + + + Where E is the multicast mac derived from the Gateway IP, + I is the solicited-node multicast address corresponding + to the target address G. + + Unknown MAC address. A priority-100 flow for IPv6 packets + with match eth.dst == 00:00:00:00:00:00 has the following + actions: + + nd_ns { + nd.target = xxreg0; + output; + }; + + + (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 + dropped. + + ā€¢ Known MAC address. A priority-0 flow with match 1 has acā€ + tions output;. + + Egress Table 0: Check DNAT local + + This table checks if the packet needs to be DNATed in the router + ingress table lr_in_dnat after it is SNATed and looped back to the + ingress pipeline. This check is done only for routers configured with + 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. + + ā€¢ A priority-0 logical flow with match 1 has actions REGā€ā€ + BIT_DST_NAT_IP_LOCAL = 0; next;. + + 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ā€ + NATed here. + + ā€¢ A priority-0 logical flow with match 1 has actions next;. + + Egress Table 1: UNDNAT on Gateway Routers + + ā€¢ 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 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;. + 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. + + 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 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;. + + 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ā€ + 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 + to go through conntrack. + + Egress Table 3: SNAT on Gateway Routers + + ā€¢ 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 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 + 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 + 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 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 == alā€ + lowed_ext_ips. + + ā€¢ 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 + 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;. + + Egress Table 3: SNAT on Distributed Routers + + ā€¢ 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, two + flows are added. The priority P of these flows are calcuā€ + 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 + to be run first. + + ā€¢ 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(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, + then there is an additional action (for both the flows) + eth.src = EA;, where EA is the ethernet address associā€ + ated with the IP address A in the NAT rule. This allows + upstream MAC learning to point to the correct chassis. + + 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 == 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;. + + Egress Table 4: Post SNAT + + Packets reaching this table are processed according to the flows below: + + ā€¢ 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. + + 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 + 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 + distributed router, a priority-100 logical flow with + 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 + 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 following actions: + + clone { + ct_clear; + inport = outport; + outport = ""; + flags = 0; + flags.loopback = 1; + reg0 = 0; + reg1 = 0; + ... + reg9 = 0; + REGBIT_EGRESS_LOOPBACK = 1; + next(pipeline=ingress, table=0); + }; + + + 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 adā€ + dress check against the router address. + + ā€¢ A priority-0 logical flow with match 1 has actions next;. + + Egress Table 6: Delivery + + Packets that reach this table are ready for delivery. It contains: + + ā€¢ 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 enā€ + abled logical router port, with action output;. + + ā€¢ 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ā€ā€ + 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, + obs_point=@cookie) action, where: + + ā€¢ 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 + the datapathā€™s tunnel key. + +OVN 23.06.3 ovn-northd ovn-northd(8) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-sb.5 b/src/static/support/dist-docs-branch-23.06/ovn-sb.5 new file mode 100644 index 00000000..edae70f6 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-sb.5 @@ -0,0 +1,3514 @@ +'\" p +.\" -*- nroff -*- +.TH "ovn-sb" 5 " DB Schema 20.27.2" "Open vSwitch 23.06.3" "Open vSwitch Manual" +.fp 5 L CR \\" Make fixed-width font available as \\fL. +.de TQ +. br +. ns +. TP "\\$1" +.. +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +.SH NAME +ovn-sb \- OVN_Southbound database schema +.PP +.PP +.PP +.PP +This database holds logical and physical configuration and state for the Open Virtual Network (OVN) system to support virtual network abstraction\[char46] For an introduction to OVN, please see \fBovn\-architecture\fR(7)\[char46] +.PP +.PP +The OVN Southbound database sits at the center of the OVN architecture\[char46] It is the one component that speaks both southbound directly to all the hypervisors and gateways, via \fBovn\-controller\fR/\fBovn\-controller\-vtep\fR, and northbound to the Cloud Management System, via \fBovn\-northd\fR: +.SS "Database Structure" +.PP +.PP +The OVN Southbound database contains classes of data with different properties, as described in the sections below\[char46] +.ST "Physical network" +.PP +.PP +Physical network tables contain information about the chassis nodes in the system\[char46] This contains all the information necessary to wire the overlay, such as IP addresses, supported tunnel types, and security keys\[char46] +.PP +.PP +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\[char46] +.PP +.PP +The \fBChassis\fR and \fBEncap\fR tables are the physical network tables\[char46] +.ST "Logical Network" +.PP +.PP +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)\[char46] +.PP +.PP +Logical network data may be large (O(n) in the number of logical ports, ACL rules, etc\[char46])\[char46] Thus, to improve scaling, each chassis should receive only data related to logical networks in which that chassis participates\[char46] +.PP +.PP +The logical network data is ultimately controlled by the cloud management system (CMS) running northbound of OVN\[char46] 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\(cqs configuration, although that happens indirectly via the \fBOVN_Northbound\fR database and \fBovn\-northd\fR\[char46] +.PP +.PP +Logical network data is likely to change more quickly than physical network data\[char46] This is especially true in a container environment where containers are created and destroyed (and therefore added to and deleted from logical switches) quickly\[char46] +.PP +.PP +The \fBLogical_Flow\fR, \fBMulticast_Group\fR, \fBAddress_Group\fR, \fBDHCP_Options\fR, \fBDHCPv6_Options\fR, and \fBDNS\fR tables contain logical network data\[char46] +.ST "Logical-physical bindings" +.PP +.PP +These tables link logical and physical components\[char46] They show the current placement of logical components (such as VMs and VIFs) onto chassis, and map logical entities to the values that represent them in tunnel encapsulations\[char46] +.PP +.PP +These tables change frequently, at least every time a VM powers up or down or migrates, and especially quickly in a container environment\[char46] The amount of data per VM (or VIF) is small\[char46] +.PP +.PP +Each chassis is authoritative about the VMs and VIFs that it hosts at any given time and can efficiently flood that state to a central location, so the consistency needs are minimal\[char46] +.PP +.PP +The \fBPort_Binding\fR and \fBDatapath_Binding\fR tables contain binding data\[char46] +.ST "MAC bindings" +.PP +.PP +The \fBMAC_Binding\fR table tracks the bindings from IP addresses to Ethernet addresses that are dynamically discovered using ARP (for IPv4) and neighbor discovery (for IPv6)\[char46] Usually, IP-to-MAC bindings for virtual machines are statically populated into the \fBPort_Binding\fR table, so \fBMAC_Binding\fR is primarily used to discover bindings on physical networks\[char46] +.SS "Common Columns" +.PP +.PP +Some tables contain a special column named \fBexternal_ids\fR\[char46] This column has the same form and purpose each place that it appears, so we describe it here to save space later\[char46] +.RS +.TP +\fBexternal_ids\fR: map of string-string pairs +Key-value pairs for use by the software that manages the OVN Southbound database rather than by \fBovn\-controller\fR/\fBovn\-controller\-vtep\fR\[char46] In particular, \fBovn\-northd\fR can use key-value pairs in this column to relate entities in the southbound database to higher-level entities (such as entities in the OVN Northbound database)\[char46] Individual key-value pairs in this column may be documented in some cases to aid in understanding and troubleshooting, but the reader should not mistake such documentation as comprehensive\[char46] +.RE +.SH "TABLE SUMMARY" +.PP +The following list summarizes the purpose of each of the tables in the +\fBOVN_Southbound\fR database. Each table is described in more detail on a later +page. +.IP "Table" 1in +Purpose +.TQ 1in +\fBSB_Global\fR +Southbound configuration +.TQ 1in +\fBChassis\fR +Physical Network Hypervisor and Gateway Information +.TQ 1in +\fBChassis_Private\fR +Chassis Private +.TQ 1in +\fBEncap\fR +Encapsulation Types +.TQ 1in +\fBAddress_Set\fR +Address Sets +.TQ 1in +\fBPort_Group\fR +Port Groups +.TQ 1in +\fBLogical_Flow\fR +Logical Network Flows +.TQ 1in +\fBLogical_DP_Group\fR +Logical Datapath Groups +.TQ 1in +\fBMulticast_Group\fR +Logical Port Multicast Groups +.TQ 1in +\fBMirror\fR +Mirror Entry +.TQ 1in +\fBMeter\fR +Meter entry +.TQ 1in +\fBMeter_Band\fR +Band for meter entries +.TQ 1in +\fBDatapath_Binding\fR +Physical-Logical Datapath Bindings +.TQ 1in +\fBPort_Binding\fR +Physical-Logical Port Bindings +.TQ 1in +\fBMAC_Binding\fR +IP to MAC bindings +.TQ 1in +\fBDHCP_Options\fR +DHCP Options supported by native OVN DHCP +.TQ 1in +\fBDHCPv6_Options\fR +DHCPv6 Options supported by native OVN DHCPv6 +.TQ 1in +\fBConnection\fR +OVSDB client connections\[char46] +.TQ 1in +\fBSSL\fR +SSL configuration\[char46] +.TQ 1in +\fBDNS\fR +Native DNS resolution +.TQ 1in +\fBRBAC_Role\fR +RBAC_Role configuration\[char46] +.TQ 1in +\fBRBAC_Permission\fR +RBAC_Permission configuration\[char46] +.TQ 1in +\fBGateway_Chassis\fR +Gateway_Chassis configuration\[char46] +.TQ 1in +\fBHA_Chassis\fR +HA_Chassis configuration\[char46] +.TQ 1in +\fBHA_Chassis_Group\fR +HA_Chassis_Group configuration\[char46] +.TQ 1in +\fBController_Event\fR +Controller Event table +.TQ 1in +\fBIP_Multicast\fR +IP_Multicast configuration\[char46] +.TQ 1in +\fBIGMP_Group\fR +IGMP_Group configuration\[char46] +.TQ 1in +\fBService_Monitor\fR +Service_Monitor configuration\[char46] +.TQ 1in +\fBLoad_Balancer\fR +Load_Balancer configuration\[char46] +.TQ 1in +\fBBFD\fR +BFD configuration\[char46] +.TQ 1in +\fBFDB\fR +Port to MAC bindings +.TQ 1in +\fBStatic_MAC_Binding\fR +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.186591,0.119525 wid 0.201873 height 0.095620 "SB_Global" +box at 0.186591,0.119525 wid 0.146317 height 0.040064 +linethick = 1.000000; +box at 0.928317,0.191240 wid 0.207840 height 0.095620 "Connection" +linethick = 1.000000; +box at 0.928317,0.047810 wid 0.143430 height 0.095620 "SSL" +linethick = 0.500000; +box at 2.919470,2.348045 wid 0.152063 height 0.095620 "Chassis" +box at 2.919470,2.348045 wid 0.096507 height 0.040064 +linethick = 1.000000; +box at 3.282252,1.694597 wid 0.143430 height 0.095620 "Encap" +linethick = 0.500000; +box at 2.486502,2.204615 wid 0.273588 height 0.095620 "Chassis_Private" +box at 2.486502,2.204615 wid 0.218032 height 0.040064 +linethick = 0.500000; +box at 0.186591,2.236361 wid 0.223770 height 0.095620 "Address_Set" +box at 0.186591,2.236361 wid 0.168214 height 0.040064 +linethick = 0.500000; +box at 0.186591,2.664164 wid 0.213825 height 0.095620 "Port_Group" +box at 0.186591,2.664164 wid 0.158270 height 0.040064 +linethick = 0.500000; +box at 0.186591,0.533885 wid 0.247675 height 0.095620 "Logical_Flow" +box at 0.186591,0.533885 wid 0.192119 height 0.040064 +linethick = 0.500000; +box at 1.642140,0.964175 wid 0.305449 height 0.095620 "Datapath_Binding" +box at 1.642140,0.964175 wid 0.249893 height 0.040064 +linethick = 1.000000; +box at 0.928317,0.610897 wid 0.327365 height 0.095620 "Logical_DP_Group" +linethick = 0.500000; +box at 0.186591,1.949501 wid 0.289518 height 0.095620 "Multicast_Group" +box at 0.186591,1.949501 wid 0.233963 height 0.040064 +linethick = 0.500000; +box at 0.928317,1.949501 wid 0.237730 height 0.095620 "Port_Binding" +box at 0.928317,1.949501 wid 0.182175 height 0.040064 +linethick = 0.500000; +box at 1.642140,1.683983 wid 0.143430 height 0.095620 "Mirror" +box at 1.642140,1.683983 wid 0.087874 height 0.040064 +linethick = 0.500000; +box at 0.186591,2.948347 wid 0.143430 height 0.095620 "Meter" +box at 0.186591,2.948347 wid 0.087874 height 0.040064 +linethick = 1.000000; +box at 0.928317,2.948347 wid 0.223770 height 0.095620 "Meter_Band" +linethick = 1.000000; +box at 2.074763,2.470247 wid 0.297493 height 0.095620 "Gateway_Chassis" +linethick = 0.500000; +box at 1.642140,2.071703 wid 0.333350 height 0.095620 "HA_Chassis_Group" +box at 1.642140,2.071703 wid 0.277795 height 0.040064 +linethick = 0.500000; +box at 0.928317,0.334670 wid 0.257639 height 0.095620 "MAC_Binding" +box at 0.928317,0.334670 wid 0.202083 height 0.040064 +linethick = 0.500000; +box at 0.186591,3.091777 wid 0.269591 height 0.095620 "DHCP_Options" +box at 0.186591,3.091777 wid 0.214035 height 0.040064 +linethick = 0.500000; +box at 0.186591,3.235207 wid 0.305449 height 0.095620 "DHCPv6_Options" +box at 0.186591,3.235207 wid 0.249893 height 0.040064 +linethick = 0.500000; +box at 0.928317,1.174003 wid 0.143430 height 0.095620 "DNS" +box at 0.928317,1.174003 wid 0.087874 height 0.040064 +linethick = 0.500000; +box at 0.186591,3.378637 wid 0.223770 height 0.095620 "RBAC_Role" +box at 0.186591,3.378637 wid 0.168214 height 0.040064 +linethick = 0.500000; +box at 0.928317,3.378637 wid 0.319390 height 0.095620 "RBAC_Permission" +box at 0.928317,3.378637 wid 0.263834 height 0.040064 +linethick = 1.000000; +box at 2.486502,2.348045 wid 0.223770 height 0.095620 "HA_Chassis" +linethick = 0.500000; +box at 2.486502,1.827413 wid 0.291507 height 0.095620 "Controller_Event" +box at 2.486502,1.827413 wid 0.235952 height 0.040064 +linethick = 0.500000; +box at 0.928317,1.030573 wid 0.229756 height 0.095620 "IP_Multicast" +box at 0.928317,1.030573 wid 0.174200 height 0.040064 +linethick = 0.500000; +box at 0.186591,1.806147 wid 0.243697 height 0.095620 "IGMP_Group" +box at 0.186591,1.806147 wid 0.188142 height 0.040064 +linethick = 0.500000; +box at 0.186591,3.522067 wid 0.289518 height 0.095620 "Service_Monitor" +box at 0.186591,3.522067 wid 0.233963 height 0.040064 +linethick = 0.500000; +box at 0.186591,0.826042 wid 0.263624 height 0.095620 "Load_Balancer" +box at 0.186591,0.826042 wid 0.208069 height 0.040064 +linethick = 0.500000; +box at 0.186591,3.665497 wid 0.143430 height 0.095620 "BFD" +box at 0.186591,3.665497 wid 0.087874 height 0.040064 +linethick = 0.500000; +box at 0.186591,3.808927 wid 0.143430 height 0.095620 "FDB" +box at 0.186591,3.808927 wid 0.087874 height 0.040064 +linethick = 0.500000; +box at 0.928317,0.754327 wid 0.357255 height 0.095620 "Static_MAC_Binding" +box at 0.928317,0.754327 wid 0.301700 height 0.040064 +linethick = 0.500000; +box at 0.186591,3.952357 wid 0.373186 height 0.095620 "Chassis_Template_Var" +box at 0.186591,3.952357 wid 0.317630 height 0.040064 +linethick = 1.000000; +spline -> from 0.288562,0.129196 to 0.288562,0.129196 to 0.428320,0.142808 to 0.681732,0.167486 to 0.823193,0.181261 +"connections*" at 0.561442,0.188916 +linethick = 1.000000; +spline -> from 0.288466,0.108731 to 0.288466,0.108731 to 0.329468,0.104342 to 0.377508,0.099292 to 0.420996,0.094956 to 0.575977,0.079502 to 0.757903,0.062880 to 0.855417,0.054092 +"ssl?" at 0.561442,0.114545 +linethick = 1.000000; +spline -> from 2.948921,2.298896 to 2.948921,2.298896 to 3.015281,2.177459 to 3.186632,1.864437 to 3.252992,1.743382 +"encaps+" at 3.103060,2.138446 +linethick = 0.500000; +spline -> from 2.624195,2.243819 to 2.624195,2.243819 to 2.677742,2.260074 to 2.739895,2.279772 to 2.795546,2.299470 to 2.810846,2.305016 to 2.827292,2.311135 to 2.842783,2.317255 +"chassis?" at 2.737792,2.319167 +linethick = 1.000000; +spline -> from 0.311377,0.513403 to 0.311377,0.513403 to 0.488312,0.487356 to 0.825564,0.451403 to 1.106935,0.501336 to 1.256409,0.527861 to 1.310185,0.522716 to 1.427664,0.618872 to 1.527262,0.700397 to 1.592704,0.841800 to 1.621926,0.915829 +"logical_datapath?" at 0.928317,0.520938 +linethick = 1.000000; +spline -> from 0.311683,0.546679 to 0.311683,0.546679 to 0.435396,0.559626 to 0.627248,0.579687 to 0.763526,0.593953 +"logical_dp_group?" at 0.561442,0.605925 +linethick = 0.500000; +spline -> from 1.092688,0.618853 to 1.092688,0.618853 to 1.194791,0.630021 to 1.326116,0.656125 to 1.427664,0.716481 to 1.510337,0.765648 to 1.576621,0.858725 to 1.611828,0.915734 +"datapaths*" at 1.291195,0.736083 +linethick = 1.000000; +spline -> from 0.329124,1.900600 to 0.329124,1.900600 to 0.344328,1.893658 to 0.359302,1.886066 to 0.373186,1.877862 to 0.396995,1.863806 to 0.398257,1.853785 to 0.420996,1.838027 to 0.632565,1.691288 to 1.237017,1.437379 to 1.427664,1.264307 to 1.510299,1.189283 to 1.578935,1.076586 to 1.614104,1.012769 +"datapath" at 0.928317,1.668378 +linethick = 0.500000; +spline -> from 0.332107,1.949501 to 0.332107,1.949501 to 0.470967,1.949501 to 0.679323,1.949501 to 0.808639,1.949501 +"ports*" at 0.561442,1.968433 +linethick = 0.500000; +spline -> from 1.047555,1.932098 to 1.047555,1.932098 to 1.329194,1.894615 to 2.065201,1.824640 to 2.632227,2.018729 to 2.711209,2.045694 to 2.737792,2.051240 to 2.795546,2.111672 to 2.847946,2.166175 to 2.882943,2.247835 to 2.901302,2.299470 +"chassis?" at 2.074763,1.952560 +linethick = 0.500000; +spline -> from 0.930784,1.998267 to 0.930784,1.998267 to 0.932888,2.133473 to 0.956888,2.518631 to 1.154745,2.741043 to 1.257269,2.856361 to 1.324146,2.843739 to 1.475474,2.873955 to 1.792072,2.936873 to 2.582505,3.033831 to 2.795546,2.863245 to 2.868600,2.804917 to 2.902067,2.513659 to 2.912776,2.396811 +"additional_chassis*" at 2.074763,2.975121 +linethick = 0.500000; +spline -> from 0.929312,1.997884 to 0.929312,1.997884 to 0.927801,2.127927 to 0.943827,2.485546 to 1.154745,2.640259 to 1.301790,2.747928 to 2.644467,2.742190 to 2.795546,2.640259 to 2.877015,2.585182 to 2.903788,2.464319 to 2.912585,2.396428 +"requested_chassis?" at 2.074763,2.736071 +linethick = 0.500000; +spline -> from 0.954823,1.997693 to 0.954823,1.997693 to 0.990069,2.064627 to 1.062051,2.185108 to 1.154745,2.257779 to 1.419842,2.465084 to 1.526286,2.477514 to 1.856615,2.541962 to 2.195244,2.607940 to 2.296792,2.593406 to 2.632227,2.512702 to 2.708341,2.494343 to 2.728039,2.486120 to 2.795546,2.446342 to 2.819260,2.432190 to 2.843356,2.413831 to 2.863819,2.396620 +"requested_additional_chassis*" at 2.074763,2.600673 +linethick = 0.500000; +spline -> from 1.047613,1.914886 to 1.047613,1.914886 to 1.081902,1.905381 to 1.119653,1.895781 to 1.154745,1.888495 to 1.676142,1.780234 to 1.810048,1.762430 to 2.340778,1.717832 to 2.664929,1.690600 to 3.053912,1.691709 to 3.209963,1.693507 +"encap?" at 2.486502,1.737435 +linethick = 0.500000; +spline -> from 0.954402,1.901251 to 0.954402,1.901251 to 0.988711,1.836153 to 1.059068,1.721963 to 1.154745,1.665375 to 1.275112,1.594215 to 1.962122,1.561800 to 2.072085,1.561800 to 2.072085,1.561800 to 2.072085,1.561800 to 2.922147,1.561800 to 3.027329,1.561800 to 3.139778,1.613033 to 3.209963,1.651855 +"additional_encap*" at 2.486502,1.580713 +linethick = 1.000000; +spline -> from 0.941054,1.900715 to 0.941054,1.900715 to 0.962798,1.808212 to 1.023191,1.607678 to 1.154745,1.505346 to 1.252813,1.429079 to 1.331604,1.523705 to 1.427664,1.444933 to 1.565548,1.331853 to 1.616360,1.111104 to 1.632692,1.013094 +"datapath" at 1.291195,1.524948 +linethick = 0.500000; +spline -> from 0.964901,1.900715 to 0.964901,1.900715 to 1.004029,1.848717 to 1.073507,1.768894 to 1.154745,1.731124 to 1.291214,1.667670 to 1.472261,1.669659 to 1.569908,1.676773 +"mirror_rules*" at 1.291195,1.750707 +linethick = 1.000000; +spline -> from 1.007185,1.998267 to 1.007185,1.998267 to 1.049812,2.024658 to 1.104335,2.056977 to 1.154745,2.082412 to 1.427530,2.220105 to 1.760938,2.352634 to 1.941277,2.421290 +"gateway_chassis*" at 1.291195,2.228902 +linethick = 1.000000; +spline -> from 1.047957,1.969772 to 1.047957,1.969772 to 1.164307,1.989852 to 1.343824,2.020833 to 1.474594,2.043399 +"ha_chassis_group?" at 1.291195,2.053535 +linethick = 1.000000; +spline -> from 0.259188,2.948347 to 0.259188,2.948347 to 0.387720,2.948347 to 0.662341,2.948347 to 0.815925,2.948347 +"bands+" at 0.561442,2.967280 +linethick = 0.500000; +spline -> from 2.224312,2.468335 to 2.224312,2.468335 to 2.371185,2.463554 to 2.602394,2.447298 to 2.795546,2.395855 to 2.811228,2.391647 to 2.827675,2.385910 to 2.843356,2.380173 +"chassis?" at 2.486502,2.483825 +linethick = 0.500000; +spline -> from 1.809723,2.042061 to 1.809723,2.042061 to 2.011462,2.013183 to 2.359710,1.987749 to 2.632227,2.095034 to 2.739131,2.137107 to 2.832264,2.238847 to 2.880839,2.299661 +"ref_chassis*" at 2.486502,2.114541 +linethick = 1.000000; +spline -> from 1.793831,2.120852 to 1.793831,2.120852 to 1.960019,2.175546 to 2.225077,2.262752 to 2.373671,2.311709 +"ha_chassis*" at 2.074763,2.300617 +linethick = 1.000000; +spline -> from 1.057997,0.318587 to 1.057997,0.318587 to 1.167501,0.311855 to 1.323878,0.320289 to 1.427664,0.403057 to 1.591270,0.533579 to 1.628542,0.805044 to 1.637014,0.915676 +"datapath" at 1.291195,0.422660 +linethick = 1.000000; +spline -> from 1.001180,1.161668 to 1.001180,1.161668 to 1.098425,1.143653 to 1.278937,1.106801 to 1.427664,1.057136 to 1.464612,1.044801 to 1.503969,1.028450 to 1.538602,1.012922 +"datapaths+" at 1.291195,1.150423 +linethick = 0.500000; +spline -> from 0.299501,3.378637 to 0.299501,3.378637 to 0.423673,3.378637 to 0.626540,3.378637 to 0.767561,3.378637 +"permissions value*" at 0.561442,3.397570 +linethick = 0.500000; +spline -> from 2.599143,2.348045 to 2.599143,2.348045 to 2.676021,2.348045 to 2.776231,2.348045 to 2.843356,2.348045 +"chassis?" at 2.737792,2.366977 +linethick = 0.500000; +spline -> from 2.633184,1.817201 to 2.633184,1.817201 to 2.690173,1.820739 to 2.752135,1.835139 to 2.795546,1.874554 to 2.858656,1.931715 to 2.897286,2.189698 to 2.911055,2.298896 +"chassis?" at 2.737792,1.894137 +linethick = 0.500000; +spline -> from 1.044017,1.019979 to 1.044017,1.019979 to 1.164346,1.008695 to 1.355394,0.990795 to 1.488536,0.978307 +"datapath" at 1.291195,1.028240 +linethick = 0.500000; +spline -> from 0.309598,1.836707 to 0.309598,1.836707 to 0.332815,1.846862 to 0.355420,1.860249 to 0.373186,1.877862 to 0.413824,1.918137 to 0.395408,1.946249 to 0.420996,1.997311 to 0.613880,2.383042 to 0.494413,2.826145 to 0.925659,2.826145 to 0.925659,2.826145 to 0.925659,2.826145 to 2.489180,2.826145 to 2.637582,2.826145 to 2.694380,2.801857 to 2.795546,2.693233 to 2.874337,2.608705 to 2.902449,2.469865 to 2.912011,2.396620 +"chassis?" at 1.642140,2.845077 +linethick = 0.500000; +spline -> from 0.203747,1.757668 to 0.203747,1.757668 to 0.231496,1.673694 to 0.300285,1.501636 to 0.420996,1.413053 to 0.791275,1.141282 to 1.026940,1.403797 to 1.427664,1.179320 to 1.501750,1.137802 to 1.566887,1.062682 to 1.604752,1.013094 +"datapath?" at 0.928317,1.301828 +linethick = 0.500000; +spline -> from 0.309598,1.827394 to 0.309598,1.827394 to 0.413614,1.846001 to 0.567887,1.874190 to 0.701870,1.901117 to 0.736561,1.908078 to 0.774178,1.916034 to 0.808486,1.923492 +"ports*" at 0.561442,1.920623 +linethick = 1.000000; +spline -> from 0.319218,0.838434 to 0.319218,0.838434 to 0.587929,0.864022 to 1.203301,0.922618 to 1.488842,0.949813 +"datapaths*" at 0.928317,0.932620 +linethick = 1.000000; +spline -> from 0.319199,0.788081 to 0.319199,0.788081 to 0.443084,0.751898 to 0.630002,0.697280 to 0.763545,0.658267 +"datapath_group?" at 0.561442,0.775918 +linethick = 1.000000; +spline -> from 1.108140,0.759395 to 1.108140,0.759395 to 1.205137,0.766911 to 1.325943,0.784122 to 1.427664,0.822734 to 1.484711,0.844382 to 1.541815,0.883797 to 1.582320,0.915523 +"datapath" at 1.291195,0.842317 +.ps +3 +.PE +.RE\} +.bp +.SH "SB_Global TABLE" +.PP +.PP +.PP +Southbound configuration for an OVN system\[char46] This table must have exactly one row\[char46] +.SS "Summary: +.TQ .25in +\fIStatus:\fR +.RS .25in +.TQ 2.75in +\fBnb_cfg\fR +integer +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.TQ 2.75in +\fBoptions\fR +map of string-string pairs +.RE +.TQ .25in +\fICommon options:\fR +.RS .25in +.TQ 2.75in +\fBoptions\fR +map of string-string pairs +.TQ .25in +\fIOptions for configuring BFD:\fR +.RS .25in +.TQ 2.50in +\fBoptions : bfd-min-rx\fR +optional string +.TQ 2.50in +\fBoptions : bfd-decay-min-rx\fR +optional string +.TQ 2.50in +\fBoptions : bfd-min-tx\fR +optional string +.TQ 2.50in +\fBoptions : bfd-mult\fR +optional string +.TQ 2.50in +\fBoptions : debug_drop_domain_id\fR +optional string +.TQ 2.50in +\fBoptions : debug_drop_collector_set\fR +optional string +.RE +.TQ .25in +\fIOptions for configuring Load Balancers:\fR +.RS .25in +.TQ 2.50in +\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 +.RS .25in +.TQ 2.75in +\fBconnections\fR +set of \fBConnection\fRs +.TQ 2.75in +\fBssl\fR +optional \fBSSL\fR +.RE +.TQ .25in +\fISecurity Configurations:\fR +.RS .25in +.TQ 2.75in +\fBipsec\fR +boolean +.RE +.SS "Details: +.ST "Status:" +.PP +This column allow a client to track the overall configuration state of the system\[char46] +.IP "\fBnb_cfg\fR: integer" +Sequence number for the configuration\[char46] When a CMS or \fBovn\-nbctl\fR updates the northbound database, it increments the \fBnb_cfg\fR column in the \fBNB_Global\fR table in the northbound database\[char46] In turn, when \fBovn\-northd\fR updates the southbound database to bring it up to date with these changes, it updates this column to the same value\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.IP "\fBoptions\fR: map of string-string pairs" +.ST "Common options:" +.PP +.IP "\fBoptions\fR: map of string-string pairs" +This column provides general key/value settings\[char46] The supported options are described individually below\[char46] +.ST "Options for configuring BFD:" +.PP +.PP +.PP +These options apply when \fBovn\-controller\fR configures BFD on tunnels interfaces\[char46] +.IP "\fBoptions : bfd-min-rx\fR: optional string" +BFD option \fBmin\-rx\fR value to use when configuring BFD on tunnel interfaces\[char46] +.IP "\fBoptions : bfd-decay-min-rx\fR: optional string" +BFD option \fBdecay\-min\-rx\fR value to use when configuring BFD on tunnel interfaces\[char46] +.IP "\fBoptions : bfd-min-tx\fR: optional string" +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 : debug_drop_domain_id\fR: optional string" +If set to a 8-bit number and if \fBdebug_drop_collector_set\fR is also configured, \fBovn\-controller\fR will add a \fBsample\fR action to every flow that does not come from a logical flow that contains a \(cqdrop\(cq action\[char46] The 8 most significant bits of the observation_domain_id field will be those specified in the \fB debug_drop_domain_id\fR\[char46] The 24 least significant bits of the observation_domain_id field will be zero\[char46] +.IP +The observation_point_id will be set to the OpenFlow table number\[char46] +.IP "\fBoptions : debug_drop_collector_set\fR: optional string" +If set to a 32-bit number \fBovn\-controller\fR will add a \fBsample\fR action to every flow that does not come from a 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] +.ST "Options for configuring Load Balancers:" +.PP +.PP +.PP +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" +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\[char46] See the \fBConnection\fR table for more information\[char46] +.IP "\fBssl\fR: optional \fBSSL\fR" +Global SSL configuration\[char46] +.ST "Security Configurations:" +.PP +.IP "\fBipsec\fR: boolean" +Tunnel encryption configuration\[char46] If this column is set to be true, all OVN tunnels will be encrypted with IPsec\[char46] +.bp +.SH "Chassis TABLE" +.PP +.PP +.PP +Each row in this table represents a hypervisor or gateway (a chassis) in the physical network\[char46] Each chassis, via \fBovn\-controller\fR/\fBovn\-controller\-vtep\fR, adds and updates its own row, and keeps a copy of the remaining rows to determine how to reach other hypervisors\[char46] +.PP +.PP +When a chassis shuts down gracefully, it should remove its own row\[char46] (This is not critical because resources hosted on the chassis are equally unreachable regardless of whether the row is present\[char46]) If a chassis shuts down permanently without removing its row, some kind of manual or automatic cleanup is eventually needed; we can devise a process for that as necessary\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBhostname\fR +string +.TQ 3.00in +\fBnb_cfg\fR +integer +.TQ 3.00in +\fBother_config : ovn-bridge-mappings\fR +optional string +.TQ 3.00in +\fBother_config : datapath-type\fR +optional string +.TQ 3.00in +\fBother_config : iface-types\fR +optional string +.TQ 3.00in +\fBother_config : ovn-cms-options\fR +optional string +.TQ 3.00in +\fBother_config : is-interconn\fR +optional string +.TQ 3.00in +\fBother_config : is-remote\fR +optional string +.TQ 3.00in +\fBtransport_zones\fR +set of strings +.TQ 3.00in +\fBother_config : ovn-chassis-mac-mappings\fR +optional string +.TQ 3.00in +\fBother_config : port-up-notif\fR +optional string +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.TQ .25in +\fIEncapsulation Configuration:\fR +.RS .25in +.TQ 2.75in +\fBencaps\fR +set of 1 or more \fBEncap\fRs +.RE +.TQ .25in +\fIGateway Configuration:\fR +.RS .25in +.TQ 2.75in +\fBvtep_logical_switches\fR +set of strings +.RE +.SS "Details: +.IP "\fBname\fR: string (must be unique within table)" +OVN does not prescribe a particular format for chassis names\[char46] ovn-controller populates this column using \fBexternal_ids:system-id\fR in the Open_vSwitch database\(cqs \fBOpen_vSwitch\fR table\[char46] ovn-controller-vtep populates this column with \fBname\fR in the hardware_vtep database\(cqs \fBPhysical_Switch\fR table\[char46] +.IP "\fBhostname\fR: string" +The hostname of the chassis, if applicable\[char46] ovn-controller will populate this column with the hostname of the host it is running on\[char46] ovn-controller-vtep will leave this column empty\[char46] +.IP "\fBnb_cfg\fR: integer" +Deprecated\[char46] This column is replaced by the \fBnb_cfg\fR column of the \fBChassis_Private\fR table\[char46] +.IP "\fBother_config : ovn-bridge-mappings\fR: optional string" +\fBovn\-controller\fR populates this key with the set of bridge mappings it has been configured to use\[char46] Other applications should treat this key as read-only\[char46] See \fBovn\-controller\fR(8) for more information\[char46] +.IP "\fBother_config : datapath-type\fR: optional string" +\fBovn\-controller\fR populates this key with the datapath type configured in the \fBdatapath_type\fR column of the Open_vSwitch database\(cqs \fBBridge\fR table\[char46] Other applications should treat this key as read-only\[char46] See \fBovn\-controller\fR(8) for more information\[char46] +.IP "\fBother_config : iface-types\fR: optional string" +\fBovn\-controller\fR populates this key with the interface types configured in the \fBiface_types\fR column of the Open_vSwitch database\(cqs \fBOpen_vSwitch\fR table\[char46] Other applications should treat this key as read-only\[char46] See \fBovn\-controller\fR(8) for more information\[char46] +.IP "\fBother_config : ovn-cms-options\fR: optional string" +\fBovn\-controller\fR populates this key with the set of options configured in the \fBexternal_ids:ovn-cms-options\fR column of the Open_vSwitch database\(cqs \fBOpen_vSwitch\fR table\[char46] See \fBovn\-controller\fR(8) for more information\[char46] +.IP "\fBother_config : is-interconn\fR: optional string" +\fBovn\-controller\fR populates this key with the setting configured in the \fBexternal_ids:ovn-is-interconn\fR column of the Open_vSwitch database\(cqs \fBOpen_vSwitch\fR table\[char46] If set to true, the chassis is used as an interconnection gateway\[char46] See \fBovn\-controller\fR(8) for more information\[char46] +.IP "\fBother_config : is-remote\fR: optional string" +\fBovn\-ic\fR set this key to true for remote interconnection gateway chassises learned from the interconnection southbound database\[char46] See \fBovn\-ic\fR(8) for more information\[char46] +.IP "\fBtransport_zones\fR: set of strings" +\fBovn\-controller\fR populates this key with the transport zones configured in the \fBexternal_ids:ovn-transport-zones\fR column of the Open_vSwitch database\(cqs \fBOpen_vSwitch\fR table\[char46] See \fBovn\-controller\fR(8) for more information\[char46] +.IP "\fBother_config : ovn-chassis-mac-mappings\fR: optional string" +\fBovn\-controller\fR populates this key with the set of options configured in the \fBexternal_ids:ovn-chassis-mac-mappings\fR column of the Open_vSwitch database\(cqs \fBOpen_vSwitch\fR table\[char46] See \fBovn\-controller\fR(8) for more information\[char46] +.IP "\fBother_config : port-up-notif\fR: optional string" +\fBovn\-controller\fR populates this key with \fBtrue\fR when it supports \fBPort_Binding\[char46]up\fR\[char46] +.ST "Common Columns:" +.PP +The overall purpose of these columns is described under \fBCommon +Columns\fR at the beginning of this document\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +.ST "Encapsulation Configuration:" +.PP +.PP +.PP +OVN uses encapsulation to transmit logical dataplane packets between chassis\[char46] +.IP "\fBencaps\fR: set of 1 or more \fBEncap\fRs" +Points to supported encapsulation configurations to transmit logical dataplane packets to this chassis\[char46] Each entry is a \fBEncap\fR record that describes the configuration\[char46] +.ST "Gateway Configuration:" +.PP +.PP +.PP +A \fIgateway\fR 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\[char46] Gateways are typically dedicated nodes that do not host VMs and will be controlled by \fBovn\-controller\-vtep\fR\[char46] +.IP "\fBvtep_logical_switches\fR: set of strings" +Stores all VTEP logical switch names connected by this gateway chassis\[char46] The \fBPort_Binding\fR table entry with \fBoptions\fR:\fBvtep\-physical\-switch\fR equal \fBChassis\fR \fBname\fR, and \fBoptions\fR:\fBvtep\-logical\-switch\fR value in \fBChassis\fR \fBvtep_logical_switches\fR, will be associated with this \fBChassis\fR\[char46] +.bp +.SH "Chassis_Private TABLE" +.PP +.PP +.PP +Each row in this table maintains per chassis private data that are accessed only by the owning chassis (write only) and ovn-northd, not by any other chassis\[char46] These data are stored in this separate table instead of the \fBChassis\fR 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\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBchassis\fR +optional weak reference to \fBChassis\fR +.TQ 3.00in +\fBnb_cfg\fR +integer +.TQ 3.00in +\fBnb_cfg_timestamp\fR +integer +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBname\fR: string (must be unique within table)" +The name of the chassis that owns these chassis-private data\[char46] +.IP "\fBchassis\fR: optional weak reference to \fBChassis\fR" +The reference to \fBChassis\fR table for the chassis that owns these chassis-private data\[char46] +.IP "\fBnb_cfg\fR: integer" +Sequence number for the configuration\[char46] When \fBovn\-controller\fR updates the configuration of a chassis from the contents of the southbound database, it copies \fBnb_cfg\fR from the \fBSB_Global\fR table into this column\[char46] +.IP "\fBnb_cfg_timestamp\fR: integer" +The timestamp when \fBovn\-controller\fR finishes processing the change corresponding to \fBnb_cfg\fR\[char46] +.ST "Common Columns:" +.PP +The overall purpose of these columns is described under \fBCommon +Columns\fR at the beginning of this document\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +.bp +.SH "Encap TABLE" +.PP +.PP +.PP +The \fBencaps\fR column in the \fBChassis\fR table refers to rows in this table to identify how OVN may transmit logical dataplane packets to this chassis\[char46] Each chassis, via \fBovn\-controller\fR(8) or \fBovn\-controller\-vtep\fR(8), adds and updates its own rows and keeps a copy of the remaining rows to determine how to reach other chassis\[char46] +.SS "Summary: +.TQ 3.00in +\fBtype\fR +string, one of \fBgeneve\fR, \fBstt\fR, or \fBvxlan\fR +.TQ 3.00in +\fBoptions\fR +map of string-string pairs +.TQ 3.00in +\fBoptions : csum\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.TQ 3.00in +\fBoptions : dst_port\fR +optional string, containing an integer +.TQ 3.00in +\fBip\fR +string +.TQ 3.00in +\fBchassis_name\fR +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 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" +\fBcsum\fR indicates whether this chassis can transmit and receive packets that include checksums with reasonable performance\[char46] It hints to senders transmitting data to this chassis that they should use checksums to protect OVN metadata\[char46] \fBovn\-controller\fR populates this key with the value defined in \fBexternal_ids:ovn-encap-csum\fR column of the Open_vSwitch database\(cqs \fBOpen_vSwitch\fR table\[char46] Other applications should treat this key as read-only\[char46] See \fBovn\-controller\fR(8) for more information\[char46] +.IP +In terms of performance, checksumming actually significantly increases throughput in most common cases when running on Linux based hosts without NICs supporting encapsulation hardware offload (around 60% for bulk traffic)\[char46] The reason is that generally all NICs are capable of offloading transmitted and received TCP/UDP checksums (viewed as ordinary data packets and not as tunnels)\[char46] The benefit comes on the receive side where the validated 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\[char46] +.IP +Not all devices see such a benefit\[char46] The most notable exception is hardware VTEPs\[char46] 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\[char46] In addition certain versions of the Linux kernel are not able to fully take advantage of encapsulation NIC offloads in the presence of checksums\[char46] (This is actually a pretty narrow corner case though: earlier versions of Linux don\(cqt support encapsulation offloads at all and later versions support both offloads and checksums well\[char46]) +.IP +\fBcsum\fR defaults to \fBfalse\fR for hardware VTEPs and \fBtrue\fR for all other cases\[char46] +.IP +This option applies to \fBgeneve\fR and \fBvxlan\fR encapsulations\[char46] +.IP "\fBoptions : dst_port\fR: optional string, containing an integer" +If set, overrides the UDP (for \fBgeneve\fR and \fBvxlan\fR) or TCP (for \fBstt\fR) destination port\[char46] +.IP "\fBip\fR: string" +The IPv4 address of the encapsulation tunnel endpoint\[char46] +.IP "\fBchassis_name\fR: string" +The name of the chassis that created this encap\[char46] +.bp +.SH "Address_Set TABLE" +.PP +.PP +.PP +This table contains address sets synced from the \fBAddress_Set\fR table in the \fBOVN_Northbound\fR database and address sets generated from the \fBPort_Group\fR table in the \fBOVN_Northbound\fR database\[char46] +.PP +.PP +See the documentation for the \fBAddress_Set\fR table and \fBPort_Group\fR table in the \fBOVN_Northbound\fR database for details\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBaddresses\fR +set of strings +.SS "Details: +.IP "\fBname\fR: string (must be unique within table)" +.IP "\fBaddresses\fR: set of strings" +.bp +.SH "Port_Group TABLE" +.PP +.PP +.PP +This table contains names for the logical switch ports in the \fBOVN_Northbound\fR database that belongs to the same group that is defined in \fBPort_Group\fR in the \fBOVN_Northbound\fR database\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBports\fR +set of strings +.SS "Details: +.IP "\fBname\fR: string (must be unique within table)" +.IP "\fBports\fR: set of strings" +.bp +.SH "Logical_Flow TABLE" +.PP +.PP +.PP +Each row in this table represents one logical flow\[char46] \fBovn\-northd\fR populates this table with logical flows that implement the L2 and L3 topologies specified in the \fBOVN_Northbound\fR database\[char46] Each hypervisor, via \fBovn\-controller\fR, translates the logical flows into OpenFlow flows specific to its hypervisor and installs them into Open vSwitch\[char46] +.PP +.PP +Logical flows are expressed in an OVN-specific format, described here\[char46] 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\[char46] Translation between logical and physical flows helps to ensure isolation between logical datapaths\[char46] (The logical flow abstraction also allows the OVN centralized components to do less work, since they do not have to separately compute and push out physical flows to each chassis\[char46]) +.PP +.PP +The default action when no flow matches is to drop packets\[char46] +.PP +\fBArchitectural Logical Life Cycle of a Packet\fR +.PP +.PP +This following description focuses on the life cycle of a packet through a logical datapath, ignoring physical details of the implementation\[char46] Please refer to \fBArchitectural Physical Life Cycle of a Packet\fR in \fBovn\-architecture\fR(7) for the physical information\[char46] +.PP +.PP +The description here is written as if OVN itself executes these steps, but in fact OVN (that is, \fBovn\-controller\fR) programs Open vSwitch, via OpenFlow and OVSDB, to execute them on its behalf\[char46] +.PP +.PP +At a high level, OVN passes each packet through the logical datapath\(cqs logical ingress pipeline, which may output the packet to one or more logical port or logical multicast groups\[char46] For each such logical output port, OVN passes the packet through the datapath\(cqs logical egress pipeline, which may either drop the packet or deliver it to the destination\[char46] 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\[char46] Between the two pipelines is also where, when necessary, OVN encapsulates a packet in a tunnel (or tunnels) to transmit to remote hypervisors\[char46] +.PP +.PP +In more detail, to start, OVN searches the \fBLogical_Flow\fR table for a row with correct \fBlogical_datapath\fR or a \fBlogical_dp_group\fR, a \fBpipeline\fR of \fBingress\fR, a \fBtable_id\fR of 0, and a \fBmatch\fR that is true for the packet\[char46] If none is found, OVN drops the packet\[char46] If OVN finds more than one, it chooses the match with the highest \fBpriority\fR\[char46] Then OVN executes each of the actions specified in the row\(cqs \fBactions\fR column, in the order specified\[char46] Some actions, such as those to modify packet headers, require no further details\[char46] The \fBnext\fR and \fBoutput\fR actions are special\[char46] +.PP +.PP +The \fBnext\fR action causes the above process to be repeated recursively, except that OVN searches for \fBtable_id\fR of 1 instead of 0\[char46] Similarly, any \fBnext\fR action in a row found in that table would cause a further search for a \fBtable_id\fR of 2, and so on\[char46] When recursive processing completes, flow control returns to the action following \fBnext\fR\[char46] +.PP +.PP +The \fBoutput\fR action also introduces recursion\[char46] Its effect depends on the current value of the \fBoutport\fR field\[char46] Suppose \fBoutport\fR designates a logical port\[char46] First, OVN compares \fBinport\fR to \fBoutport\fR; if they are equal, it treats the \fBoutput\fR as a no-op by default\[char46] In the common case, where they are different, the packet enters the egress pipeline\[char46] This transition to the egress pipeline discards register data, e\[char46]g\[char46] \fBreg0\fR \[char46]\[char46]\[char46] \fBreg9\fR and connection tracking state, to achieve uniform behavior regardless of whether the egress pipeline is on a different hypervisor (because registers aren\(cqt preserve across tunnel encapsulation)\[char46] +.PP +.PP +To execute the egress pipeline, OVN again searches the \fBLogical_Flow\fR table for a row with correct \fBlogical_datapath\fR or a \fBlogical_dp_group\fR, a \fBtable_id\fR of 0, a \fBmatch\fR that is true for the packet, but now looking for a \fBpipeline\fR of \fBegress\fR\[char46] If no matching row is found, the output becomes a no-op\[char46] Otherwise, OVN executes the actions for the matching flow (which is chosen from multiple, if necessary, as already described)\[char46] +.PP +.PP +In the \fBegress\fR pipeline, the \fBnext\fR action acts as already described, except that it, of course, searches for \fBegress\fR flows\[char46] The \fBoutput\fR action, however, now directly outputs the packet to the output port (which is now fixed, because \fBoutport\fR is read-only within the egress pipeline)\[char46] +.PP +.PP +The description earlier assumed that \fBoutport\fR referred to a logical port\[char46] If it instead designates a logical multicast group, then the description above still applies, with the addition of fan-out from the logical multicast group to each logical port in the group\[char46] For each member of the group, OVN executes the logical pipeline as described, with the logical output port replaced by the group member\[char46] +.PP +\fBPipeline Stages\fR +.PP +.PP +\fBovn\-northd\fR populates the \fBLogical_Flow\fR table with the logical flows described in detail in \fBovn\-northd\fR(8)\[char46] +.SS "Summary: +.TQ 3.00in +\fBlogical_datapath\fR +optional \fBDatapath_Binding\fR +.TQ 3.00in +\fBlogical_dp_group\fR +optional \fBLogical_DP_Group\fR +.TQ 3.00in +\fBpipeline\fR +string, either \fBegress\fR or \fBingress\fR +.TQ 3.00in +\fBtable_id\fR +integer, in range 0 to 32 +.TQ 3.00in +\fBpriority\fR +integer, in range 0 to 65,535 +.TQ 3.00in +\fBmatch\fR +string +.TQ 3.00in +\fBactions\fR +string +.TQ 3.00in +\fBtags\fR +map of string-string pairs +.TQ 3.00in +\fBcontroller_meter\fR +optional string +.TQ 3.00in +\fBexternal_ids : stage-name\fR +optional string +.TQ 3.00in +\fBexternal_ids : stage-hint\fR +optional string, containing an uuid +.TQ 3.00in +\fBexternal_ids : source\fR +optional string +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBlogical_datapath\fR: optional \fBDatapath_Binding\fR" +The logical datapath to which the logical flow belongs\[char46] +.IP "\fBlogical_dp_group\fR: optional \fBLogical_DP_Group\fR" +The group of logical datapaths to which the logical flow belongs\[char46] This means that the same logical flow belongs to all datapaths in a group\[char46] +.IP "\fBpipeline\fR: string, either \fBegress\fR or \fBingress\fR" +The primary flows used for deciding on a packet\(cqs destination are the \fBingress\fR flows\[char46] The \fBegress\fR flows implement ACLs\[char46] See \fBLogical Life Cycle of a Packet\fR, above, for details\[char46] +.IP "\fBtable_id\fR: integer, in range 0 to 32" +The stage in the logical pipeline, analogous to an OpenFlow table number\[char46] +.IP "\fBpriority\fR: integer, in range 0 to 65,535" +The flow\(cqs priority\[char46] Flows with numerically higher priority take precedence over those with lower\[char46] If two logical datapath flows with the same priority both match, then the one actually applied to the packet is undefined\[char46] +.IP "\fBmatch\fR: string" +A matching expression\[char46] OVN provides a superset of OpenFlow matching capabilities, using a syntax similar to Boolean expressions in a programming language\[char46] +.IP +The most important components of match expression are \fIcomparisons\fR between \fIsymbols\fR and \fIconstants\fR, e\[char46]g\[char46] \fBip4\[char46]dst == 192\[char46]168\[char46]0\[char46]1\fR, \fBip\[char46]proto == 6\fR, \fBarp\[char46]op == 1\fR, \fBeth\[char46]type == +0x800\fR\[char46] The logical AND operator \fB&&\fR and logical OR operator \fB||\fR can combine comparisons into a larger expression\[char46] +.IP +Matching expressions also support parentheses for grouping, the logical NOT prefix operator \fB!\fR, and literals \fB0\fR and \fB1\fR to express ``false\(cq\(cq or ``true,\(cq\(cq respectively\[char46] The latter is useful by itself as a catch-all expression that matches every packet\[char46] +.IP +Match expressions also support a kind of function syntax\[char46] The following functions are supported: +.RS +.TP +\fBis_chassis_resident(\fIlport\fB)\fR +Evaluates to true on a chassis on which logical port \fIlport\fR (a quoted string) resides, and to false elsewhere\[char46] This function was introduced in OVN 2\[char46]7\[char46] +.RE +.IP +\fBSymbols\fR +.IP +\fBType\fR\[char46] Symbols have \fIinteger\fR or \fIstring\fR type\[char46] Integer symbols have a \fIwidth\fR in bits\[char46] +.IP +\fBKinds\fR\[char46] There are three kinds of symbols: +.RS +.IP \(bu +\fIFields\fR\[char46] A field symbol represents a packet header or metadata field\[char46] For example, a field named \fBvlan\[char46]tci\fR might represent the VLAN TCI field in a packet\[char46] +.IP +A field symbol can have integer or string type\[char46] Integer fields can be nominal or ordinal (see \fBLevel of Measurement\fR, below)\[char46] +.IP \(bu +\fISubfields\fR\[char46] A subfield represents a subset of bits from a larger field\[char46] For example, a field \fBvlan\[char46]vid\fR might be defined as an alias for \fBvlan\[char46]tci[0\[char46]\[char46]11]\fR\[char46] Subfields are provided for syntactic convenience, because it is always possible to instead refer to a subset of bits from a field directly\[char46] +.IP +Only ordinal fields (see \fBLevel of Measurement\fR, below) may have subfields\[char46] Subfields are always ordinal\[char46] +.IP \(bu +\fIPredicates\fR\[char46] A predicate is shorthand for a Boolean expression\[char46] Predicates may be used much like 1-bit fields\[char46] For example, \fBip4\fR might expand to \fBeth\[char46]type == +0x800\fR\[char46] Predicates are provided for syntactic convenience, because it is always possible to instead specify the underlying expression directly\[char46] +.IP +A predicate whose expansion refers to any nominal field or predicate (see \fBLevel of Measurement\fR, below) is nominal; other predicates have Boolean level of measurement\[char46] +.RE +.IP +\fBLevel of Measurement\fR\[char46] See http://en\[char46]wikipedia\[char46]org/wiki/Level_of_measurement for the statistical concept on which this classification is based\[char46] There are three levels: +.RS +.IP \(bu +\fIOrdinal\fR\[char46] In statistics, ordinal values can be ordered on a scale\[char46] OVN considers a field (or subfield) to be ordinal if its bits can be examined individually\[char46] This is true for the OpenFlow fields that OpenFlow or Open vSwitch makes ``maskable\[char46]\(cq\(cq +.IP +Any use of a ordinal field may specify a single bit or a range of bits, e\[char46]g\[char46] \fBvlan\[char46]tci[13\[char46]\[char46]15]\fR refers to the PCP field within the VLAN TCI, and \fBeth\[char46]dst[40]\fR refers to the multicast bit in the Ethernet destination address\[char46] +.IP +OVN supports all the usual arithmetic relations (\fB==\fR, \fB!=\fR, \fB<\fR, \fB<=\fR, \fB>\fR, and \fB>=\fR) on ordinal fields and their subfields, because OVN can implement these in OpenFlow and Open vSwitch as collections of bitwise tests\[char46] +.IP \(bu +\fINominal\fR\[char46] In statistics, nominal values cannot be usefully compared except for equality\[char46] This is true of OpenFlow port numbers, Ethernet types, and IP protocols are examples: all of these are just identifiers assigned arbitrarily with no deeper meaning\[char46] In OpenFlow and Open vSwitch, bits in these fields generally aren\(cqt individually addressable\[char46] +.IP +OVN only supports arithmetic tests for equality on nominal fields, because OpenFlow and Open vSwitch provide no way for a flow to efficiently implement other comparisons on them\[char46] (A test for inequality can be sort of built out of two flows with different priorities, but OVN matching expressions always generate flows with a single priority\[char46]) +.IP +String fields are always nominal\[char46] +.IP \(bu +\fIBoolean\fR\[char46] 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\[char46] +.IP +Only predicates (see above) have a Boolean level of measurement\[char46] +.IP +This isn\(cqt a standard level of measurement\[char46] +.RE +.IP +\fBPrerequisites\fR\[char46] Any symbol can have prerequisites, which are additional condition implied by the use of the symbol\[char46] For example, For example, \fBicmp4\[char46]type\fR symbol might have prerequisite \fBicmp4\fR, which would cause an expression \fBicmp4\[char46]type == +0\fR to be interpreted as \fBicmp4\[char46]type == 0 && +icmp4\fR, which would in turn expand to \fBicmp4\[char46]type == 0 +&& eth\[char46]type == 0x800 && ip4\[char46]proto == 1\fR (assuming \fBicmp4\fR is a predicate defined as suggested under \fBTypes\fR above)\[char46] +.IP +\fBRelational operators\fR +.IP +All of the standard relational operators \fB==\fR, \fB!=\fR, \fB<\fR, \fB<=\fR, \fB>\fR, and \fB>=\fR are supported\[char46] Nominal fields support only \fB==\fR and \fB!=\fR, and only in a positive sense when outer \fB!\fR are taken into account, e\[char46]g\[char46] given string field \fBinport\fR, \fBinport == +\(dqeth0\(dq\fR and \fB!(inport != \(dqeth0\(dq)\fR are acceptable, but not \fBinport != \(dqeth0\(dq\fR\[char46] +.IP +The implementation of \fB==\fR (or \fB!=\fR when it is negated), is more efficient than that of the other relational operators\[char46] +.IP +\fBConstants\fR +.IP +Integer constants may be expressed in decimal, hexadecimal prefixed by \fB0x\fR, or as dotted-quad IPv4 addresses, IPv6 addresses in their standard forms, or Ethernet addresses as colon-separated hex digits\[char46] 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\[char46] IPv4 and IPv6 masks may be given as integers, to express CIDR prefixes\[char46] +.IP +String constants have the same syntax as quoted strings in JSON (thus, they are Unicode strings)\[char46] +.IP +Some operators support sets of constants written inside curly braces \fB{\fR \[char46]\[char46]\[char46] \fB}\fR\[char46] Commas between elements of a set, and after the last elements, are optional\[char46] With \fB==\fR, ``\fB\fIfield\fB == { \fIconstant1\fB, +\fIconstant2\fB,\fR \[char46]\[char46]\[char46] \fB}\fR\(cq\(cq is syntactic sugar for ``\fB\fIfield\fB == \fIconstant1\fB || +\fIfield\fB == \fIconstant2\fB || \fR\[char46]\[char46]\[char46]\fB\fR\[char46] Similarly, ``\fB\fIfield\fB != { \fIconstant1\fB, +\fIconstant2\fB, \fR\[char46]\[char46]\[char46]\fB }\fR\(cq\(cq is equivalent to ``\fB\fIfield\fB != \fIconstant1\fB && +\fIfield\fB != \fIconstant2\fB && +\fR\[char46]\[char46]\[char46]\fB\fR\(cq\(cq\[char46] +.IP +You may refer to a set of IPv4, IPv6, or MAC addresses stored in the \fBAddress_Set\fR table by its \fBname\fR\[char46] An \fBAddress_Set\fR with a name of \fBset1\fR can be referred to as \fB$set1\fR\[char46] +.IP +You may refer to a group of logical switch ports stored in the \fBPort_Group\fR table by its \fBname\fR\[char46] An \fBPort_Group\fR with a name of \fBport_group1\fR can be referred to as \fB@port_group1\fR\[char46] +.IP +Additionally, you may refer to the set of addresses belonging to a group of logical switch ports stored in the \fBPort_Group\fR table by its \fBname\fR followed by a suffix \(cq_ip4\(cq/\(cq_ip6\(cq\[char46] The IPv4 address set of a \fBPort_Group\fR with a name of \fBport_group1\fR can be referred to as \fB$port_group1_ip4\fR, and the IPv6 address set of the same \fBPort_Group\fR can be referred to as \fB$port_group1_ip6\fR +.IP +\fBMiscellaneous\fR +.IP +Comparisons may name the symbol or the constant first, e\[char46]g\[char46] \fBtcp\[char46]src == 80\fR and \fB80 == tcp\[char46]src\fR are both acceptable\[char46] +.IP +Tests for a range may be expressed using a syntax like \fB1024 <= +tcp\[char46]src <= 49151\fR, which is equivalent to \fB1024 <= +tcp\[char46]src && tcp\[char46]src <= 49151\fR\[char46] +.IP +For a one-bit field or predicate, a mention of its name is equivalent to \fB\fIsymobl\fB == 1\fR, e\[char46]g\[char46] \fBvlan\[char46]present\fR is equivalent to \fBvlan\[char46]present == 1\fR\[char46] The same is true for one-bit subfields, e\[char46]g\[char46] \fBvlan\[char46]tci[12]\fR\[char46] There is no technical limitation to implementing the same for ordinal fields of all widths, but the implementation is expensive enough that the syntax parser requires writing an explicit comparison against zero to make mistakes less likely, e\[char46]g\[char46] in \fBtcp\[char46]src != 0\fR the comparison against 0 is required\[char46] +.IP +\fBOperator precedence\fR is as shown below, from highest to lowest\[char46] There are two exceptions where parentheses are required even though the table would suggest that they are not: \fB&&\fR and \fB||\fR require parentheses when used together, and \fB!\fR requires parentheses when applied to a relational expression\[char46] Thus, in \fB(eth\[char46]type == 0x800 || eth\[char46]type == 0x86dd) +&& ip\[char46]proto == 6\fR or \fB!(arp\[char46]op == 1)\fR, the parentheses are mandatory\[char46] +.RS +.IP \(bu +\fB()\fR +.IP \(bu +\fB== != < <= > >=\fR +.IP \(bu +\fB!\fR +.IP \(bu +\fB&& ||\fR +.RE +.IP +\fBComments\fR may be introduced by \fB//\fR, which extends to the next new-line\[char46] Comments within a line may be bracketed by \fB/*\fR and \fB*/\fR\[char46] Multiline comments are not supported\[char46] +.IP +\fBSymbols\fR +.IP +Most of the symbols below have integer type\[char46] Only \fBinport\fR and \fBoutport\fR have string type\[char46] \fBinport\fR names a logical port\[char46] Thus, its value is a \fBlogical_port\fR name from the \fBPort_Binding\fR table\[char46] \fBoutport\fR may name a logical port, as \fBinport\fR, or a logical multicast group defined in the \fBMulticast_Group\fR table\[char46] For both symbols, only names within the flow\(cqs logical datapath may be used\[char46] +.IP +The \fBreg\fR\fIX\fR symbols are 32-bit integers\[char46] The \fBxxreg\fR\fIX\fR symbols are 128-bit integers, which overlay four of the 32-bit registers: \fBxxreg0\fR overlays \fBreg0\fR through \fBreg3\fR, with \fBreg0\fR supplying the most-significant bits of \fBxxreg0\fR and \fBreg3\fR the least-significant\[char46] \fBxxreg1\fR similarly overlays \fBreg4\fR through \fBreg7\fR\[char46] +.RS +.IP \(bu +\fBreg0\fR\[char46]\[char46]\[char46]\fBreg9\fR +.IP \(bu +\fBxxreg0\fR \fBxxreg1\fR +.IP \(bu +\fBinport\fR \fBoutport\fR +.IP \(bu +\fBflags\[char46]loopback\fR +.IP \(bu +\fBpkt\[char46]mark\fR +.IP \(bu +\fBeth\[char46]src\fR \fBeth\[char46]dst\fR \fBeth\[char46]type\fR +.IP \(bu +\fBvlan\[char46]tci\fR \fBvlan\[char46]vid\fR \fBvlan\[char46]pcp\fR \fBvlan\[char46]present\fR +.IP \(bu +\fBip\[char46]proto\fR \fBip\[char46]dscp\fR \fBip\[char46]ecn\fR \fBip\[char46]ttl\fR \fBip\[char46]frag\fR +.IP \(bu +\fBip4\[char46]src\fR \fBip4\[char46]dst\fR +.IP \(bu +\fBip6\[char46]src\fR \fBip6\[char46]dst\fR \fBip6\[char46]label\fR +.IP \(bu +\fBarp\[char46]op\fR \fBarp\[char46]spa\fR \fBarp\[char46]tpa\fR \fBarp\[char46]sha\fR \fBarp\[char46]tha\fR +.IP \(bu +\fBrarp\[char46]op\fR \fBrarp\[char46]spa\fR \fBrarp\[char46]tpa\fR \fBrarp\[char46]sha\fR \fBrarp\[char46]tha\fR +.IP \(bu +\fBtcp\[char46]src\fR \fBtcp\[char46]dst\fR \fBtcp\[char46]flags\fR +.IP \(bu +\fBudp\[char46]src\fR \fBudp\[char46]dst\fR +.IP \(bu +\fBsctp\[char46]src\fR \fBsctp\[char46]dst\fR +.IP \(bu +\fBicmp4\[char46]type\fR \fBicmp4\[char46]code\fR +.IP \(bu +\fBicmp6\[char46]type\fR \fBicmp6\[char46]code\fR +.IP \(bu +\fBnd\[char46]target\fR \fBnd\[char46]sll\fR \fBnd\[char46]tll\fR +.IP \(bu +\fBct_mark\fR \fBct_label\fR +.IP \(bu +\fBct_state\fR, which has several Boolean subfields\[char46] The \fBct_next\fR action initializes the following subfields: +.RS +.IP \(bu +\fBct\[char46]trk\fR: Always set to true by \fBct_next\fR to indicate that connection tracking has taken place\[char46] All other \fBct\fR subfields have \fBct\[char46]trk\fR as a prerequisite\[char46] +.IP \(bu +\fBct\[char46]new\fR: True for a new flow +.IP \(bu +\fBct\[char46]est\fR: True for an established flow +.IP \(bu +\fBct\[char46]rel\fR: True for a related flow +.IP \(bu +\fBct\[char46]rpl\fR: True for a reply flow +.IP \(bu +\fBct\[char46]inv\fR: True for a connection entry in a bad state +.RE +.IP +The \fBct_dnat\fR, \fBct_snat\fR, and \fBct_lb\fR actions initialize the following subfields: +.RS +.IP \(bu +\fBct\[char46]dnat\fR: True for a packet whose destination IP address has been changed\[char46] +.IP \(bu +\fBct\[char46]snat\fR: True for a packet whose source IP address has been changed\[char46] +.RE +.RE +.IP +The following predicates are supported: +.RS +.IP \(bu +\fBeth\[char46]bcast\fR expands to \fBeth\[char46]dst == ff:ff:ff:ff:ff:ff\fR +.IP \(bu +\fBeth\[char46]mcast\fR expands to \fBeth\[char46]dst[40]\fR +.IP \(bu +\fBvlan\[char46]present\fR expands to \fBvlan\[char46]tci[12]\fR +.IP \(bu +\fBip4\fR expands to \fBeth\[char46]type == 0x800\fR +.IP \(bu +\fBip4\[char46]src_mcast\fR expands to \fBip4\[char46]src[28\[char46]\[char46]31] == 0xe\fR +.IP \(bu +\fBip4\[char46]mcast\fR expands to \fBip4\[char46]dst[28\[char46]\[char46]31] == 0xe\fR +.IP \(bu +\fBip6\fR expands to \fBeth\[char46]type == 0x86dd\fR +.IP \(bu +\fBip\fR expands to \fBip4 || ip6\fR +.IP \(bu +\fBicmp4\fR expands to \fBip4 && ip\[char46]proto == 1\fR +.IP \(bu +\fBicmp6\fR expands to \fBip6 && ip\[char46]proto == 58\fR +.IP \(bu +\fBicmp\fR expands to \fBicmp4 || icmp6\fR +.IP \(bu +\fBip\[char46]is_frag\fR expands to \fBip\[char46]frag[0]\fR +.IP \(bu +\fBip\[char46]later_frag\fR expands to \fBip\[char46]frag[1]\fR +.IP \(bu +\fBip\[char46]first_frag\fR expands to \fBip\[char46]is_frag && !ip\[char46]later_frag\fR +.IP \(bu +\fBarp\fR expands to \fBeth\[char46]type == 0x806\fR +.IP \(bu +\fBrarp\fR expands to \fBeth\[char46]type == 0x8035\fR +.IP \(bu +\fBnd\fR expands to \fBicmp6\[char46]type == {135, 136} && icmp6\[char46]code == 0 && ip\[char46]ttl == 255\fR +.IP \(bu +\fBnd_ns\fR expands to \fBicmp6\[char46]type == 135 && icmp6\[char46]code == 0 && ip\[char46]ttl == 255\fR +.IP \(bu +\fBnd_na\fR expands to \fBicmp6\[char46]type == 136 && icmp6\[char46]code == 0 && ip\[char46]ttl == 255\fR +.IP \(bu +\fBnd_rs\fR expands to \fBicmp6\[char46]type == 133 && +icmp6\[char46]code == 0 && ip\[char46]ttl == 255\fR +.IP \(bu +\fBnd_ra\fR expands to \fBicmp6\[char46]type == 134 && +icmp6\[char46]code == 0 && ip\[char46]ttl == 255\fR +.IP \(bu +\fBtcp\fR expands to \fBip\[char46]proto == 6\fR +.IP \(bu +\fBudp\fR expands to \fBip\[char46]proto == 17\fR +.IP \(bu +\fBsctp\fR expands to \fBip\[char46]proto == 132\fR +.RE +.IP "\fBactions\fR: string" +Logical datapath actions, to be executed when the logical flow represented by this row is the highest-priority match\[char46] +.IP +Actions share lexical syntax with the \fBmatch\fR column\[char46] An empty set of actions (or one that contains just white space or comments), or a set of actions that consists of just \fBdrop;\fR, causes the matched packets to be dropped\[char46] Otherwise, the column should contain a sequence of actions, each terminated by a semicolon\[char46] +.IP +The following actions are defined: +.RS +.TP +\fBoutput;\fR +In the ingress pipeline, this action executes the \fBegress\fR pipeline as a subroutine\[char46] If \fBoutport\fR names a logical port, the egress pipeline executes once; if it is a multicast group, the egress pipeline runs once for each logical port in the group\[char46] +.IP +In the egress pipeline, this action performs the actual output to the \fBoutport\fR logical port\[char46] (In the egress pipeline, \fBoutport\fR never names a multicast group\[char46]) +.IP +By default, output to the input port is implicitly dropped, that is, \fBoutput\fR becomes a no-op if \fBoutport\fR == \fBinport\fR\[char46] Occasionally it may be useful to override this behavior, e\[char46]g\[char46] to send an ARP reply to an ARP request; to do so, use \fBflags\[char46]loopback = 1\fR to allow the packet to \(dqhair-pin\(dq back to the input port\[char46] +.TP +\fBnext;\fR +.TQ .5in +\fBnext(\fItable\fB);\fR +.TQ .5in +\fBnext(pipeline=\fIpipeline\fB, table=\fItable\fB);\fR +Executes the given logical datapath \fItable\fR in \fIpipeline\fR as a subroutine\[char46] The default \fItable\fR is just after the current one\[char46] If \fIpipeline\fR is specified, it may be \fBingress\fR or \fBegress\fR; the default \fIpipeline\fR is the one currently executing\[char46] Actions in the both ingress and egress pipeline can use \fBnext\fR to jump across the other pipeline\[char46] Actions in the ingress pipeline should use \fBnext\fR 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\[char46] +.TP +\fB\fIfield\fB = \fIconstant\fB;\fR +Sets data or metadata field \fIfield\fR to constant value \fIconstant\fR, e\[char46]g\[char46] \fBoutport = \(dqvif0\(dq;\fR to set the logical output port\[char46] To set only a subset of bits in a field, specify a subfield for \fIfield\fR or a masked \fIconstant\fR, e\[char46]g\[char46] one may use \fBvlan\[char46]pcp[2] = 1;\fR or \fBvlan\[char46]pcp = 4/4;\fR to set the most significant bit of the VLAN PCP\[char46] +.IP +Assigning to a field with prerequisites implicitly adds those prerequisites to \fBmatch\fR; thus, for example, a flow that sets \fBtcp\[char46]dst\fR applies only to TCP flows, regardless of whether its \fBmatch\fR mentions any TCP field\[char46] +.IP +Not all fields are modifiable (e\[char46]g\[char46] \fBeth\[char46]type\fR and \fBip\[char46]proto\fR are read-only), and not all modifiable fields may be partially modified (e\[char46]g\[char46] \fBip\[char46]ttl\fR must assigned as a whole)\[char46] The \fBoutport\fR field is modifiable in the \fBingress\fR pipeline but not in the \fBegress\fR pipeline\[char46] +.TP +\fB\fIovn_field\fB = \fIconstant\fB;\fR +Sets OVN field \fIovn_field\fR to constant value \fIconstant\fR\[char46] +.IP +\fBOVN\fR supports setting the values of certain fields which are not yet supported in OpenFlow to set or modify them\[char46] +.IP +Below are the supported \fBOVN fields\fR: +.RS +.IP \(bu +\fBicmp4\[char46]frag_mtu\fR \fBicmp6\[char46]frag_mtu\fR +.IP +This field sets the low-order 16 bits of the ICMP{4,6} header field that is labelled \(dqunused\(dq in the ICMP specification as defined in the RFC 1191 with the value specified in \fIconstant\fR\[char46] +.IP +Eg\[char46] icmp4\[char46]frag_mtu = 1500; +.RE +.TP +\fB\fIfield1\fB = \fIfield2\fB;\fR +Sets data or metadata field \fIfield1\fR to the value of data or metadata field \fIfield2\fR, e\[char46]g\[char46] \fBreg0 = +ip4\[char46]src;\fR copies \fBip4\[char46]src\fR into \fBreg0\fR\[char46] To modify only a subset of a field\(cqs bits, specify a subfield for \fIfield1\fR or \fIfield2\fR or both, e\[char46]g\[char46] \fBvlan\[char46]pcp += reg0[0\[char46]\[char46]2];\fR copies the least-significant bits of \fBreg0\fR into the VLAN PCP\[char46] +.IP +\fIfield1\fR and \fIfield2\fR must be the same type, either both string or both integer fields\[char46] If they are both integer fields, they must have the same width\[char46] +.IP +If \fIfield1\fR or \fIfield2\fR has prerequisites, they are added implicitly to \fBmatch\fR\[char46] It is possible to write an assignment with contradictory prerequisites, such as \fBip4\[char46]src = ip6\[char46]src[0\[char46]\[char46]31];\fR, but the contradiction means that a logical flow with such an assignment will never be matched\[char46] +.TP +\fB\fIfield1\fB <\-> \fIfield2\fB;\fR +Similar to \fB\fIfield1\fB = \fIfield2\fB;\fR except that the two values are exchanged instead of copied\[char46] Both \fIfield1\fR and \fIfield2\fR must modifiable\[char46] +.TP +\fBpush(\fIfield\fB);\fR +Push the value of \fIfield\fR to the stack top\[char46] +.TP +\fBpop(\fIfield\fB);\fR +Pop the stack top and store the value to \fIfield\fR, which must be modifiable\[char46] +.TP +\fBip\[char46]ttl\-\-;\fR +Decrements the IPv4 or IPv6 TTL\[char46] If this would make the TTL zero or negative, then processing of the packet halts; no further actions are processed\[char46] (To properly handle such cases, a higher-priority flow should match on \fBip\[char46]ttl == {0, 1};\fR\[char46]) +.IP +\fBPrerequisite:\fR \fBip\fR +.TP +\fBct_next;\fR +Apply connection tracking to the flow, initializing \fBct_state\fR for matching in later tables\[char46] Automatically moves on to the next table, as if followed by \fBnext\fR\[char46] +.IP +As a side effect, IP fragments will be reassembled for matching\[char46] If a fragmented packet is output, then it will be sent with any overlapping fragments squashed\[char46] The connection tracking state is scoped by the logical port when the action is used in a flow for a logical switch, so overlapping addresses may be used\[char46] To allow traffic related to the matched flow, execute \fBct_commit +\fR\[char46] Connection tracking state is scoped by the logical topology when the action is used in a flow for a router\[char46] +.IP +It is possible to have actions follow \fBct_next\fR, but they will not have access to any of its side-effects and is not generally useful\[char46] +.TP +\fBct_commit { };\fR +.TQ .5in +\fBct_commit { ct_mark=\fIvalue[/mask]\fB; };\fR +.TQ .5in +\fBct_commit { ct_label=\fIvalue[/mask]\fB; };\fR +.TQ .5in +\fBct_commit { ct_mark=\fIvalue[/mask]\fB; ct_label=\fIvalue[/mask]\fB; };\fR +Commit the flow to the connection tracking entry associated with it by a previous call to \fBct_next\fR\[char46] When \fBct_mark=\fIvalue[/mask]\fB\fR and/or \fBct_label=\fIvalue[/mask]\fB\fR are supplied, \fBct_mark\fR and/or \fBct_label\fR will be set to the values indicated by \fIvalue[/mask]\fR on the connection tracking entry\[char46] \fBct_mark\fR is a 32-bit field\[char46] \fBct_label\fR is a 128-bit field\[char46] The \fIvalue[/mask]\fR should be specified in hex string if more than 64bits are to be used\[char46] Registers and other named fields can be used for \fIvalue\fR\[char46] \fBct_mark\fR and \fBct_label\fR may be sub-addressed in order to have specific bits set\[char46] +.IP +Note that if you want processing to continue in the next table, you must execute the \fBnext\fR action after \fBct_commit\fR\[char46] You may also leave out \fBnext\fR which will commit connection tracking state, and then drop the packet\[char46] This could be useful for setting \fBct_mark\fR on a connection tracking entry before dropping a packet, for example\[char46] +.TP +\fBct_dnat;\fR +.TQ .5in +\fBct_dnat(\fIIP\fB);\fR +\fBct_dnat\fR sends the packet through the DNAT zone in connection tracking table to unDNAT any packet that was DNATed in the opposite direction\[char46] The packet is then automatically sent to to the next tables as if followed by \fBnext;\fR action\[char46] The next tables will see the changes in the packet caused by the connection tracker\[char46] +.IP +\fBct_dnat(\fIIP\fB)\fR 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\[char46] The packet is then automatically sent to the next tables as if followed by \fBnext;\fR action\[char46] The next tables will see the changes in the packet caused by the connection tracker\[char46] +.TP +\fBct_snat;\fR +.TQ .5in +\fBct_snat(\fIIP\fB);\fR +\fBct_snat\fR sends the packet through the SNAT zone to unSNAT any packet that was SNATed in the opposite direction\[char46] The packet is automatically sent to the next tables as if followed by the \fBnext;\fR action\[char46] The next tables will see the changes in the packet caused by the connection tracker\[char46] +.IP +\fBct_snat(\fIIP\fB)\fR sends the packet through the SNAT zone to change the source IP address of the packet to the one provided inside the parenthesis and commits the connection\[char46] The packet is then automatically sent to the next tables as if followed by \fBnext;\fR action\[char46] The next tables will see the changes in the packet caused by the connection tracker\[char46] +.TP +\fBct_dnat_in_czone;\fR +.TQ .5in +\fBct_dnat_in_czone(\fIIP\fB);\fR +\fBct_dnat_in_czone\fR sends the packet through the common NAT zone (used for both DNAT and SNAT) in connection tracking table to unDNAT any packet that was DNATed in the opposite direction\[char46] The packet is then automatically sent to to the next tables as if followed by \fBnext;\fR action\[char46] The next tables will see the changes in the packet caused by the connection tracker\[char46] +.IP +\fBct_dnat_in_czone(\fIIP\fB)\fR 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\[char46] The packet is then automatically sent to the next tables as if followed by \fBnext;\fR action\[char46] The next tables will see the changes in the packet caused by the connection tracker\[char46] +.TP +\fBct_snat_in_czone;\fR +.TQ .5in +\fBct_snat_in_czone(\fIIP\fB);\fR +\fBct_snat_in_czone\fR sends the packet through the common NAT zone to unSNAT any packet that was SNATed in the opposite direction\[char46] The packet is automatically sent to the next tables as if followed by the \fBnext;\fR action\[char46] The next tables will see the changes in the packet caused by the connection tracker\[char46] +.IP +\fBct_snat_in_czone(\fIIP\fB)\fR sends the packet\e 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\[char46] The packet is then automatically sent to the next tables as if followed by \fBnext;\fR action\[char46] The next tables will see the changes in the packet caused by the connection tracker\[char46] +.TP +\fBct_clear;\fR +Clears connection tracking state\[char46] +.TP +\fBct_commit_nat;\fR +Applies NAT and commits the connection to the CT\[char46] Automatically moves on to the next table, as if followed by \fBnext\fR\[char46] This is very useful for connections that are in related state for already existing connections and allows the NAT to be applied to them as well\[char46] +.TP +\fBclone { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR +Makes a copy of the packet being processed and executes each \fBaction\fR on the copy\[char46] Actions following the \fIclone\fR action, if any, apply to the original, unmodified packet\[char46] This can be used as a way to ``save and restore\(cq\(cq the packet around a set of actions that may modify it and should not persist\[char46] +.TP +\fBarp { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR +Temporarily replaces the IPv4 packet being processed by an ARP packet and executes each nested \fIaction\fR on the ARP packet\[char46] Actions following the \fIarp\fR action, if any, apply to the original, unmodified packet\[char46] +.IP +The ARP packet that this action operates on is initialized based on the IPv4 packet being processed, as follows\[char46] These are default values that the nested actions will probably want to change: +.RS +.IP \(bu +\fBeth\[char46]src\fR unchanged +.IP \(bu +\fBeth\[char46]dst\fR unchanged +.IP \(bu +\fBeth\[char46]type = 0x0806\fR +.IP \(bu +\fBarp\[char46]op = 1\fR (ARP request) +.IP \(bu +\fBarp\[char46]sha\fR copied from \fBeth\[char46]src\fR +.IP \(bu +\fBarp\[char46]spa\fR copied from \fBip4\[char46]src\fR +.IP \(bu +\fBarp\[char46]tha = 00:00:00:00:00:00\fR +.IP \(bu +\fBarp\[char46]tpa\fR copied from \fBip4\[char46]dst\fR +.RE +.IP +The ARP packet has the same VLAN header, if any, as the IP packet it replaces\[char46] +.IP +\fBPrerequisite:\fR \fBip4\fR +.TP +\fBget_arp(\fIP\fB, \fIA\fB);\fR +\fBParameters\fR: logical port string field \fIP\fR, 32-bit IP address field \fIA\fR\[char46] +.IP +Looks up \fIA\fR in \fIP\fR\(cqs mac binding table\[char46] If an entry is found, stores its Ethernet address in \fBeth\[char46]dst\fR, otherwise stores \fB00:00:00:00:00:00\fR in \fBeth\[char46]dst\fR\[char46] +.IP +\fBExample:\fR \fBget_arp(outport, ip4\[char46]dst);\fR +.TP +\fBput_arp(\fIP\fB, \fIA\fB, \fIE\fB);\fR +\fBParameters\fR: logical port string field \fIP\fR, 32-bit IP address field \fIA\fR, 48-bit Ethernet address field \fIE\fR\[char46] +.IP +Adds or updates the entry for IP address \fIA\fR in logical port \fIP\fR\(cqs mac binding table, setting its Ethernet address to \fIE\fR\[char46] +.IP +\fBExample:\fR \fBput_arp(inport, arp\[char46]spa, arp\[char46]sha);\fR +.TP +\fB\fIR\fB = lookup_arp(\fIP\fB, \fIA\fB, \fIM\fB);\fR +\fBParameters\fR: logical port string field \fIP\fR, 32-bit IP address field \fIA\fR, 48-bit MAC address field \fIM\fR\[char46] +.IP +\fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] +.IP +Looks up \fIA\fR and \fIM\fR in \fIP\fR\(cqs mac binding table\[char46] If an entry is found, stores \fB1\fR in the 1-bit subfield \fIR\fR, else 0\[char46] +.IP +\fBExample:\fR \fB +reg0[0] = lookup_arp(inport, arp\[char46]spa, arp\[char46]sha); +\fR +.TP +\fB\fIR\fB = lookup_arp_ip(\fIP\fB, \fIA\fB);\fR +\fBParameters\fR: logical port string field \fIP\fR, 32-bit IP address field \fIA\fR\[char46] +.IP +\fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] +.IP +Looks up \fIA\fR in \fIP\fR\(cqs mac binding table\[char46] If an entry is found, stores \fB1\fR in the 1-bit subfield \fIR\fR, else 0\[char46] +.IP +\fBExample:\fR \fB +reg0[0] = lookup_arp_ip(inport, arp\[char46]spa); +\fR +.TP +\fB\fIP\fB = get_fdb(\fIA\fB);\fR +\fBParameters\fR:48-bit MAC address field \fIA\fR\[char46] +.IP +Looks up \fIA\fR in fdb table\[char46] If an entry is found, stores the logical port key to the out parameter \fBP\fR\[char46] +.IP +\fBExample:\fR \fBoutport = get_fdb(eth\[char46]src);\fR +.TP +\fBput_fdb(\fIP\fB, \fIA\fB);\fR +\fBParameters\fR: logical port string field \fIP\fR, 48-bit MAC address field \fIA\fR\[char46] +.IP +Adds or updates the entry for Ethernet address \fIA\fR in fdb table, setting its logical port key to \fIP\fR\[char46] +.IP +\fBExample:\fR \fBput_fdb(inport, arp\[char46]spa);\fR +.TP +\fB\fIR\fB = lookup_fdb(\fIP\fB, \fIA\fB);\fR +\fBParameters\fR: 48-bit MAC address field \fIM\fR, logical port string field \fIP\fR\[char46] +.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 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); +\fR +.TP +\fBnd_ns { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR +Temporarily replaces the IPv6 packet being processed by an IPv6 Neighbor Solicitation packet and executes each nested \fIaction\fR on the IPv6 NS packet\[char46] Actions following the \fInd_ns\fR action, if any, apply to the original, unmodified packet\[char46] +.IP +The IPv6 NS packet that this action operates on is initialized based on the IPv6 packet being processed, as follows\[char46] These are default values that the nested actions will probably want to change: +.RS +.IP \(bu +\fBeth\[char46]src\fR unchanged +.IP \(bu +\fBeth\[char46]dst\fR set to IPv6 multicast MAC address +.IP \(bu +\fBeth\[char46]type = 0x86dd\fR +.IP \(bu +\fBip6\[char46]src\fR copied from \fBip6\[char46]src\fR +.IP \(bu +\fBip6\[char46]dst\fR set to IPv6 Solicited-Node multicast address +.IP \(bu +\fBicmp6\[char46]type = 135\fR (Neighbor Solicitation) +.IP \(bu +\fBnd\[char46]target\fR copied from \fBip6\[char46]dst\fR +.RE +.IP +The IPv6 NS packet has the same VLAN header, if any, as the IP packet it replaces\[char46] +.IP +\fBPrerequisite:\fR \fBip6\fR +.TP +\fBnd_na { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR +Temporarily replaces the IPv6 neighbor solicitation packet being processed by an IPv6 neighbor advertisement (NA) packet and executes each nested \fIaction\fR on the NA packet\[char46] Actions following the \fBnd_na\fR action, if any, apply to the original, unmodified packet\[char46] +.IP +The NA packet that this action operates on is initialized based on the IPv6 packet being processed, as follows\[char46] These are default values that the nested actions will probably want to change: +.RS +.IP \(bu +\fBeth\[char46]dst\fR exchanged with \fBeth\[char46]src\fR +.IP \(bu +\fBeth\[char46]type = 0x86dd\fR +.IP \(bu +\fBip6\[char46]dst\fR copied from \fBip6\[char46]src\fR +.IP \(bu +\fBip6\[char46]src\fR copied from \fBnd\[char46]target\fR +.IP \(bu +\fBicmp6\[char46]type = 136\fR (Neighbor Advertisement) +.IP \(bu +\fBnd\[char46]target\fR unchanged +.IP \(bu +\fBnd\[char46]sll = 00:00:00:00:00:00\fR +.IP \(bu +\fBnd\[char46]tll\fR copied from \fBeth\[char46]dst\fR +.RE +.IP +The ND packet has the same VLAN header, if any, as the IPv6 packet it replaces\[char46] +.IP +\fBPrerequisite:\fR \fBnd_ns\fR +.TP +\fBnd_na_router { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR +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 \fIaction\fR on the NA packet\[char46] Actions following the \fBnd_na_router\fR action, if any, apply to the original, unmodified packet\[char46] +.IP +The NA packet that this action operates on is initialized based on the IPv6 packet being processed, as follows\[char46] These are default values that the nested actions will probably want to change: +.RS +.IP \(bu +\fBeth\[char46]dst\fR exchanged with \fBeth\[char46]src\fR +.IP \(bu +\fBeth\[char46]type = 0x86dd\fR +.IP \(bu +\fBip6\[char46]dst\fR copied from \fBip6\[char46]src\fR +.IP \(bu +\fBip6\[char46]src\fR copied from \fBnd\[char46]target\fR +.IP \(bu +\fBicmp6\[char46]type = 136\fR (Neighbor Advertisement) +.IP \(bu +\fBnd\[char46]target\fR unchanged +.IP \(bu +\fBnd\[char46]sll = 00:00:00:00:00:00\fR +.IP \(bu +\fBnd\[char46]tll\fR copied from \fBeth\[char46]dst\fR +.RE +.IP +The ND packet has the same VLAN header, if any, as the IPv6 packet it replaces\[char46] +.IP +\fBPrerequisite:\fR \fBnd_ns\fR +.TP +\fBget_nd(\fIP\fB, \fIA\fB);\fR +\fBParameters\fR: logical port string field \fIP\fR, 128-bit IPv6 address field \fIA\fR\[char46] +.IP +Looks up \fIA\fR in \fIP\fR\(cqs mac binding table\[char46] If an entry is found, stores its Ethernet address in \fBeth\[char46]dst\fR, otherwise stores \fB00:00:00:00:00:00\fR in \fBeth\[char46]dst\fR\[char46] +.IP +\fBExample:\fR \fBget_nd(outport, ip6\[char46]dst);\fR +.TP +\fBput_nd(\fIP\fB, \fIA\fB, \fIE\fB);\fR +\fBParameters\fR: logical port string field \fIP\fR, 128-bit IPv6 address field \fIA\fR, 48-bit Ethernet address field \fIE\fR\[char46] +.IP +Adds or updates the entry for IPv6 address \fIA\fR in logical port \fIP\fR\(cqs mac binding table, setting its Ethernet address to \fIE\fR\[char46] +.IP +\fBExample:\fR \fBput_nd(inport, nd\[char46]target, nd\[char46]tll);\fR +.TP +\fB\fIR\fB = lookup_nd(\fIP\fB, \fIA\fB, \fIM\fB);\fR +\fBParameters\fR: logical port string field \fIP\fR, 128-bit IP address field \fIA\fR, 48-bit MAC address field \fIM\fR\[char46] +.IP +\fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] +.IP +Looks up \fIA\fR and \fIM\fR in \fIP\fR\(cqs mac binding table\[char46] If an entry is found, stores \fB1\fR in the 1-bit subfield \fIR\fR, else 0\[char46] +.IP +\fBExample:\fR \fB +reg0[0] = lookup_nd(inport, ip6\[char46]src, eth\[char46]src); +\fR +.TP +\fB\fIR\fB = lookup_nd_ip(\fIP\fB, \fIA\fB);\fR +\fBParameters\fR: logical port string field \fIP\fR, 128-bit IP address field \fIA\fR\[char46] +.IP +\fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] +.IP +Looks up \fIA\fR in \fIP\fR\(cqs mac binding table\[char46] If an entry is found, stores \fB1\fR in the 1-bit subfield \fIR\fR, else 0\[char46] +.IP +\fBExample:\fR \fB +reg0[0] = lookup_nd_ip(inport, ip6\[char46]src); +\fR +.TP +\fB\fIR\fB = put_dhcp_opts(\fID1\fB = \fIV1\fB, \fID2\fB = \fIV2\fB, \[char46]\[char46]\[char46], \fIDn\fB = \fIVn\fB);\fR +\fBParameters\fR: one or more DHCP option/value pairs, which must include an \fBofferip\fR option (with code 0)\[char46] +.IP +\fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] +.IP +Valid only in the ingress pipeline\[char46] +.IP +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 in \fIR\fR\[char46] +.IP +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 \fIR\fR\[char46] +.IP +The contents of the \fBDHCP_Option\fR table control the DHCP option names and values that this action supports\[char46] +.IP +\fBExample:\fR \fB +reg0[0] = put_dhcp_opts(offerip = 10\[char46]0\[char46]0\[char46]2, router = 10\[char46]0\[char46]0\[char46]1, +netmask = 255\[char46]255\[char46]255\[char46]0, dns_server = {8\[char46]8\[char46]8\[char46]8, 7\[char46]7\[char46]7\[char46]7}); +\fR +.TP +\fB\fIR\fB = put_dhcpv6_opts(\fID1\fB = \fIV1\fB, \fID2\fB = \fIV2\fB, \[char46]\[char46]\[char46], \fIDn\fB = \fIVn\fB);\fR +\fBParameters\fR: one or more DHCPv6 option/value pairs\[char46] +.IP +\fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] +.IP +Valid only in the ingress pipeline\[char46] +.IP +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 \fIR\fR\[char46] +.IP +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 \fIR\fR\[char46] +.IP +The contents of the \fBDHCPv6_Options\fR table control the DHCPv6 option names and values that this action supports\[char46] +.IP +\fBExample:\fR \fB +reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4, server_id = 00:00:00:00:10:02, +dns_server={ae70::1,ae70::2}); +\fR +.TP +\fBset_queue(\fIqueue_number\fB);\fR +\fBParameters\fR: Queue number \fIqueue_number\fR, in the range 0 to 61440\[char46] +.IP +This is a logical equivalent of the OpenFlow \fBset_queue\fR action\[char46] It affects packets that egress a hypervisor through a physical interface\[char46] For nonzero \fIqueue_number\fR, it configures packet queuing to match the settings configured for the \fBPort_Binding\fR with \fBoptions:qdisc_queue_id\fR matching \fIqueue_number\fR\[char46] When \fIqueue_number\fR is zero, it resets queuing to the default strategy\[char46] +.IP +\fBExample:\fR \fBset_queue(10);\fR +.TP +\fBct_lb;\fR +.TQ .5in +\fBct_lb(backends=\fIip\fB[:\fIport\fB][,\[char46]\[char46]\[char46]][; hash_fields=\fIfield1\fB,\fIfield2\fB,\[char46]\[char46]\[char46]][; ct_flag]);\fR +With arguments, \fBct_lb\fR commits the packet to the connection tracking table and DNATs the packet\(cqs destination IP address (and port) to the IP address or addresses (and optional ports) specified in the \fBbackends\fR\[char46] If multiple comma-separated IP addresses are specified, each is given equal weight for picking the DNAT address\[char46] By default, \fBdp_hash\fR is used as the OpenFlow group selection method, but if \fBhash_fields\fR is specified, \fBhash\fR is used as the selection method, and the fields listed are used as the hash fields\[char46] The \fBct_flag\fR field represents one of supported flag: \fBskip_snat\fR or \fBforce_snat\fR, this flag will be stored in \fBct_label\fR register\[char46] +.IP +Without arguments, \fBct_lb\fR sends the packet to the connection tracking table to NAT the packets\[char46] If the packet is part of an established connection that was previously committed to the connection tracker via \fBct_lb(\fR\[char46]\[char46]\[char46]\fB)\fR, it will automatically get DNATed to the same IP address as the first packet in that connection\[char46] +.IP +Processing automatically moves on to the next table, as if \fBnext;\fR were specified, and later tables act on the packet as modified by the connection tracker\[char46] 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\[char46] Connection tracking state is scoped by the logical topology when the action is used in a flow for a router\[char46] +.TP +\fBct_lb_mark;\fR +.TQ .5in +\fBct_lb_mark(backends=\fIip\fB[:\fIport\fB][,\[char46]\[char46]\[char46]][; hash_fields=\fIfield1\fB,\fIfield2\fB,\[char46]\[char46]\[char46]][; ct_flag]);\fR +Same as \fBct_lb\fR, except that it internally uses ct_mark to store the NAT flag, while \fBct_lb\fR uses ct_label for the same purpose\[char46] +.TP +\fB\fIR\fB = dns_lookup();\fR +\fBParameters\fR: No parameters\[char46] +.IP +\fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] +.IP +Valid only in the ingress pipeline\[char46] +.IP +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 \fBDNS\fR table\[char46] If it is successful, it changes the packet into a DNS reply and stores 1 in \fIR\fR\[char46] If the action is applied to a non-DNS packet, an invalid DNS request packet, or a valid DNS request for which the \fBDNS\fR table does not supply an answer, it leaves the packet unchanged and stores 0 in \fIR\fR\[char46] +.IP +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\[char46] The logical pipeline can implement this behavior with matches and actions in later tables\[char46] +.IP +\fBExample:\fR \fB +reg0[3] = dns_lookup(); +\fR +.IP +\fBPrerequisite:\fR \fBudp\fR +.TP +\fB\fIR\fB = put_nd_ra_opts(\fID1\fB = \fIV1\fB, \fID2\fB = \fIV2\fB, \[char46]\[char46]\[char46], \fIDn\fB = \fIVn\fB);\fR +\fBParameters\fR: The following IPv6 ND Router Advertisement option/value pairs as defined in RFC 4861\[char46] +.RS +.IP \(bu +\fBaddr_mode\fR +.IP +Mandatory parameter which specifies the address mode flag to be set in the RA flag options field\[char46] The value of this option is a string and the following values can be defined - \(dqslaac\(dq, \(dqdhcpv6_stateful\(dq and \(dqdhcpv6_stateless\(dq\[char46] +.IP \(bu +\fBslla\fR +.IP +Mandatory parameter which specifies the link-layer address of the interface from which the Router Advertisement is sent\[char46] +.IP \(bu +\fBmtu\fR +.IP +Optional parameter which specifies the MTU\[char46] +.IP \(bu +\fBprefix\fR +.IP +Optional parameter which should be specified if the addr_mode is \(dqslaac\(dq or \(dqdhcpv6_stateless\(dq\[char46] The value should be an IPv6 prefix which will be used for stateless IPv6 address configuration\[char46] This option can be defined multiple times\[char46] +.RE +.IP +\fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] +.IP +Valid only in the ingress pipeline\[char46] +.IP +When this action is applied to an IPv6 Router solicitation request packet, it changes the packet into an IPv6 Router Advertisement reply and adds the options specified in the parameters, and stores 1 in \fIR\fR\[char46] +.IP +When this action is applied to a non-IPv6 Router solicitation packet or an invalid IPv6 request packet , it leaves the packet unchanged and stores 0 in \fIR\fR\[char46] +.IP +\fBExample:\fR \fB +reg0[3] = put_nd_ra_opts(addr_mode = \(dqslaac\(dq, +slla = 00:00:00:00:10:02, prefix = aef0::/64, mtu = 1450); +\fR +.TP +\fBset_meter(\fIrate\fB);\fR +.TQ .5in +\fBset_meter(\fIrate\fB, \fIburst\fB);\fR +\fBParameters\fR: rate limit int field \fIrate\fR in kbps, burst rate limits int field \fIburst\fR in kbps\[char46] +.IP +This action sets the rate limit for a flow\[char46] +.IP +\fBExample:\fR \fBset_meter(100, 1000);\fR +.TP +\fB\fIR\fB = check_pkt_larger(\fIL\fB)\fR +\fBParameters\fR: packet length \fIL\fR to check for in bytes\[char46] +.IP +\fBResult\fR: stored to a 1-bit subfield \fIR\fR\[char46] +.IP +This is a logical equivalent of the OpenFlow \fBcheck_pkt_larger\fR action\[char46] If the packet is larger than the length specified in \fIL\fR, it stores 1 in the subfield \fIR\fR\[char46] +.IP +\fBExample: \fR\fBreg0[6] = check_pkt_larger(1000);\fR +.RE +.RS +.TP +\fBlog(\fIkey\fB=\fIvalue\fB, \fR\[char46]\[char46]\[char46]\fB);\fR +Causes \fBovn\-controller\fR to log the packet on the chassis that processes it\[char46] Packet logging currently uses the same logging mechanism as other Open vSwitch and OVN messages, which means that whether and where log messages appear depends on the local logging configuration that can be configured with \fBovs\-appctl\fR, etc\[char46] +.IP +The \fBlog\fR action takes zero or more of the following key-value pair arguments that control what is logged: +.RS +.TP +\fBname=\fR\fIstring\fR +An optional name for the ACL\[char46] The \fIstring\fR is currently limited to 64 bytes\[char46] +.TP +\fBseverity=\fR\fIlevel\fR +Indicates the severity of the event\[char46] The \fIlevel\fR is one of following (from more to less serious): \fBalert\fR, \fBwarning\fR, \fBnotice\fR, \fBinfo\fR, or \fBdebug\fR\[char46] If a severity is not provided, the default is \fBinfo\fR\[char46] +.TP +\fBverdict=\fR\fIvalue\fR +The verdict for packets matching the flow\[char46] The value must be one of \fBallow\fR, \fBdeny\fR, or \fBreject\fR\[char46] +.TP +\fBmeter=\fR\fIstring\fR +An optional rate-limiting meter to be applied to the logs\[char46] The \fIstring\fR should reference a \fBname\fR entry from the \fBMeter\fR table\[char46] The only meter \fBaction\fR that is appropriate is \fBdrop\fR\[char46] +.RE +.TP +\fBfwd_group(liveness=\fIbool\fB, childports=\fIport\fB, \[char46]\[char46]\[char46]);\fR +\fBParameters\fR: optional \fBliveness\fR, either \fBtrue\fR or \fBfalse\fR, defaulting to false; \fBchildports\fR, a comma-delimited list of strings denoting logical ports to load balance across\[char46] +.IP +Load balance traffic to one or more child ports in a logical switch\[char46] \fBovn\-controller\fR translates the \fBfwd_group\fR into an OpenFlow group with one bucket for each child port\[char46] If \fBliveness=true\fR is specified, it also integrates the bucket selection with BFD status on the tunnel interface corresponding to child port\[char46] +.IP +\fBExample:\fR \fBfwd_group(liveness=true, childports=\(dqp1\(dq, +\(dqp2\(dq);\fR +.RE +.RS +.TP +\fBicmp4 { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR +.TQ .5in +\fBicmp4_error { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR +Temporarily replaces the IPv4 packet being processed by an ICMPv4 packet and executes each nested \fIaction\fR on the ICMPv4 packet\[char46] Actions following these actions, if any, apply to the original, unmodified packet\[char46] +.IP +The ICMPv4 packet that these actions operates on is initialized based on the IPv4 packet being processed, as follows\[char46] These are default values that the nested actions will probably want to change\[char46] Ethernet and IPv4 fields not listed here are not changed: +.RS +.IP \(bu +\fBip\[char46]proto = 1\fR (ICMPv4) +.IP \(bu +\fBip\[char46]frag = 0\fR (not a fragment) +.IP \(bu +\fBip\[char46]ttl = 255\fR +.IP \(bu +\fBicmp4\[char46]type = 3\fR (destination unreachable) +.IP \(bu +\fBicmp4\[char46]code = 1\fR (host unreachable) +.RE +.IP +\fBicmp4_error\fR action is expected to be used to generate an ICMPv4 packet in response to an error in original IP packet\[char46] When this action generates the ICMPv4 packet, it also copies the original IP datagram following the ICMPv4 header as per RFC 1122: 3\[char46]2\[char46]2\[char46] +.IP +\fBPrerequisite:\fR \fBip4\fR +.TP +\fBicmp6 { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR +.TQ .5in +\fBicmp6_error { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR +Temporarily replaces the IPv6 packet being processed by an ICMPv6 packet and executes each nested \fIaction\fR on the ICMPv6 packet\[char46] Actions following the \fIicmp6\fR action, if any, apply to the original, unmodified packet\[char46] +.IP +The ICMPv6 packet that this action operates on is initialized based on the IPv6 packet being processed, as follows\[char46] These are default values that the nested actions will probably want to change\[char46] Ethernet and IPv6 fields not listed here are not changed: +.RS +.IP \(bu +\fBip\[char46]proto = 58\fR (ICMPv6) +.IP \(bu +\fBip\[char46]ttl = 255\fR +.IP \(bu +\fBicmp6\[char46]type = 1\fR (destination unreachable) +.IP \(bu +\fBicmp6\[char46]code = 1\fR (administratively prohibited) +.RE +.IP +\fBicmp6_error\fR action is expected to be used to generate an ICMPv6 packet in response to an error in original IPv6 packet\[char46] +.IP +\fBPrerequisite:\fR \fBip6\fR +.TP +\fBtcp_reset;\fR +This action transforms the current TCP packet according to the following pseudocode: +.IP +.nf +\fB +.br +\fBif (tcp\[char46]ack) { +.br +\fB tcp\[char46]seq = tcp\[char46]ack; +.br +\fB} else { +.br +\fB tcp\[char46]ack = tcp\[char46]seq + length(tcp\[char46]payload); +.br +\fB tcp\[char46]seq = 0; +.br +\fB} +.br +\fBtcp\[char46]flags = RST; +.br +\fB\fR +.fi +.IP +Then, the action drops all TCP options and payload data, and updates the TCP checksum\[char46] IP ttl is set to 255\[char46] +.IP +\fBPrerequisite:\fR \fBtcp\fR +.TP +\fBreject { \fIaction\fB; \fR\[char46]\[char46]\[char46]\fB };\fR +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\[char46] Otherwise it replaces it with an ICMPv4 or ICMPv6 packet and executes the inner actions\[char46] +.IP +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\[char46] +.TP +\fBtrigger_event;\fR +This action is used to allow ovs-vswitchd to report CMS related events writing them in \fBController_Event\fR table\[char46] 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\[char46] Supported events: +.RS +.IP \(bu +\fIempty_lb_backends\fR\[char46] This event is raised if a received packet is destined for a load balancer VIP that has no configured backend destinations\[char46] For this event, the event info includes the load balancer VIP, the load balancer UUID, and the transport protocol\[char46] Associated meter: \fBevent\-elb\fR +.RE +.TP +\fBigmp;\fR +This action sends the packet to \fBovn\-controller\fR for multicast snooping\[char46] +.IP +\fBPrerequisite:\fR \fBigmp\fR +.TP +\fBbind_vport(\fIV\fB, \fIP\fB);\fR +\fBParameters\fR: logical port string field \fIV\fR of type \fBvirtual\fR, logical port string field \fIP\fR\[char46] +.IP +Binds the virtual logical port \fIV\fR and sets the \fBchassis\fR column and \fBvirtual_parent\fR of the table \fBPort_Binding\fR\[char46] \fBvirtual_parent\fR is set to \fIP\fR\[char46] +.TP +\fBhandle_svc_check(\fIP\fB);\fR +\fBParameters\fR: logical port string field \fIP\fR\[char46] +.IP +Handles the service monitor reply received from the VIF of the logical port \fIP\fR\[char46] \fBovn\-controller\fR periodically sends out the service monitor packets for the services configured in the \fBService_Monitor\fR table and this action updates the status of those services\[char46] +.IP +\fBExample:\fR \fBhandle_svc_check(inport);\fR +.TP +\fBhandle_dhcpv6_reply;\fR +Handle DHCPv6 prefix delegation advertisements/replies from a IPv6 delegation server\[char46] \fBovn\-controller\fR will add an entry \fBipv6_ra_pd_list\fR in the \fBoptions\fR table for each prefix received from the delegation server +.TP +\fB\fIR\fB = select(\fIN1\fB[=\fIW1\fB], \fIN2\fB[=\fIW2\fB], \[char46]\[char46]\[char46]);\fR +\fBParameters\fR: Integer \fIN1\fR, \fIN2\fR\[char46]\[char46]\[char46], with optional weight \fIW1\fR, \fIW2\fR, \[char46]\[char46]\[char46] +.IP +\fBResult\fR: stored to a logical field or subfield \fIR\fR\[char46] +.IP +Select from a list of integers \fIN1\fR, \fIN2\fR\[char46]\[char46]\[char46], each within the range 0 ~ 65535, and store the selected one in the field \fIR\fR\[char46] There must be 2 or more integers listed, each with an optional weight, which is an integer within the range 1 ~ 65535\[char46] If weight is not specified, it defaults to 100\[char46] The selection method is based on the 5-tuple hash of packet header\[char46] +.IP +Processing automatically moves on to the next table, as if \fBnext;\fR were specified\[char46] The \fBselect\fR action must be put as the last action of the logical flow when there are multiple actions (actions put after \fBselect\fR will not take effect)\[char46] +.IP +\fBExample:\fR \fBreg8[16\[char46]\[char46]31] = select(1=20, 2=30, 3=50);\fR +.TP +\fBhandle_dhcpv6_reply;\fR +This action is used to parse DHCPv6 replies from IPv6 Delegation Router and managed IPv6 Prefix delegation state machine +.TP +\fB\fIR\fB = chk_lb_hairpin();\fR +This action checks if the packet under consideration was destined to a load balancer VIP and it is hairpinned, i\[char46]e\[char46], after load balancing the destination IP matches the source IP\[char46] If it is so, then the 1-bit destination register \fIR\fR is set to 1\[char46] +.TP +\fB\fIR\fB = chk_lb_hairpin_reply();\fR +This action checks if the packet under consideration is from one of the backend IP of a load balancer VIP and the destination IP is the load balancer VIP\[char46] If it is so, then the 1-bit destination register \fIR\fR is set to 1\[char46] +.TP +\fB\fIR\fB = ct_snat_to_vip;\fR +This action sends the packet through the SNAT zone to change the source IP address of the packet to the load balancer VIP if the original destination IP was load balancer VIP and commits the connection\[char46] This action applies successfully only for the hairpinned traffic i\[char46]e if the action \fBchk_lb_hairpin\fR returned success\[char46] This action doesn\(cqt take any arguments and it determines the SNAT IP internally\[char46] The packet is not automatically sent to the next table\[char46] The caller has to execute the \fBnext;\fR action explicitly after this action to advance the packet to the next stage\[char46] +.TP +\fB\fIR\fB = check_in_port_sec();\fR +This action checks if the packet under consideration passes the inport port security checks\[char46] If the packet fails the port security checks, then \fB1\fR is stored in the destination register \fIR\fR\[char46] Else 0 is stored\[char46] The port security values to check are retrieved from the the \fBinport\fR logical port\[char46] +.IP +This action should be used in the ingress logical switch pipeline\[char46] +.IP +\fBExample:\fR \fBreg8[0\[char46]\[char46]7] = check_in_port_sec();\fR +.TP +\fB\fIR\fB = check_out_port_sec();\fR +This action checks if the packet under consideration passes the outport port security checks\[char46] If the packet fails the port security checks, then \fB1\fR is stored in the destination register \fIR\fR\[char46] Else 0 is stored\[char46] The port security values to check are retrieved from the the \fBoutport\fR logical port\[char46] +.IP +This action should be used in the egress logical switch pipeline\[char46] +.IP +\fBExample:\fR \fBreg8[0\[char46]\[char46]7] = check_out_port_sec();\fR +.TP +\fBcommit_ecmp_nh(\fIipv6\fB);\fR +\fBParameters\fR: IPv4/IPv6 traffic\[char46] +.IP +This action translates to an openflow \(dqlearn\(dq action that inserts two new flows in tables 76 and 77\[char46] +.RS +.IP \(bu +Match on the the 5-tuple and the expected next-hop mac address in table 76: \fBnw_src=ip0\fR, \fBnw_dst=ip1\fR, \fBip_proto\fR,\fBtp_src=l4_port0\fR, \fBtp_dst=l4_port1\fR,\fBdl_src=ethaddr\fR and set \fBreg9[5]\fR\[char46] +.IP \(bu +Match on the 5-tuple in table 77: \fBnw_src=ip1\fR, \fBnw_dst=ip0\fR, \fBip_proto\fR, \fBtp_src=l4_port1\fR, \fBtp_dst=l4_port0\fR and set \fBreg9[5]\fR to 1 +.RE +.IP +This action is applied if the packet arrives via ECMP route or if it is routed via an ECMP route +.TP +\fB\fIR\fB = check_ecmp_nh_mac();\fR +This action checks if the packet under consideration matches any flow in table 76\[char46] If it is so, then the 1-bit destination register \fIR\fR is set to 1\[char46] +.TP +\fB\fIR\fB = check_ecmp_nh();\fR +This action checks if the packet under consideration matches the any flow in table 77\[char46] If it is so, then the 1-bit destination register \fIR\fR is set to 1\[char46] +.TP +\fB +commit_lb_aff(\fIvip\fB, \fIbackend\fB, +\fIproto\fB, \fItimeout\fB); +\fR +\fBParameters\fR: load-balancer virtual ip:port \fIvip\fR, load-balancer backend ip:port \fIbackend\fR, load-balancer protocol \fIproto\fR, affinity timeout \fItimeout\fR\[char46] +.IP +This action translates to an openflow \(dqlearn\(dq action that inserts a new flow in table 78\[char46] +.RS +.IP \(bu +Match on the 4-tuple in table 78: \fBnw_src=ip client\fR, \fBnw_dst=vip ip\fR, \fBip_proto\fR, \fBtp_dst=vip port\fR and set \fBreg9[6]\fR to 1, \fBreg4\fR and \fBreg8\fR to backend ip and port respectively\[char46] For IPv6 register \fBxxreg1\fR is used to store the backend ip\[char46] +.RE +.IP +This action is applied for new connections received by a specific load-balacer with affinity timeout configured\[char46] +.TP +\fB\fIR\fB = chk_lb_aff();\fR +This action checks if the packet under consideration matches any flow in table 78\[char46] If it is so, then the 1-bit destination register \fIR\fR is set to 1\[char46] +.TP +\fBsample(probability=\fIpackets\fB, \[char46]\[char46]\[char46])\fR +This action causes the matched traffic to be sampled using IPFIX protocol\[char46] More information about how per-flow IPFIX sampling works in OVS can be found in \fBovs\-actions\fR(7) and \fBovs\-vswitchd\[char46]conf\[char46]db\fR(5)\[char46] +.IP +In order to reliably identify each sampled packet when it is received by the IPFIX collector, this action sets the content of the \fBObservationDomainID\fR and \fBObservationPointID\fR IPFIX fields (see argument description below)\[char46] +.IP +The following key-value arguments are supported: +.RS +.TP +\fBprobability=\fR\fIpackets\fR +The number of sampled packets out of 65535\[char46] It must be greater or equal to 1\[char46] +.TP +\fBcollector_set=\fR\fIid\fR +The unsigned 32-bit integer identifier of the sample collector to send sampled packets to\[char46] It must match the value configured in the \fBFlow_Sample_Collector_Set\fR Table in OVS\[char46] Defaults to 0\[char46] +.TP +\fBobs_domain=\fR\fIid\fR +An unsigned 8-bit integer that identifies the sampling application\[char46] It will be placed in the 8 most significant bits of the \fBObservationDomainID\fR field of IPFIX samples\[char46] The 24 less significant bits will be automatically filled in with the datapath key\[char46] Defaults to 0\[char46] +.TP +\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 +.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] +.RS +.TP +in_out_port +In the logical flow\(cqs \(dqmatch\(dq column, if a logical port P is compared with \(dqinport\(dq and the logical flow is on a logical switch ingress pipeline, or if P is compared with \(dqoutport\(dq 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\[char46] If there are multiple logical ports meeting this criteria, one of them can be added\[char46] ovn-controller uses this information to skip parsing flows that are not needed on the chassis\[char46] Failing to add the tag will affect efficiency, while adding wrong value will affect correctness\[char46] +.RE +.IP "\fBcontroller_meter\fR: optional string" +The name of the meter in table \fBMeter\fR to be used for all packets that the logical flow might send to \fBovn\-controller\fR\[char46] +.IP "\fBexternal_ids : stage-name\fR: optional string" +Human-readable name for this flow\(cqs stage in the pipeline\[char46] +.IP "\fBexternal_ids : stage-hint\fR: optional string, containing an uuid" +UUID of a \fBOVN_Northbound\fR record that caused this logical flow to be created\[char46] Currently used only for attribute of logical flows to northbound \fBACL\fR records\[char46] +.IP "\fBexternal_ids : source\fR: optional string" +Source file and line number of the code that added this flow to the pipeline\[char46] +.ST "Common Columns:" +.PP +The overall purpose of these columns is described under \fBCommon +Columns\fR at the beginning of this document\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +.bp +.SH "Logical_DP_Group TABLE" +.PP +.PP +.PP +Each row in this table represents a group of logical datapaths referenced by the \fBlogical_dp_group\fR column in the \fBLogical_Flow\fR table\[char46] +.SS "Summary: +.TQ 3.00in +\fBdatapaths\fR +set of weak reference to \fBDatapath_Binding\fRs +.SS "Details: +.IP "\fBdatapaths\fR: set of weak reference to \fBDatapath_Binding\fRs" +List of \fBDatapath_Binding\fR entries\[char46] +.bp +.SH "Multicast_Group TABLE" +.PP +.PP +.PP +The rows in this table define multicast groups of logical ports\[char46] Multicast groups allow a single packet transmitted over a tunnel to a hypervisor to be delivered to multiple VMs on that hypervisor, which uses bandwidth more efficiently\[char46] +.PP +.PP +Each row in this table defines a logical multicast group numbered \fBtunnel_key\fR within \fBdatapath\fR, whose logical ports are listed in the \fBports\fR column\[char46] +.SS "Summary: +.TQ 3.00in +\fBdatapath\fR +\fBDatapath_Binding\fR +.TQ 3.00in +\fBtunnel_key\fR +integer, in range 32,768 to 65,535 +.TQ 3.00in +\fBname\fR +string +.TQ 3.00in +\fBports\fR +set of weak reference to \fBPort_Binding\fRs +.SS "Details: +.IP "\fBdatapath\fR: \fBDatapath_Binding\fR" +The logical datapath in which the multicast group resides\[char46] +.IP "\fBtunnel_key\fR: integer, in range 32,768 to 65,535" +The value used to designate this logical egress port in tunnel encapsulations\[char46] An index forces the key to be unique within the \fBdatapath\fR\[char46] The unusual range ensures that multicast group IDs do not overlap with logical port IDs\[char46] +.IP "\fBname\fR: string" +The logical multicast group\(cqs name\[char46] An index forces the name to be unique within the \fBdatapath\fR\[char46] Logical flows in the ingress pipeline may output to the group just as for individual logical ports, by assigning the group\(cqs name to \fBoutport\fR and executing an \fBoutput\fR action\[char46] +.IP +Multicast group names and logical port names share a single namespace and thus should not overlap (but the database schema cannot enforce this)\[char46] To try to avoid conflicts, \fBovn\-northd\fR uses names that begin with \fB_MC_\fR\[char46] +.IP "\fBports\fR: set of weak reference to \fBPort_Binding\fRs" +The logical ports included in the multicast group\[char46] All of these ports must be in the \fBdatapath\fR logical datapath (but the database schema cannot enforce this)\[char46] +.bp +.SH "Mirror TABLE" +.PP +.PP +.PP +Each row in this table represents a mirror that can be used for port mirroring\[char46] These mirrors are referenced by the \fBmirror_rules\fR column in the \fBPort_Binding\fR table\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBfilter\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, one of \fBerspan\fR, \fBgre\fR, or \fBlocal\fR +.TQ 3.00in +\fBindex\fR +integer +.TQ 3.00in +\fBexternal_ids\fR +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, 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] 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] 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 +.SH "Meter TABLE" +.PP +.PP +.PP +Each row in this table represents a meter that can be used for QoS or rate-limiting\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBunit\fR +string, either \fBkbps\fR or \fBpktps\fR +.TQ 3.00in +\fBbands\fR +set of 1 or more \fBMeter_Band\fRs +.SS "Details: +.IP "\fBname\fR: string (must be unique within table)" +A name for this meter\[char46] +.IP +Names that begin with \(dq__\(dq (two underscores) are reserved for OVN internal use and should not be added manually\[char46] +.IP "\fBunit\fR: string, either \fBkbps\fR or \fBpktps\fR" +The unit for \fBrate\fR and \fBburst_rate\fR parameters in the \fBbands\fR entry\[char46] \fBkbps\fR specifies kilobits per second, and \fBpktps\fR specifies packets per second\[char46] +.IP "\fBbands\fR: set of 1 or more \fBMeter_Band\fRs" +The bands associated with this meter\[char46] Each band specifies a rate above which the band is to take the action \fBaction\fR\[char46] If multiple bands\(cq rates are exceeded, then the band with the highest rate among the exceeded bands is selected\[char46] +.bp +.SH "Meter_Band TABLE" +.PP +.PP +.PP +Each row in this table represents a meter band which specifies the rate above which the configured action should be applied\[char46] These bands are referenced by the \fBbands\fR column in the \fBMeter\fR table\[char46] +.SS "Summary: +.TQ 3.00in +\fBaction\fR +string, must be \fBdrop\fR +.TQ 3.00in +\fBrate\fR +integer, in range 1 to 4,294,967,295 +.TQ 3.00in +\fBburst_size\fR +integer, in range 0 to 4,294,967,295 +.SS "Details: +.IP "\fBaction\fR: string, must be \fBdrop\fR" +The action to execute when this band matches\[char46] The only supported action is \fBdrop\fR\[char46] +.IP "\fBrate\fR: 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 \fBMeter\fR entry\(cqs \fBunit\fR column specified \fBkbps\fR or \fBpktps\fR\[char46] +.IP "\fBburst_size\fR: integer, in range 0 to 4,294,967,295" +The maximum burst allowed for the band in kilobits or packets, depending on whether \fBkbps\fR or \fBpktps\fR was selected in the parent \fBMeter\fR entry\(cqs \fBunit\fR column\[char46] If the size is zero, the switch is free to select some reasonable value depending on its configuration\[char46] +.bp +.SH "Datapath_Binding TABLE" +.PP +.PP +.PP +Each row in this table represents a logical datapath, which implements a logical pipeline among the ports in the \fBPort_Binding\fR table associated with it\[char46] In practice, the pipeline in a given logical datapath implements either a logical switch or a logical router\[char46] +.PP +.PP +The main purpose of a row in this table is provide a physical binding for a logical datapath\[char46] A logical datapath does not have a physical location, so its physical binding information is limited: just \fBtunnel_key\fR\[char46] The rest of the data in this table does not affect packet forwarding\[char46] +.SS "Summary: +.TQ 3.00in +\fBtunnel_key\fR +integer, in range 1 to 16,777,215 (must be unique within table) +.TQ 3.00in +\fBload_balancers\fR +set of uuids +.TQ .25in +\fIOVN_Northbound Relationship:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids : logical-switch\fR +optional string, containing an uuid +.TQ 2.75in +\fBexternal_ids : logical-router\fR +optional string, containing an uuid +.TQ 2.75in +\fBexternal_ids : interconn-ts\fR +optional string +.TQ .25in +\fINaming:\fR +.RS .25in +.TQ 2.50in +\fBexternal_ids : name\fR +optional string +.TQ 2.50in +\fBexternal_ids : name2\fR +optional string +.RE +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBtunnel_key\fR: integer, in range 1 to 16,777,215 (must be unique within table)" +The tunnel key value to which the logical datapath is bound\[char46] The \fBTunnel Encapsulation\fR section in \fBovn\-architecture\fR(7) describes how tunnel keys are constructed for each supported encapsulation\[char46] +.IP "\fBload_balancers\fR: set of uuids" +Not used anymore; kept for backwards compatibility of the schema\[char46] +.ST "OVN_Northbound Relationship:" +.PP +.PP +.PP +Each row in \fBDatapath_Binding\fR is associated with some logical datapath\[char46] \fBovn\-northd\fR uses these keys to track the association of a logical datapath with concepts in the \fBOVN_Northbound\fR database\[char46] +.IP "\fBexternal_ids : logical-switch\fR: optional string, containing an uuid" +For a logical datapath that represents a logical switch, \fBovn\-northd\fR stores in this key the UUID of the corresponding \fBLogical_Switch\fR row in the \fBOVN_Northbound\fR database\[char46] +.IP "\fBexternal_ids : logical-router\fR: optional string, containing an uuid" +For a logical datapath that represents a logical router, \fBovn\-northd\fR stores in this key the UUID of the corresponding \fBLogical_Router\fR row in the \fBOVN_Northbound\fR database\[char46] +.IP "\fBexternal_ids : interconn-ts\fR: optional string" +For a logical datapath that represents a logical switch that represents a transit switch for interconnection, \fBovn\-northd\fR stores in this key the value of the same \fBinterconn\-ts\fR key of the \fBexternal_ids\fR column of the corresponding \fBLogical_Switch\fR row in the \fBOVN_Northbound\fR database\[char46] +.ST "Naming:" +.PP +.PP +.PP +\fBovn\-northd\fR copies these from the name fields in the \fBOVN_Northbound\fR database, either from \fBname\fR and \fBexternal_ids:neutron:router_name\fR in the \fBLogical_Router\fR table or from \fBname\fR and \fBexternal_ids:neutron:network_name\fR in the \fBLogical_Switch\fR table\[char46] +.IP "\fBexternal_ids : name\fR: optional string" +A name for the logical datapath\[char46] +.IP "\fBexternal_ids : name2\fR: optional string" +Another name for the logical datapath\[char46] +.ST "Common Columns:" +.PP +The overall purpose of these columns is described under \fBCommon +Columns\fR at the beginning of this document\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +.bp +.SH "Port_Binding TABLE" +.PP +.PP +.PP +Each row in this table binds a logical port to a realization\[char46] For most logical ports, this means binding to some physical location, for example by binding a logical port to a VIF that belongs to a VM running on a particular hypervisor\[char46] 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\[char46] +.PP +.PP +For every \fBLogical_Switch_Port\fR record in \fBOVN_Northbound\fR database, \fBovn\-northd\fR creates a record in this table\[char46] \fBovn\-northd\fR populates and maintains every column except the \fBchassis\fR and \fBvirtual_parent\fR columns, which it leaves empty in new records\[char46] +.PP +.PP +\fBovn\-controller\fR/\fBovn\-controller\-vtep\fR populates the \fBchassis\fR column for the records that identify the logical ports that are located on its hypervisor/gateway, which \fBovn\-controller\fR/\fBovn\-controller\-vtep\fR in turn finds out by monitoring the local hypervisor\(cqs Open_vSwitch database, which identifies logical ports via the conventions described in \fBIntegrationGuide\[char46]rst\fR\[char46] (The exceptions are for \fBPort_Binding\fR records with \fBtype\fR of \fBl3gateway\fR, whose locations are identified by \fBovn\-northd\fR via the \fBoptions:l3gateway\-chassis\fR column in this table\[char46] \fBovn\-controller\fR is still responsible to populate the \fBchassis\fR column\[char46]) +.PP +.PP +\fBovn\-controller\fR also populates the \fBvirtual_parent\fR column of records whose \fBtype\fR is \fBvirtual\fR\[char46] +.PP +.PP +When a chassis shuts down gracefully, it should clean up the \fBchassis\fR column that it previously had populated\[char46] (This is not critical because resources hosted on the chassis are equally unreachable regardless of whether their rows are present\[char46]) To handle the case where a VM is shut down abruptly on one chassis, then brought up again on a different one, \fBovn\-controller\fR/\fBovn\-controller\-vtep\fR must overwrite the \fBchassis\fR column with new information\[char46] +.SS "Summary: +.TQ .25in +\fICore Features:\fR +.RS .25in +.TQ 2.75in +\fBdatapath\fR +\fBDatapath_Binding\fR +.TQ 2.75in +\fBlogical_port\fR +string (must be unique within table) +.TQ 2.75in +\fBencap\fR +optional weak reference to \fBEncap\fR +.TQ 2.75in +\fBadditional_encap\fR +set of weak reference to \fBEncap\fRs +.TQ 2.75in +\fBchassis\fR +optional weak reference to \fBChassis\fR +.TQ 2.75in +\fBadditional_chassis\fR +set of weak reference to \fBChassis\fR +.TQ 2.75in +\fBgateway_chassis\fR +set of \fBGateway_Chassis\fRes +.TQ 2.75in +\fBha_chassis_group\fR +optional \fBHA_Chassis_Group\fR +.TQ 2.75in +\fBup\fR +optional boolean +.TQ 2.75in +\fBtunnel_key\fR +integer, in range 1 to 32,767 +.TQ 2.75in +\fBmac\fR +set of strings +.TQ 2.75in +\fBport_security\fR +set of strings +.TQ 2.75in +\fBtype\fR +string +.TQ 2.75in +\fBrequested_chassis\fR +optional weak reference to \fBChassis\fR +.TQ 2.75in +\fBrequested_additional_chassis\fR +set of weak reference to \fBChassis\fR +.RE +.TQ 3.00in +\fBmirror_rules\fR +set of weak reference to \fBMirror\fRs +.TQ .25in +\fIPatch Options:\fR +.RS .25in +.TQ 2.75in +\fBoptions : peer\fR +optional string +.TQ 2.75in +\fBnat_addresses\fR +set of strings +.RE +.TQ .25in +\fIL3 Gateway Options:\fR +.RS .25in +.TQ 2.75in +\fBoptions : peer\fR +optional string +.TQ 2.75in +\fBoptions : l3gateway-chassis\fR +optional string +.TQ 2.75in +\fBnat_addresses\fR +set of strings +.RE +.TQ .25in +\fILocalnet Options:\fR +.RS .25in +.TQ 2.75in +\fBoptions : network_name\fR +optional string +.TQ 2.75in +\fBtag\fR +optional integer, in range 1 to 4,095 +.RE +.TQ .25in +\fIL2 Gateway Options:\fR +.RS .25in +.TQ 2.75in +\fBoptions : network_name\fR +optional string +.TQ 2.75in +\fBoptions : l2gateway-chassis\fR +optional string +.TQ 2.75in +\fBtag\fR +optional integer, in range 1 to 4,095 +.RE +.TQ .25in +\fIVTEP Options:\fR +.RS .25in +.TQ 2.75in +\fBoptions : vtep-physical-switch\fR +optional string +.TQ 2.75in +\fBoptions : vtep-logical-switch\fR +optional string +.RE +.TQ .25in +\fIVMI (or VIF) Options:\fR +.RS .25in +.TQ 2.75in +\fBoptions : requested-chassis\fR +optional string +.TQ 2.75in +\fBoptions : activation-strategy\fR +optional string +.TQ 2.75in +\fBoptions : additional-chassis-activated\fR +optional string +.TQ 2.75in +\fBoptions : iface-id-ver\fR +optional string +.TQ 2.75in +\fBoptions : qos_min_rate\fR +optional string +.TQ 2.75in +\fBoptions : qos_max_rate\fR +optional string +.TQ 2.75in +\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 +.TQ .25in +\fIDistributed Gateway Port Options:\fR +.RS .25in +.TQ 2.75in +\fBoptions : chassis-redirect-port\fR +optional string +.RE +.TQ .25in +\fIChassis Redirect Options:\fR +.RS .25in +.TQ 2.75in +\fBoptions : distributed-port\fR +optional string +.TQ 2.75in +\fBoptions : redirect-type\fR +optional string +.TQ 2.75in +\fBoptions : always-redirect\fR +optional string +.RE +.TQ .25in +\fINested Containers:\fR +.RS .25in +.TQ 2.75in +\fBparent_port\fR +optional string +.TQ 2.75in +\fBtag\fR +optional integer, in range 1 to 4,095 +.RE +.TQ .25in +\fIVirtual ports:\fR +.RS .25in +.TQ 2.75in +\fBvirtual_parent\fR +optional string +.RE +.TQ .25in +\fINaming:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids : name\fR +optional string +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.ST "Core Features:" +.PP +.IP "\fBdatapath\fR: \fBDatapath_Binding\fR" +The logical datapath to which the logical port belongs\[char46] +.IP "\fBlogical_port\fR: string (must be unique within table)" +A logical port\[char46] For a logical switch port, this is taken from \fBname\fR in the OVN_Northbound database\(cqs \fBLogical_Switch_Port\fR table\[char46] For a logical router port, this is taken from \fBname\fR in the OVN_Northbound database\(cqs \fBLogical_Router_port\fR table\[char46] (This means that logical switch ports and router port names must not share names in an OVN deployment\[char46]) OVN does not prescribe a particular format for the logical port ID\[char46] +.IP "\fBencap\fR: optional weak reference to \fBEncap\fR" +Points to preferred encapsulation configuration to transmit logical dataplane packets to this chassis\[char46] The entry is reference to a \fBEncap\fR record\[char46] +.IP "\fBadditional_encap\fR: set of weak reference to \fBEncap\fRs" +Points to preferred encapsulation configuration to transmit logical dataplane packets to this additional chassis\[char46] The entry is reference to a \fBEncap\fR record\[char46] See also \fBadditional_chassis\fR\[char46] +.IP "\fBchassis\fR: optional weak reference to \fBChassis\fR" +The meaning of this column depends on the value of the \fBtype\fR column\[char46] This is the meaning for each \fBtype\fR +.RS +.TP +(empty string) +The physical location of the logical port\[char46] To successfully identify a chassis, this column must be a \fBChassis\fR record\[char46] This is populated by \fBovn\-controller\fR\[char46] +.TP +vtep +The physical location of the hardware_vtep gateway\[char46] To successfully identify a chassis, this column must be a \fBChassis\fR record\[char46] This is populated by \fBovn\-controller\-vtep\fR\[char46] +.TP +localnet +Always empty\[char46] A localnet port is realized on every chassis that has connectivity to the corresponding physical network\[char46] +.TP +localport +Always empty\[char46] A localport port is present on every chassis\[char46] +.TP +l3gateway +The physical location of the L3 gateway\[char46] To successfully identify a chassis, this column must be a \fBChassis\fR record\[char46] This is populated by \fBovn\-controller\fR based on the value of the \fBoptions:l3gateway\-chassis\fR column in this table\[char46] +.TP +l2gateway +The physical location of this L2 gateway\[char46] To successfully identify a chassis, this column must be a \fBChassis\fR record\[char46] This is populated by \fBovn\-controller\fR based on the value of the \fBoptions:l2gateway\-chassis\fR column in this table\[char46] +.RE +.IP "\fBadditional_chassis\fR: set of weak reference to \fBChassis\fR" +The meaning of this column is the same as for the \fBchassis\fR\[char46] The column is used to track an additional physical location of the logical port\[char46] Used with regular (empty \fBtype\fR) port bindings\[char46] +.IP "\fBgateway_chassis\fR: set of \fBGateway_Chassis\fRes" +A list of \fBGateway_Chassis\fR\[char46] +.IP +This should only be populated for ports with \fBtype\fR set to \fBchassisredirect\fR\[char46] This column defines the list of chassis used as gateways where traffic will be redirected through\[char46] +.IP "\fBha_chassis_group\fR: optional \fBHA_Chassis_Group\fR" +This should only be populated for ports with \fBtype\fR set to \fBchassisredirect\fR\[char46] This column defines the HA chassis group with a list of HA chassis used as gateways where traffic will be redirected through\[char46] +.IP "\fBup\fR: optional boolean" +This is set to \fBtrue\fR whenever all OVS flows required by this Port_Binding have been installed\[char46] This is populated by \fBovn\-controller\fR\[char46] +.IP "\fBtunnel_key\fR: integer, in range 1 to 32,767" +A number that represents the logical port in the key (e\[char46]g\[char46] STT key or Geneve TLV) field carried within tunnel protocol packets\[char46] +.IP +The tunnel ID must be unique within the scope of a logical datapath\[char46] +.IP "\fBmac\fR: set of strings" +This column is a misnomer as it may contain MAC addresses and IP addresses\[char46] It is copied from the \fBaddresses\fR column in the \fBLogical_Switch_Port\fR table in the Northbound database\[char46] It follows the same format as that column\[char46] +.IP "\fBport_security\fR: set of strings" +This column controls the addresses from which the host attached to the logical port (``the host\(cq\(cq) is allowed to send packets and to which it is allowed to receive packets\[char46] If this column is empty, all addresses are permitted\[char46] +.IP +It is copied from the \fBport_security\fR column in the \fBLogical_Switch_Port\fR table in the Northbound database\[char46] It follows the same format as that column\[char46] +.IP "\fBtype\fR: string" +A type for this logical port\[char46] Logical ports can be used to model other types of connectivity into an OVN logical switch\[char46] The following types are defined: +.RS +.TP +(empty string) +VM (or VIF) interface\[char46] +.TP +\fBpatch\fR +One of a pair of logical ports that act as if connected by a patch cable\[char46] Useful for connecting two logical datapaths, e\[char46]g\[char46] to connect a logical router to a logical switch or to another logical router\[char46] +.TP +\fBl3gateway\fR +One of a pair of logical ports that act as if connected by a patch cable across multiple chassis\[char46] Useful for connecting a logical switch with a Gateway router (which is only resident on a particular chassis)\[char46] +.TP +\fBlocalnet\fR +A connection to a locally accessible network from \fBovn\-controller\fR instances that have a corresponding bridge mapping\[char46] A logical switch can have multiple \fBlocalnet\fR ports attached\[char46] This type is used to model direct connectivity to existing networks\[char46] In this case, each chassis should have a mapping for one of the physical networks only\[char46] Note: nothing said above implies that a chassis cannot be plugged to multiple physical networks as long as they belong to different switches\[char46] +.TP +\fBlocalport\fR +A connection to a local VIF\[char46] Traffic that arrives on a \fBlocalport\fR is never forwarded over a tunnel to another chassis\[char46] These ports are present on every chassis and have the same address in all of them\[char46] This is used to model connectivity to local services that run on every hypervisor\[char46] +.TP +\fBl2gateway\fR +An L2 connection to a physical network\[char46] The chassis this \fBPort_Binding\fR is bound to will serve as an L2 gateway to the network named by \fBoptions\fR:\fBnetwork_name\fR\[char46] +.TP +\fBvtep\fR +A port to a logical switch on a VTEP gateway chassis\[char46] In order to get this port correctly recognized by the OVN controller, the \fBoptions\fR:\fBvtep\-physical\-switch\fR and \fBoptions\fR:\fBvtep\-logical\-switch\fR must also be defined\[char46] +.TP +\fBchassisredirect\fR +A logical port that represents a particular instance, bound to a specific chassis, of an otherwise distributed parent port (e\[char46]g\[char46] of type \fBpatch\fR)\[char46] A \fBchassisredirect\fR port should never be used as an \fBinport\fR\[char46] When an ingress pipeline sets the \fBoutport\fR, it may set the value to a logical port of type \fBchassisredirect\fR\[char46] This will cause the packet to be directed to a specific chassis to carry out the egress pipeline\[char46] At the beginning of the egress pipeline, the \fBoutport\fR will be reset to the value of the distributed port\[char46] +.TP +\fBvirtual\fR +Represents a logical port with an \fBvirtual ip\fR\[char46] This \fBvirtual ip\fR can be configured on a logical port (which is referred as virtual parent)\[char46] +.RE +.IP "\fBrequested_chassis\fR: optional weak reference to \fBChassis\fR" +This column exists so that the ovn-controller can effectively monitor all \fBPort_Binding\fR records destined for it, and is a supplement to the \fBoptions:requested-chassis\fR option\[char46] 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\[char46] This column must be a \fBChassis\fR record\[char46] This is populated by \fBovn\-northd\fR when the \fBoptions:requested-chassis\fR is defined and contains a string matching the name or hostname of an existing chassis\[char46] See also \fBrequested_additional_chassis\fR\[char46] +.IP "\fBrequested_additional_chassis\fR: set of weak reference to \fBChassis\fR" +This column exists so that the ovn-controller can effectively monitor all \fBPort_Binding\fR records destined for it, and is a supplement to the \fBoptions:requested-chassis\fR option when multiple chassis are listed\[char46] This column must be a list of \fBChassis\fR records\[char46] This is populated by \fBovn\-northd\fR when the \fBoptions:requested-chassis\fR is defined as a list of chassis names or hostnames\[char46] See also \fBrequested_chassis\fR\[char46] +.IP "\fBmirror_rules\fR: set of weak reference to \fBMirror\fRs" +Mirror rules that apply to the port binding\[char46] Please see the \fBMirror\fR table\[char46] +.ST "Patch Options:" +.PP +.PP +.PP +These options apply to logical ports with \fBtype\fR of \fBpatch\fR\[char46] +.IP "\fBoptions : peer\fR: optional string" +The \fBlogical_port\fR in the \fBPort_Binding\fR record for the other side of the patch\[char46] The named \fBlogical_port\fR must specify this \fBlogical_port\fR in its own \fBpeer\fR option\[char46] That is, the two patch logical ports must have reversed \fBlogical_port\fR and \fBpeer\fR values\[char46] +.IP "\fBnat_addresses\fR: set of strings" +MAC address followed by a list of SNAT and DNAT external IP addresses, followed by \fBis_chassis_resident(\(dq\fIlport\fB\(dq)\fR, where \fIlport\fR is the name of a logical port on the same chassis where the corresponding NAT rules are applied\[char46] This is used to send gratuitous ARPs for SNAT and DNAT external IP addresses via \fBlocalnet\fR, from the chassis where \fIlport\fR resides\[char46] Example: \fB80:fa:5b:06:72:b7 158\[char46]36\[char46]44\[char46]22 +158\[char46]36\[char46]44\[char46]24 is_chassis_resident(\(dqfoo1\(dq)\fR\[char46] This would result in generation of gratuitous ARPs for IP addresses 158\[char46]36\[char46]44\[char46]22 and 158\[char46]36\[char46]44\[char46]24 with a MAC address of 80:fa:5b:06:72:b7 from the chassis where the logical port \(dqfoo1\(dq resides\[char46] +.ST "L3 Gateway Options:" +.PP +.PP +.PP +These options apply to logical ports with \fBtype\fR of \fBl3gateway\fR\[char46] +.IP "\fBoptions : peer\fR: optional string" +The \fBlogical_port\fR in the \fBPort_Binding\fR record for the other side of the \(cql3gateway\(cq port\[char46] The named \fBlogical_port\fR must specify this \fBlogical_port\fR in its own \fBpeer\fR option\[char46] That is, the two \(cql3gateway\(cq logical ports must have reversed \fBlogical_port\fR and \fBpeer\fR values\[char46] +.IP "\fBoptions : l3gateway-chassis\fR: optional string" +The \fBchassis\fR in which the port resides\[char46] +.IP "\fBnat_addresses\fR: set of strings" +MAC address of the \fBl3gateway\fR port followed by a list of SNAT and DNAT external IP addresses\[char46] This is used to send gratuitous ARPs for SNAT and DNAT external IP addresses via \fBlocalnet\fR\[char46] Example: \fB80:fa:5b:06:72:b7 158\[char46]36\[char46]44\[char46]22 158\[char46]36\[char46]44\[char46]24\fR\[char46] This would result in generation of gratuitous ARPs for IP addresses 158\[char46]36\[char46]44\[char46]22 and 158\[char46]36\[char46]44\[char46]24 with a MAC address of 80:fa:5b:06:72:b7\[char46] This is used in OVS version 2\[char46]8 and later versions\[char46] +.ST "Localnet Options:" +.PP +.PP +.PP +These options apply to logical ports with \fBtype\fR of \fBlocalnet\fR\[char46] +.IP "\fBoptions : network_name\fR: optional string" +Required\[char46] \fBovn\-controller\fR uses the configuration entry \fBovn\-bridge\-mappings\fR to determine how to connect to this network\[char46] \fBovn\-bridge\-mappings\fR is a list of network names mapped to a local OVS bridge that provides access to that network\[char46] An example of configuring \fBovn\-bridge\-mappings\fR would be: .IP +.nf +\fB$ ovs\-vsctl set open \[char46] external\-ids:ovn\-bridge\-mappings=physnet1:br\-eth0,physnet2:br\-eth1\fR +.fi +.IP +When a logical switch has a \fBlocalnet\fR port attached, every chassis that may have a local vif attached to that logical switch must have a bridge mapping configured to reach that \fBlocalnet\fR\[char46] Traffic that arrives on a \fBlocalnet\fR port is never forwarded over a tunnel to another chassis\[char46] If there are multiple \fBlocalnet\fR ports in a logical switch, each chassis should only have a single bridge mapping for one of the physical networks\[char46] Note: In case of multiple \fBlocalnet\fR 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\[char46] +.IP "\fBtag\fR: 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\[char46] The VLAN ID is used to match incoming traffic and is also added to outgoing traffic\[char46] +.ST "L2 Gateway Options:" +.PP +.PP +.PP +These options apply to logical ports with \fBtype\fR of \fBl2gateway\fR\[char46] +.IP "\fBoptions : network_name\fR: optional string" +Required\[char46] \fBovn\-controller\fR uses the configuration entry \fBovn\-bridge\-mappings\fR to determine how to connect to this network\[char46] \fBovn\-bridge\-mappings\fR is a list of network names mapped to a local OVS bridge that provides access to that network\[char46] An example of configuring \fBovn\-bridge\-mappings\fR would be: .IP +.nf +\fB$ ovs\-vsctl set open \[char46] external\-ids:ovn\-bridge\-mappings=physnet1:br\-eth0,physnet2:br\-eth1\fR +.fi +.IP +When a logical switch has a \fBl2gateway\fR port attached, the chassis that the \fBl2gateway\fR port is bound to must have a bridge mapping configured to reach the network identified by \fBnetwork_name\fR\[char46] +.IP "\fBoptions : l2gateway-chassis\fR: optional string" +Required\[char46] The \fBchassis\fR in which the port resides\[char46] +.IP "\fBtag\fR: optional integer, in range 1 to 4,095" +If set, indicates that the gateway is connected to a specific VLAN on the physical network\[char46] The VLAN ID is used to match incoming traffic and is also added to outgoing traffic\[char46] +.ST "VTEP Options:" +.PP +.PP +.PP +These options apply to logical ports with \fBtype\fR of \fBvtep\fR\[char46] +.IP "\fBoptions : vtep-physical-switch\fR: optional string" +Required\[char46] The name of the VTEP gateway\[char46] +.IP "\fBoptions : vtep-logical-switch\fR: optional string" +Required\[char46] A logical switch name connected by the VTEP gateway\[char46] Must be set when \fBtype\fR is \fBvtep\fR\[char46] +.ST "VMI (or VIF) Options:" +.PP +.PP +.PP +These options apply to logical ports with \fBtype\fR having (empty string) +.IP "\fBoptions : requested-chassis\fR: optional string" +If set, identifies a specific chassis (by name or hostname) that is allowed to bind this port\[char46] Using this option will prevent thrashing between two chassis trying to bind the same port during a live migration\[char46] It can also prevent similar thrashing due to a mis-configuration, if a port is accidentally created on more than one chassis\[char46] +.IP +If set to a comma separated list, the first entry identifies the main chassis and the rest are one or more additional chassis that are allowed to bind the same port\[char46] +.IP +When multiple chassis are set for the port, and the logical switch is connected to an external network through a \fBlocalnet\fR port, tunneling is enforced for the port to guarantee delivery of packets directed to the port to all its locations\[char46] This has MTU implications because the network used for tunneling must have MTU larger than \fBlocalnet\fR for stable connectivity\[char46] +.IP "\fBoptions : activation-strategy\fR: optional string" +If used with multiple chassis set in \fBrequested-chassis\fR, specifies an activation strategy for all additional chassis\[char46] By default, no activation strategy is used, meaning additional port locations are immediately available for use\[char46] When set to \(dqrarp\(dq, the port is blocked for ingress and egress communication until a RARP packet is sent from a new location\[char46] The \(dqrarp\(dq strategy is useful in live migration scenarios for virtual machines\[char46] +.IP "\fBoptions : additional-chassis-activated\fR: optional string" +When \fBactivation-strategy\fR is set, this option indicates that the port was activated using the strategy specified\[char46] +.IP "\fBoptions : iface-id-ver\fR: optional string" +If set, this port will be bound by \fBovn\-controller\fR only if this same key and value is configured in the \fBexternal_ids\fR column in the Open_vSwitch database\(cqs \fBInterface\fR table\[char46] +.IP "\fBoptions : qos_min_rate\fR: optional string" +If set, indicates the minimum guaranteed rate available for data sent from this interface, in bit/s\[char46] +.IP "\fBoptions : qos_max_rate\fR: optional string" +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] +.ST "Distributed Gateway Port Options:" +.PP +.PP +.PP +These options apply to the distributed parent ports of logical ports with \fBtype\fR of \fBchasssisredirect\fR\[char46] +.IP "\fBoptions : chassis-redirect-port\fR: optional string" +The name of the chassis redirect port derived from this port if this port is a distributed parent of a chassis redirect port\[char46] +.ST "Chassis Redirect Options:" +.PP +.PP +.PP +These options apply to logical ports with \fBtype\fR of \fBchassisredirect\fR\[char46] +.IP "\fBoptions : distributed-port\fR: optional string" +The name of the distributed port for which this \fBchassisredirect\fR port represents a particular instance\[char46] +.IP "\fBoptions : redirect-type\fR: optional string" +The value is copied from the column \fBoptions\fR in the OVN_Northbound database\(cqs \fBLogical_Router_Port\fR table for the distributed parent of this port\[char46] +.IP "\fBoptions : always-redirect\fR: optional string" +A boolean option that is set to true if the distributed parent of this chassis redirect port does not need distributed processing\[char46] +.ST "Nested Containers:" +.PP +.PP +.PP +These columns support containers nested within a VM\[char46] Specifically, they are used when \fBtype\fR is empty and \fBlogical_port\fR identifies the interface of a container spawned inside a VM\[char46] They are empty for containers or VMs that run directly on a hypervisor\[char46] +.IP "\fBparent_port\fR: optional string" +This is taken from \fBparent_name\fR in the OVN_Northbound database\(cqs \fBLogical_Switch_Port\fR table\[char46] +.IP "\fBtag\fR: optional integer, in range 1 to 4,095" +Identifies the VLAN tag in the network traffic associated with that container\(cqs network interface\[char46] +.IP +This column is used for a different purpose when \fBtype\fR is \fBlocalnet\fR (see \fBLocalnet Options\fR, above) or \fBl2gateway\fR (see \fBL2 Gateway Options\fR, above)\[char46] +.ST "Virtual ports:" +.PP +.IP "\fBvirtual_parent\fR: optional string" +This column is set by \fBovn\-controller\fR with one of the value from the \fBoptions:virtual-parents\fR in the OVN_Northbound database\(cqs \fBLogical_Switch_Port\fR table when the OVN action \fBbind_vport\fR is executed\[char46] \fBovn\-controller\fR also sets the \fBchassis\fR column when it executes this action with its chassis id\[char46] +.IP +\fBovn\-controller\fR sets this column only if the \fBtype\fR is \(dqvirtual\(dq\[char46] +.ST "Naming:" +.PP +.IP "\fBexternal_ids : name\fR: optional string" +For a logical switch port, \fBovn\-northd\fR copies this from \fBexternal_ids:neutron:port_name\fR in the \fBLogical_Switch_Port\fR table in the OVN_Northbound database, if it is a nonempty string\[char46] +.IP +For a logical switch port, \fBovn\-northd\fR does not currently set this key\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.IP +The \fBovn\-northd\fR program populates this column with all entries into the \fBexternal_ids\fR column of the \fBLogical_Switch_Port\fR and \fBLogical_Router_Port\fR tables of the \fBOVN_Northbound\fR database\[char46] +.bp +.SH "MAC_Binding TABLE" +.PP +.PP +.PP +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)\[char46] This table is primarily used to discover bindings on physical networks, because IP-to-MAC bindings for virtual machines are usually populated statically into the \fBPort_Binding\fR table\[char46] +.PP +.PP +This table expresses a functional relationship: \fBMAC_Binding\fR(\fBlogical_port\fR, \fBip\fR) = \fBmac\fR\[char46] +.PP +.PP +In outline, the lifetime of a logical router\(cqs MAC binding looks like this: +.RS +.IP 1. .4in +On hypervisor 1, a logical router determines that a packet should be forwarded to IP address \fIA\fR on one of its router ports\[char46] It uses its logical flow table to determine that \fIA\fR lacks a static IP-to-MAC binding and the \fBget_arp\fR action to determine that it lacks a dynamic IP-to-MAC binding\[char46] +.IP 2. .4in +Using an OVN logical \fBarp\fR action, the logical router generates and sends a broadcast ARP request to the router port\[char46] It drops the IP packet\[char46] +.IP 3. .4in +The logical switch attached to the router port delivers the ARP request to all of its ports\[char46] (It might make sense to deliver it only to ports that have no static IP-to-MAC bindings, but this could also be surprising behavior\[char46]) +.IP 4. .4in +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\[char46] It composes an ARP reply and unicasts it to the logical router port\(cqs Ethernet address\[char46] +.IP 5. .4in +The logical switch delivers the ARP reply to the logical router port\[char46] +.IP 6. .4in +The logical router flow table executes a \fBput_arp\fR action\[char46] To record the IP-to-MAC binding, \fBovn\-controller\fR adds a row to the \fBMAC_Binding\fR table\[char46] +.IP 7. .4in +On hypervisor 1, \fBovn\-controller\fR receives the updated \fBMAC_Binding\fR table from the OVN southbound database\[char46] The next packet destined to \fIA\fR through the logical router is sent directly to the bound Ethernet address\[char46] +.RE +.SS "Summary: +.TQ 3.00in +\fBlogical_port\fR +string +.TQ 3.00in +\fBip\fR +string +.TQ 3.00in +\fBmac\fR +string +.TQ 3.00in +\fBtimestamp\fR +integer +.TQ 3.00in +\fBdatapath\fR +\fBDatapath_Binding\fR +.SS "Details: +.IP "\fBlogical_port\fR: string" +The logical port on which the binding was discovered\[char46] +.IP "\fBip\fR: string" +The bound IP address\[char46] +.IP "\fBmac\fR: string" +The Ethernet address to which the IP is bound\[char46] +.IP "\fBtimestamp\fR: integer" +The timestamp in msec when the MAC binding was added or updated\[char46] Records that existed before this column will have 0\[char46] +.IP "\fBdatapath\fR: \fBDatapath_Binding\fR" +The logical datapath to which the logical port belongs\[char46] +.bp +.SH "DHCP_Options TABLE" +.PP +.PP +.PP +Each row in this table stores the DHCP Options supported by native OVN DHCP\[char46] \fBovn\-northd\fR populates this table with the supported DHCP options\[char46] \fBovn\-controller\fR looks up this table to get the DHCP codes of the DHCP options defined in the \(dqput_dhcp_opts\(dq action\[char46] Please refer to the RFC 2132 \fB\(dqhttps://tools\[char46]ietf\[char46]org/html/rfc2132\(dq\fR for the possible list of DHCP options that can be defined here\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string +.TQ 3.00in +\fBcode\fR +integer, in range 0 to 254 +.TQ 3.00in +\fBtype\fR +string, one of \fBbool\fR, \fBdomains\fR, \fBhost_id\fR, \fBipv4\fR, \fBstatic_routes\fR, \fBstr\fR, \fBuint16\fR, \fBuint32\fR, or \fBuint8\fR +.SS "Details: +.IP "\fBname\fR: string" +Name of the DHCP option\[char46] +.IP +Example\[char46] name=\(dqrouter\(dq +.IP "\fBcode\fR: integer, in range 0 to 254" +DHCP option code for the DHCP option as defined in the RFC 2132\[char46] +.IP +Example\[char46] code=3 +.IP "\fBtype\fR: string, one of \fBbool\fR, \fBdomains\fR, \fBhost_id\fR, \fBipv4\fR, \fBstatic_routes\fR, \fBstr\fR, \fBuint16\fR, \fBuint32\fR, or \fBuint8\fR" +Data type of the DHCP option code\[char46] +.RS +.TP +\fBvalue: bool\fR +This indicates that the value of the DHCP option is a bool\[char46] +.IP +Example\[char46] \(dqname=ip_forward_enable\(dq, \(dqcode=19\(dq, \(dqtype=bool\(dq\[char46] +.IP +put_dhcp_opts(\[char46]\[char46]\[char46], ip_forward_enable = 1,\[char46]\[char46]\[char46]) +.TP +\fBvalue: uint8\fR +This indicates that the value of the DHCP option is an unsigned int8 (8 bits) +.IP +Example\[char46] \(dqname=default_ttl\(dq, \(dqcode=23\(dq, \(dqtype=uint8\(dq\[char46] +.IP +put_dhcp_opts(\[char46]\[char46]\[char46], default_ttl = 50,\[char46]\[char46]\[char46]) +.TP +\fBvalue: uint16\fR +This indicates that the value of the DHCP option is an unsigned int16 (16 bits)\[char46] +.IP +Example\[char46] \(dqname=mtu\(dq, \(dqcode=26\(dq, \(dqtype=uint16\(dq\[char46] +.IP +put_dhcp_opts(\[char46]\[char46]\[char46], mtu = 1450,\[char46]\[char46]\[char46]) +.TP +\fBvalue: uint32\fR +This indicates that the value of the DHCP option is an unsigned int32 (32 bits)\[char46] +.IP +Example\[char46] \(dqname=lease_time\(dq, \(dqcode=51\(dq, \(dqtype=uint32\(dq\[char46] +.IP +put_dhcp_opts(\[char46]\[char46]\[char46], lease_time = 86400,\[char46]\[char46]\[char46]) +.TP +\fBvalue: ipv4\fR +This indicates that the value of the DHCP option is an IPv4 address or addresses\[char46] +.IP +Example\[char46] \(dqname=router\(dq, \(dqcode=3\(dq, \(dqtype=ipv4\(dq\[char46] +.IP +put_dhcp_opts(\[char46]\[char46]\[char46], router = 10\[char46]0\[char46]0\[char46]1,\[char46]\[char46]\[char46]) +.IP +Example\[char46] \(dqname=dns_server\(dq, \(dqcode=6\(dq, \(dqtype=ipv4\(dq\[char46] +.IP +put_dhcp_opts(\[char46]\[char46]\[char46], dns_server = {8\[char46]8\[char46]8\[char46]8 7\[char46]7\[char46]7\[char46]7},\[char46]\[char46]\[char46]) +.TP +\fBvalue: static_routes\fR +This indicates that the value of the DHCP option contains a pair of IPv4 route and next hop addresses\[char46] +.IP +Example\[char46] \(dqname=classless_static_route\(dq, \(dqcode=121\(dq, \(dqtype=static_routes\(dq\[char46] +.IP +put_dhcp_opts(\[char46]\[char46]\[char46], classless_static_route = {30\[char46]0\[char46]0\[char46]0/24,10\[char46]0\[char46]0\[char46]4,0\[char46]0\[char46]0\[char46]0/0,10\[char46]0\[char46]0\[char46]1}\[char46]\[char46]\[char46]) +.TP +\fBvalue: str\fR +This indicates that the value of the DHCP option is a string\[char46] +.IP +Example\[char46] \(dqname=host_name\(dq, \(dqcode=12\(dq, \(dqtype=str\(dq\[char46] +.TP +\fBvalue: host_id\fR +This indicates that the value of the DHCP option is a host_id\[char46] It can either be a host_name or an IP address\[char46] +.IP +Example\[char46] \(dqname=tftp_server\(dq, \(dqcode=66\(dq, \(dqtype=host_id\(dq\[char46] +.TP +\fBvalue: domains\fR +This indicates that the value of the DHCP option is a domain name or a comma separated list of domain names\[char46] +.IP +Example\[char46] \(dqname=domain_search_list\(dq, \(dqcode=119\(dq, \(dqtype=domains\(dq\[char46] +.RE +.bp +.SH "DHCPv6_Options TABLE" +.PP +.PP +.PP +Each row in this table stores the DHCPv6 Options supported by native OVN DHCPv6\[char46] \fBovn\-northd\fR populates this table with the supported DHCPv6 options\[char46] \fBovn\-controller\fR looks up this table to get the DHCPv6 codes of the DHCPv6 options defined in the \fBput_dhcpv6_opts\fR action\[char46] Please refer to RFC 3315 and RFC 3646 for the list of DHCPv6 options that can be defined here\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string +.TQ 3.00in +\fBcode\fR +integer, in range 0 to 254 +.TQ 3.00in +\fBtype\fR +string, one of \fBipv6\fR, \fBmac\fR, or \fBstr\fR +.SS "Details: +.IP "\fBname\fR: string" +Name of the DHCPv6 option\[char46] +.IP +Example\[char46] name=\(dqia_addr\(dq +.IP "\fBcode\fR: integer, in range 0 to 254" +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" +Data type of the DHCPv6 option code\[char46] +.RS +.TP +\fBvalue: ipv6\fR +This indicates that the value of the DHCPv6 option is an IPv6 address(es)\[char46] +.IP +Example\[char46] \(dqname=ia_addr\(dq, \(dqcode=5\(dq, \(dqtype=ipv6\(dq\[char46] +.IP +put_dhcpv6_opts(\[char46]\[char46]\[char46], ia_addr = ae70::4,\[char46]\[char46]\[char46]) +.TP +\fBvalue: str\fR +This indicates that the value of the DHCPv6 option is a string\[char46] +.IP +Example\[char46] \(dqname=domain_search\(dq, \(dqcode=24\(dq, \(dqtype=str\(dq\[char46] +.IP +put_dhcpv6_opts(\[char46]\[char46]\[char46], domain_search = ovn\[char46]domain,\[char46]\[char46]\[char46]) +.TP +\fBvalue: mac\fR +This indicates that the value of the DHCPv6 option is a MAC address\[char46] +.IP +Example\[char46] \(dqname=server_id\(dq, \(dqcode=2\(dq, \(dqtype=mac\(dq\[char46] +.IP +put_dhcpv6_opts(\[char46]\[char46]\[char46], server_id = 01:02:03:04L05:06,\[char46]\[char46]\[char46]) +.RE +.bp +.SH "Connection TABLE" +.PP +.PP +.PP +Configuration for a database connection to an Open vSwitch database (OVSDB) client\[char46] +.PP +.PP +This table primarily configures the Open vSwitch database server (\fBovsdb\-server\fR)\[char46] +.PP +.PP +The Open vSwitch database server can initiate and maintain active connections to remote clients\[char46] It can also listen for database connections\[char46] +.SS "Summary: +.TQ .25in +\fICore Features:\fR +.RS .25in +.TQ 2.75in +\fBtarget\fR +string (must be unique within table) +.TQ 2.75in +\fBread_only\fR +boolean +.TQ 2.75in +\fBrole\fR +string +.RE +.TQ .25in +\fIClient Failure Detection and Handling:\fR +.RS .25in +.TQ 2.75in +\fBmax_backoff\fR +optional integer, at least 1,000 +.TQ 2.75in +\fBinactivity_probe\fR +optional integer +.RE +.TQ .25in +\fIStatus:\fR +.RS .25in +.TQ 2.75in +\fBis_connected\fR +boolean +.TQ 2.75in +\fBstatus : last_error\fR +optional string +.TQ 2.75in +\fBstatus : state\fR +optional string, one of \fBACTIVE\fR, \fBBACKOFF\fR, \fBCONNECTING\fR, \fBIDLE\fR, or \fBVOID\fR +.TQ 2.75in +\fBstatus : sec_since_connect\fR +optional string, containing an integer, at least 0 +.TQ 2.75in +\fBstatus : sec_since_disconnect\fR +optional string, containing an integer, at least 0 +.TQ 2.75in +\fBstatus : locks_held\fR +optional string +.TQ 2.75in +\fBstatus : locks_waiting\fR +optional string +.TQ 2.75in +\fBstatus : locks_lost\fR +optional string +.TQ 2.75in +\fBstatus : n_connections\fR +optional string, containing an integer, at least 2 +.TQ 2.75in +\fBstatus : bound_port\fR +optional string, containing an integer +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.TQ 2.75in +\fBother_config\fR +map of string-string pairs +.RE +.SS "Details: +.ST "Core Features:" +.PP +.IP "\fBtarget\fR: string (must be unique within table)" +Connection methods for clients\[char46] +.IP +The following connection methods are currently supported: +.RS +.TP +\fBssl:\fIhost\fB\fR[\fB:\fIport\fB\fR] +The specified SSL \fIport\fR on the given \fIhost\fR, which can either be a DNS name (if built with unbound library) or an IP address\[char46] A valid SSL configuration must be provided when this form is used, this configuration can be specified via command-line options or the \fBSSL\fR table\[char46] +.IP +If \fIport\fR is not specified, it defaults to 6640\[char46] +.IP +SSL support is an optional feature that is not always built as part of Open vSwitch\[char46] +.TP +\fBtcp:\fIhost\fB\fR[\fB:\fIport\fB\fR] +The specified TCP \fIport\fR on the given \fIhost\fR, which can either be a DNS name (if built with unbound library) or an IP address (IPv4 or IPv6)\[char46] If \fIhost\fR is an IPv6 address, wrap it in square brackets, e\[char46]g\[char46] \fBtcp:[::1]:6640\fR\[char46] +.IP +If \fIport\fR is not specified, it defaults to 6640\[char46] +.TP +\fBpssl:\fR[\fIport\fR][\fB:\fIhost\fB\fR] +Listens for SSL connections on the specified TCP \fIport\fR\[char46] Specify 0 for \fIport\fR to have the kernel automatically choose an available port\[char46] If \fIhost\fR, 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)\[char46] If \fIhost\fR is an IPv6 address, wrap in square brackets, e\[char46]g\[char46] \fBpssl:6640:[::1]\fR\[char46] If \fIhost\fR is not specified then it listens only on IPv4 (but not IPv6) addresses\[char46] A valid SSL configuration must be provided when this form is used, this can be specified either via command-line options or the \fBSSL\fR table\[char46] +.IP +If \fIport\fR is not specified, it defaults to 6640\[char46] +.IP +SSL support is an optional feature that is not always built as part of Open vSwitch\[char46] +.TP +\fBptcp:\fR[\fIport\fR][\fB:\fIhost\fB\fR] +Listens for connections on the specified TCP \fIport\fR\[char46] Specify 0 for \fIport\fR to have the kernel automatically choose an available port\[char46] If \fIhost\fR, 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)\[char46] If \fIhost\fR is an IPv6 address, wrap it in square brackets, e\[char46]g\[char46] \fBptcp:6640:[::1]\fR\[char46] If \fIhost\fR is not specified then it listens only on IPv4 addresses\[char46] +.IP +If \fIport\fR is not specified, it defaults to 6640\[char46] +.RE +.IP +When multiple clients are configured, the \fBtarget\fR values must be unique\[char46] Duplicate \fBtarget\fR values yield unspecified results\[char46] +.IP "\fBread_only\fR: boolean" +\fBtrue\fR to restrict these connections to read-only transactions, \fBfalse\fR to allow them to modify the database\[char46] +.IP "\fBrole\fR: string" +String containing role name for this connection entry\[char46] +.ST "Client Failure Detection and Handling:" +.PP +.IP "\fBmax_backoff\fR: optional integer, at least 1,000" +Maximum number of milliseconds to wait between connection attempts\[char46] Default is implementation-specific\[char46] +.IP "\fBinactivity_probe\fR: optional integer" +Maximum number of milliseconds of idle time on connection to the client before sending an inactivity probe message\[char46] If Open vSwitch does not communicate with the client for the specified number of seconds, it will send a probe\[char46] If a response is not received for the same additional amount of time, Open vSwitch assumes the connection has been broken and attempts to reconnect\[char46] Default is implementation-specific\[char46] A value of 0 disables inactivity probes\[char46] +.ST "Status:" +.PP +.PP +.PP +Key-value pair of \fBis_connected\fR is always updated\[char46] Other key-value pairs in the status columns may be updated depends on the \fBtarget\fR type\[char46] +.PP +.PP +When \fBtarget\fR specifies a connection method that listens for inbound connections (e\[char46]g\[char46] \fBptcp:\fR or \fBpunix:\fR), both \fBn_connections\fR and \fBis_connected\fR may also be updated while the remaining key-value pairs are omitted\[char46] +.PP +.PP +On the other hand, when \fBtarget\fR specifies an outbound connection, all key-value pairs may be updated, except the above-mentioned two key-value pairs associated with inbound connection targets\[char46] They are omitted\[char46] +.IP "\fBis_connected\fR: boolean" +\fBtrue\fR if currently connected to this client, \fBfalse\fR otherwise\[char46] +.IP "\fBstatus : last_error\fR: optional string" +A human-readable description of the last error on the connection to the manager; i\[char46]e\[char46] \fBstrerror(errno)\fR\[char46] This key will exist only if an error has occurred\[char46] +.IP "\fBstatus : state\fR: optional string, one of \fBACTIVE\fR, \fBBACKOFF\fR, \fBCONNECTING\fR, \fBIDLE\fR, or \fBVOID\fR" +The state of the connection to the manager: +.RS +.TP +\fBVOID\fR +Connection is disabled\[char46] +.TP +\fBBACKOFF\fR +Attempting to reconnect at an increasing period\[char46] +.TP +\fBCONNECTING\fR +Attempting to connect\[char46] +.TP +\fBACTIVE\fR +Connected, remote host responsive\[char46] +.TP +\fBIDLE\fR +Connection is idle\[char46] Waiting for response to keep-alive\[char46] +.RE +.IP +These values may change in the future\[char46] They are provided only for human consumption\[char46] +.IP "\fBstatus : sec_since_connect\fR: optional string, containing an integer, at least 0" +The amount of time since this client last successfully connected to the database (in seconds)\[char46] Value is empty if client has never successfully been connected\[char46] +.IP "\fBstatus : sec_since_disconnect\fR: optional string, containing an integer, at least 0" +The amount of time since this client last disconnected from the database (in seconds)\[char46] Value is empty if client has never disconnected\[char46] +.IP "\fBstatus : locks_held\fR: optional string" +Space-separated list of the names of OVSDB locks that the connection holds\[char46] Omitted if the connection does not hold any locks\[char46] +.IP "\fBstatus : locks_waiting\fR: optional string" +Space-separated list of the names of OVSDB locks that the connection is currently waiting to acquire\[char46] Omitted if the connection is not waiting for any locks\[char46] +.IP "\fBstatus : locks_lost\fR: optional string" +Space-separated list of the names of OVSDB locks that the connection has had stolen by another OVSDB client\[char46] Omitted if no locks have been stolen from this connection\[char46] +.IP "\fBstatus : n_connections\fR: optional string, containing an integer, at least 2" +When \fBtarget\fR specifies a connection method that listens for inbound connections (e\[char46]g\[char46] \fBptcp:\fR or \fBpssl:\fR) and more than one connection is actually active, the value is the number of active connections\[char46] Otherwise, this key-value pair is omitted\[char46] +.IP "\fBstatus : bound_port\fR: optional string, containing an integer" +When \fBtarget\fR is \fBptcp:\fR or \fBpssl:\fR, this is the TCP port on which the OVSDB server is listening\[char46] (This is particularly useful when \fBtarget\fR specifies a port of 0, allowing the kernel to choose any available port\[char46]) +.ST "Common Columns:" +.PP +The overall purpose of these columns is described under \fBCommon +Columns\fR at the beginning of this document\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +.IP "\fBother_config\fR: map of string-string pairs" +.bp +.SH "SSL TABLE" +.PP +SSL configuration for ovn-sb database access\[char46] +.SS "Summary: +.TQ 3.00in +\fBprivate_key\fR +string +.TQ 3.00in +\fBcertificate\fR +string +.TQ 3.00in +\fBca_cert\fR +string +.TQ 3.00in +\fBbootstrap_ca_cert\fR +boolean +.TQ 3.00in +\fBssl_protocols\fR +string +.TQ 3.00in +\fBssl_ciphers\fR +string +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBprivate_key\fR: string" +Name of a PEM file containing the private key used as the switch\(cqs identity for SSL connections to the controller\[char46] +.IP "\fBcertificate\fR: string" +Name of a PEM file containing a certificate, signed by the certificate authority (CA) used by the controller and manager, that certifies the switch\(cqs private key, identifying a trustworthy switch\[char46] +.IP "\fBca_cert\fR: string" +Name of a PEM file containing the CA certificate used to verify that the switch is connected to a trustworthy controller\[char46] +.IP "\fBbootstrap_ca_cert\fR: boolean" +If set to \fBtrue\fR, 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\[char46] 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\[char46] \fBThis option exposes the +SSL connection to a man\-in\-the\-middle attack obtaining the initial +CA certificate\[char46]\fR It may still be useful for bootstrapping\[char46] +.IP "\fBssl_protocols\fR: string" +List of SSL protocols to be enabled for SSL connections\[char46] The default when this option is omitted is \fBTLSv1,TLSv1\[char46]1,TLSv1\[char46]2\fR\[char46] +.IP "\fBssl_ciphers\fR: string" +List of ciphers (in OpenSSL cipher string format) to be supported for SSL connections\[char46] The default when this option is omitted is \fBHIGH:!aNULL:!MD5\fR\[char46] +.ST "Common Columns:" +.PP +The overall purpose of these columns is described under \fBCommon +Columns\fR at the beginning of this document\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +.bp +.SH "DNS TABLE" +.PP +.PP +.PP +Each row in this table stores the DNS records\[char46] The OVN action \fBdns_lookup\fR uses this table for DNS resolution\[char46] +.SS "Summary: +.TQ 3.00in +\fBrecords\fR +map of string-string pairs +.TQ 3.00in +\fBdatapaths\fR +set of 1 or more \fBDatapath_Binding\fRs +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBrecords\fR: map of string-string pairs" +Key-value pair of DNS records with \fBDNS query name\fR as the key and a string of IP address(es) separated by comma or space as the value\[char46] ovn-northd stores the DNS query name in all lowercase in order to facilitate case-insensitive lookups\[char46] +.IP +\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] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "RBAC_Role TABLE" +.PP +Role table for role-based access controls\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string +.TQ 3.00in +\fBpermissions\fR +map of string-weak reference to \fBRBAC_Permission\fR pairs +.SS "Details: +.IP "\fBname\fR: string" +The role name, corresponding to the \fBrole\fR column in the \fBConnection\fR table\[char46] +.IP "\fBpermissions\fR: map of string-weak reference to \fBRBAC_Permission\fR pairs" +A mapping of table names to rows in the \fBRBAC_Permission\fR table\[char46] +.bp +.SH "RBAC_Permission TABLE" +.PP +Permissions table for role-based access controls\[char46] +.SS "Summary: +.TQ 3.00in +\fBtable\fR +string +.TQ 3.00in +\fBauthorization\fR +set of strings +.TQ 3.00in +\fBinsert_delete\fR +boolean +.TQ 3.00in +\fBupdate\fR +set of strings +.SS "Details: +.IP "\fBtable\fR: string" +Name of table to which this row applies\[char46] +.IP "\fBauthorization\fR: set of strings" +Set of strings identifying columns and column:key pairs to be compared with client ID\[char46] At least one match is required in order to be authorized\[char46] A zero-length string is treated as a special value indicating all clients should be considered authorized\[char46] +.IP "\fBinsert_delete\fR: boolean" +When \(dqtrue\(dq, row insertions and authorized row deletions are permitted\[char46] +.IP "\fBupdate\fR: set of strings" +Set of strings identifying columns and column:key pairs that authorized clients are allowed to modify\[char46] +.bp +.SH "Gateway_Chassis TABLE" +.PP +.PP +.PP +Association of \fBPort_Binding\fR rows of \fBtype\fR \fBchassisredirect\fR to a \fBChassis\fR\[char46] The traffic going out through a specific \fBchassisredirect\fR port will be redirected to a chassis, or a set of them in high availability configurations\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBchassis\fR +optional weak reference to \fBChassis\fR +.TQ 3.00in +\fBpriority\fR +integer, in range 0 to 32,767 +.TQ 3.00in +\fBoptions\fR +map of string-string pairs +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBname\fR: string (must be unique within table)" +Name of the \fBGateway_Chassis\fR\[char46] +.IP +A suggested, but not required naming convention is \fB${port_name}_${chassis_name}\fR\[char46] +.IP "\fBchassis\fR: optional weak reference to \fBChassis\fR" +The \fBChassis\fR to which we send the traffic\[char46] +.IP "\fBpriority\fR: integer, in range 0 to 32,767" +This is the priority the specific \fBChassis\fR among all Gateway_Chassis belonging to the same \fBPort_Binding\fR\[char46] +.IP "\fBoptions\fR: map of string-string pairs" +Reserved for future use\[char46] +.ST "Common Columns:" +.PP +The overall purpose of these columns is described under \fBCommon +Columns\fR at the beginning of this document\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +.bp +.SH "HA_Chassis TABLE" +.PP +.SS "Summary: +.TQ 3.00in +\fBchassis\fR +optional weak reference to \fBChassis\fR +.TQ 3.00in +\fBpriority\fR +integer, in range 0 to 32,767 +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBchassis\fR: optional weak reference to \fBChassis\fR" +The \fBChassis\fR which provides the HA functionality\[char46] +.IP "\fBpriority\fR: integer, in range 0 to 32,767" +Priority of the HA chassis\[char46] Chassis with highest priority will be the master in the HA chassis group\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "HA_Chassis_Group TABLE" +.PP +.PP +.PP +Table representing a group of chassis which can provide High availability services\[char46] Each chassis in the group is represented by the table \fBHA_Chassis\fR\[char46] The HA chassis with highest priority will be the master of this group\[char46] If the master chassis failover is detected, the HA chassis with the next higher priority takes over the responsibility of providing the HA\[char46] If \fBha_chassis_group\fR column of the table \fBPort_Binding\fR references this table, then this HA chassis group provides the gateway functionality and redirects the gateway traffic to the master of this group\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string (must be unique within table) +.TQ 3.00in +\fBha_chassis\fR +set of \fBHA_Chassis\fRes +.TQ 3.00in +\fBref_chassis\fR +set of weak reference to \fBChassis\fR +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBname\fR: string (must be unique within table)" +Name of the \fBHA_Chassis_Group\fR\[char46] Name should be unique\[char46] +.IP "\fBha_chassis\fR: set of \fBHA_Chassis\fRes" +A list of \fBHA_Chassis\fR which belongs to this group\[char46] +.IP "\fBref_chassis\fR: set of weak reference to \fBChassis\fR" +The set of \fBChassis\fR that reference this HA chassis group\[char46] To determine the correct \fBChassis\fR, find the \fBchassisredirect\fR type \fBPort_Binding\fR that references this \fBHA_Chassis_Group\fR\[char46] This \fBPort_Binding\fR is derived from some particular logical router\[char46] 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\[char46] For each LSP in these logical switches, find the corresponding \fBPort_Binding\fR and add its bound \fBChassis\fR (if any) to \fBref_chassis\fR\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "Controller_Event TABLE" +.PP +.PP +.PP +Database table used by \fBovn\-controller\fR to report CMS related events\[char46] Please note there is no guarantee a given event is written exactly once in the db\[char46] It is CMS responsibility to squash duplicated lines or to filter out duplicated events +.SS "Summary: +.TQ 3.00in +\fBevent_type\fR +string, must be \fBempty_lb_backends\fR +.TQ 3.00in +\fBevent_info\fR +map of string-string pairs +.TQ 3.00in +\fBchassis\fR +optional weak reference to \fBChassis\fR +.TQ 3.00in +\fBseq_num\fR +integer +.SS "Details: +.IP "\fBevent_type\fR: string, must be \fBempty_lb_backends\fR" +Event type occurred +.IP "\fBevent_info\fR: map of string-string pairs" +Key-value pairs used to specify event info to the CMS\[char46] Possible values are: +.RS +.IP \(bu +\fBvip\fR: VIP reported for the \fBempty_lb_backends\fR event +.IP \(bu +\fBprotocol\fR: Transport protocol reported for the \fBempty_lb_backends\fR event +.IP \(bu +\fBload_balancer\fR: UUID of the load balancer reported for the \fBempty_lb_backends\fR event +.RE +.IP "\fBchassis\fR: optional weak reference to \fBChassis\fR" +This column is a \fBChassis\fR record to identify the chassis that has managed a given event\[char46] +.IP "\fBseq_num\fR: integer" +Event sequence number\[char46] Global counter for controller generated events\[char46] It can be used by the CMS to detect possible duplication of the same event\[char46] +.bp +.SH "IP_Multicast TABLE" +.PP +.PP +.PP +IP Multicast configuration options\[char46] For now only applicable to IGMP\[char46] +.SS "Summary: +.TQ 3.00in +\fBdatapath\fR +weak reference to \fBDatapath_Binding\fR (must be unique within table) +.TQ 3.00in +\fBenabled\fR +optional boolean +.TQ 3.00in +\fBquerier\fR +optional boolean +.TQ 3.00in +\fBtable_size\fR +optional integer +.TQ 3.00in +\fBidle_timeout\fR +optional integer +.TQ 3.00in +\fBquery_interval\fR +optional integer +.TQ 3.00in +\fBseq_no\fR +integer +.TQ .25in +\fIQuerier configuration options:\fR +.RS .25in +.TQ 2.75in +\fBeth_src\fR +string +.TQ 2.75in +\fBip4_src\fR +string +.TQ 2.75in +\fBip6_src\fR +string +.TQ 2.75in +\fBquery_max_resp\fR +optional integer +.RE +.SS "Details: +.IP "\fBdatapath\fR: weak reference to \fBDatapath_Binding\fR (must be unique within table)" +\fBDatapath_Binding\fR entry for which these configuration options are defined\[char46] +.IP "\fBenabled\fR: optional boolean" +Enables/disables multicast snooping\[char46] Default: disabled\[char46] +.IP "\fBquerier\fR: optional boolean" +Enables/disables multicast querying\[char46] If \fBenabled\fR then multicast querying is enabled by default\[char46] +.IP "\fBtable_size\fR: optional integer" +Limits the number of multicast groups that can be learned\[char46] Default: 2048 groups per datapath\[char46] +.IP "\fBidle_timeout\fR: optional integer" +Configures the idle timeout (in seconds) for IP multicast groups if multicast snooping is enabled\[char46] Default: 300 seconds\[char46] +.IP "\fBquery_interval\fR: optional integer" +Configures the interval (in seconds) for sending multicast queries if snooping and querier are enabled\[char46] Default: \fBidle_timeout\fR/2 seconds\[char46] +.IP "\fBseq_no\fR: integer" +\fBovn\-controller\fR reads this value and flushes all learned multicast groups when it detects that \fBseq_no\fR was changed\[char46] +.ST "Querier configuration options:" +.PP +The \fBovn\-controller\fR process that runs on OVN hypervisor nodes uses the following columns to determine field values in IGMP/MLD queries that it originates: +.IP "\fBeth_src\fR: string" +Source Ethernet address\[char46] +.IP "\fBip4_src\fR: string" +Source IPv4 address\[char46] +.IP "\fBip6_src\fR: string" +Source IPv6 address\[char46] +.IP "\fBquery_max_resp\fR: optional integer" +Value (in seconds) to be used as \(dqmax-response\(dq field in multicast queries\[char46] Default: 1 second\[char46] +.bp +.SH "IGMP_Group TABLE" +.PP +.PP +.PP +Contains learned IGMP groups indexed by address/datapath/chassis\[char46] +.SS "Summary: +.TQ 3.00in +\fBaddress\fR +string +.TQ 3.00in +\fBdatapath\fR +optional weak reference to \fBDatapath_Binding\fR +.TQ 3.00in +\fBchassis\fR +optional weak reference to \fBChassis\fR +.TQ 3.00in +\fBports\fR +set of weak reference to \fBPort_Binding\fRs +.SS "Details: +.IP "\fBaddress\fR: string" +Destination IPv4 address for the IGMP group\[char46] +.IP "\fBdatapath\fR: optional weak reference to \fBDatapath_Binding\fR" +Datapath to which this IGMP group belongs\[char46] +.IP "\fBchassis\fR: optional weak reference to \fBChassis\fR" +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] +.bp +.SH "Service_Monitor TABLE" +.PP +.PP +.PP +Each row in this table configures monitoring a service for its liveness\[char46] The service can be an IPv4 TCP or UDP service\[char46] \fBovn\-controller\fR periodically sends out service monitor packets and updates the status of the service\[char46] Service monitoring for IPv6 services is not supported\[char46] +.PP +.PP +\fBovn\-northd\fR uses this feature to implement the load balancer health check feature offered to the CMS through the northbound database\[char46] +.SS "Summary: +.TQ .25in +\fIConfiguration:\fR +.RS .25in +.TQ 2.75in +\fBip\fR +string +.TQ 2.75in +\fBprotocol\fR +optional string, either \fBtcp\fR or \fBudp\fR +.TQ 2.75in +\fBport\fR +integer, in range 0 to 65,535 +.TQ 2.75in +\fBlogical_port\fR +string +.TQ 2.75in +\fBsrc_mac\fR +string +.TQ 2.75in +\fBsrc_ip\fR +string +.TQ 2.75in +\fBoptions : interval\fR +optional string, containing an integer +.TQ 2.75in +\fBoptions : timeout\fR +optional string, containing an integer +.TQ 2.75in +\fBoptions : success_count\fR +optional string, containing an integer +.TQ 2.75in +\fBoptions : failure_count\fR +optional string, containing an integer +.RE +.TQ .25in +\fIStatus Reporting:\fR +.RS .25in +.TQ 2.75in +\fBstatus\fR +optional string, one of \fBerror\fR, \fBoffline\fR, or \fBonline\fR +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.ST "Configuration:" +.PP +.PP +.PP +\fBovn\-northd\fR sets these columns and values to configure the service monitor\[char46] +.IP "\fBip\fR: string" +IP of the service to be monitored\[char46] Only IPv4 is supported\[char46] +.IP "\fBprotocol\fR: optional string, either \fBtcp\fR or \fBudp\fR" +The protocol of the service\[char46] +.IP "\fBport\fR: integer, in range 0 to 65,535" +The TCP or UDP port of the service\[char46] +.IP "\fBlogical_port\fR: string" +The VIF of the logical port on which the service is running\[char46] The \fBovn\-controller\fR that binds this \fBlogical_port\fR monitors the service by sending periodic monitor packets\[char46] +.IP "\fBsrc_mac\fR: string" +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 "\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" +The time, in seconds, after which the service monitor check times out\[char46] +.IP "\fBoptions : success_count\fR: optional string, containing an integer" +The number of successful checks after which the service is considered \fBonline\fR\[char46] +.IP "\fBoptions : failure_count\fR: optional string, containing an integer" +The number of failure checks after which the service is considered \fBoffline\fR\[char46] +.ST "Status Reporting:" +.PP +.PP +.PP +The \fBovn\-controller\fR on the chassis that hosts the \fBlogical_port\fR updates this column to report the service\(cqs status\[char46] +.IP "\fBstatus\fR: optional string, one of \fBerror\fR, \fBoffline\fR, or \fBonline\fR" +For TCP service, \fBovn\-controller\fR sends a SYN to the service and expects an ACK response to consider the service to be \fBonline\fR\[char46] +.IP +For UDP service, \fBovn\-controller\fR sends a UDP packet to the service and doesn\(cqt expect any reply\[char46] If it receives an ICMP reply, then it considers the service to be \fBoffline\fR\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "Load_Balancer TABLE" +.PP +.PP +.PP +Each row represents a load balancer\[char46] +.SS "Summary: +.TQ 3.00in +\fBname\fR +string +.TQ 3.00in +\fBvips\fR +map of string-string pairs +.TQ 3.00in +\fBprotocol\fR +optional string, one of \fBsctp\fR, \fBtcp\fR, or \fBudp\fR +.TQ 3.00in +\fBdatapaths\fR +set of \fBDatapath_Binding\fRs +.TQ 3.00in +\fBdatapath_group\fR +optional \fBLogical_DP_Group\fR +.TQ .25in +\fILoad_Balancer options:\fR +.RS .25in +.TQ 2.75in +\fBoptions : hairpin_snat_ip\fR +optional string +.TQ 2.75in +\fBoptions : hairpin_orig_tuple\fR +optional string, either \fBtrue\fR or \fBfalse\fR +.RE +.TQ .25in +\fICommon Columns:\fR +.RS .25in +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.SS "Details: +.IP "\fBname\fR: string" +A name for the load balancer\[char46] This name has no special meaning or purpose other than to provide convenience for human interaction with the ovn-nb database\[char46] +.IP "\fBvips\fR: map of string-string pairs" +A map of virtual IP addresses (and an optional port number with \fB:\fR as a separator) associated with this load balancer and their corresponding endpoint IP addresses (and optional port numbers with \fB:\fR as separators) separated by commas\[char46] +.IP "\fBprotocol\fR: optional string, one of \fBsctp\fR, \fBtcp\fR, or \fBudp\fR" +Valid protocols are \fBtcp\fR, \fBudp\fR, or \fBsctp\fR\[char46] This column is useful when a port number is provided as part of the \fBvips\fR column\[char46] If this column is empty and a port number is provided as part of \fBvips\fR column, OVN assumes the protocol to be \fBtcp\fR\[char46] +.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" +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] +.ST "Load_Balancer options:" +.PP +.IP "\fBoptions : hairpin_snat_ip\fR: optional string" +IP to be used as source IP for packets that have been hair-pinned after load balancing\[char46] This value is automatically populated by \fBovn\-northd\fR\[char46] +.IP "\fBoptions : hairpin_orig_tuple\fR: optional string, either \fBtrue\fR or \fBfalse\fR" +This value is automatically set to \fBtrue\fR by \fBovn\-northd\fR when original destination IP and transport port of the load balanced packets are stored in registers \fBreg1, reg2, xxreg1\fR\[char46] +.ST "Common Columns:" +.PP +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.bp +.SH "BFD TABLE" +.PP +.PP +.PP +Contains BFD parameter for ovn-controller bfd configuration\[char46] +.SS "Summary: +.TQ .25in +\fIConfiguration:\fR +.RS .25in +.TQ 2.75in +\fBsrc_port\fR +integer, in range 49,152 to 65,535 +.TQ 2.75in +\fBdisc\fR +integer +.TQ 2.75in +\fBlogical_port\fR +string +.TQ 2.75in +\fBdst_ip\fR +string +.TQ 2.75in +\fBmin_tx\fR +integer +.TQ 2.75in +\fBmin_rx\fR +integer +.TQ 2.75in +\fBdetect_mult\fR +integer +.TQ 2.75in +\fBoptions\fR +map of string-string pairs +.TQ 2.75in +\fBexternal_ids\fR +map of string-string pairs +.RE +.TQ .25in +\fIStatus Reporting:\fR +.RS .25in +.TQ 2.75in +\fBstatus\fR +string, one of \fBadmin_down\fR, \fBdown\fR, \fBinit\fR, or \fBup\fR +.RE +.SS "Details: +.ST "Configuration:" +.PP +.IP "\fBsrc_port\fR: integer, in range 49,152 to 65,535" +udp source port used in bfd control packets\[char46] The source port MUST be in the range 49152 through 65535 (RFC5881 section 4)\[char46] +.IP "\fBdisc\fR: integer" +A unique, nonzero discriminator value generated by the transmitting system, used to demultiplex multiple BFD sessions between the same pair of systems\[char46] +.IP "\fBlogical_port\fR: string" +OVN logical port when BFD engine is running\[char46] +.IP "\fBdst_ip\fR: string" +BFD peer IP address\[char46] +.IP "\fBmin_tx\fR: integer" +This is the minimum interval, in milliseconds, that the local system would like to use when transmitting BFD Control packets, less any jitter applied\[char46] The value zero is reserved\[char46] +.IP "\fBmin_rx\fR: 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\[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 "\fBoptions\fR: map of string-string pairs" +Reserved for future use\[char46] +.IP "\fBexternal_ids\fR: map of string-string pairs" +See \fBExternal IDs\fR at the beginning of this document\[char46] +.ST "Status Reporting:" +.PP +.IP "\fBstatus\fR: string, one of \fBadmin_down\fR, \fBdown\fR, \fBinit\fR, or \fBup\fR" +BFD port logical states\[char46] Possible values are: +.RS +.IP \(bu +\fBadmin_down\fR +.IP \(bu +\fBdown\fR +.IP \(bu +\fBinit\fR +.IP \(bu +\fBup\fR +.RE +.bp +.SH "FDB TABLE" +.PP +.PP +.PP +This table is primarily used to learn the MACs observed on a VIF (or a localnet port with \(cqlocalnet_learn_fdb\(cq enabled) which belongs to a \fBLogical_Switch_Port\fR record in \fBOVN_Northbound\fR whose port security is disabled and \(cqunknown\(cq address set\[char46] If port security is disabled on a \fBLogical_Switch_Port\fR record, OVN should allow traffic with any source mac from the VIF\[char46] This table will be used to deliver a packet to the VIF, If a packet\(cqs \fBeth\[char46]dst\fR is learnt\[char46] +.SS "Summary: +.TQ 3.00in +\fBmac\fR +string +.TQ 3.00in +\fBdp_key\fR +integer, in range 1 to 16,777,215 +.TQ 3.00in +\fBport_key\fR +integer, in range 1 to 16,777,215 +.SS "Details: +.IP "\fBmac\fR: string" +The learnt mac address\[char46] +.IP "\fBdp_key\fR: integer, in range 1 to 16,777,215" +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] +.bp +.SH "Static_MAC_Binding TABLE" +.PP +.PP +.PP +Each record represents a Static_MAC_Binding entry for a logical router\[char46] +.SS "Summary: +.TQ 3.00in +\fBlogical_port\fR +string +.TQ 3.00in +\fBip\fR +string +.TQ 3.00in +\fBmac\fR +string +.TQ 3.00in +\fBoverride_dynamic_mac\fR +boolean +.TQ 3.00in +\fBdatapath\fR +\fBDatapath_Binding\fR +.SS "Details: +.IP "\fBlogical_port\fR: string" +The logical router port for the binding\[char46] +.IP "\fBip\fR: string" +The bound IP address\[char46] +.IP "\fBmac\fR: string" +The Ethernet address to which the IP is bound\[char46] +.IP "\fBoverride_dynamic_mac\fR: boolean" +Override dynamically learnt MACs\[char46] +.IP "\fBdatapath\fR: \fBDatapath_Binding\fR" +The logical datapath to which the logical router port belongs\[char46] +.bp +.SH "Chassis_Template_Var TABLE" +.PP +.PP +.PP +Each record represents the set of template variable instantiations for a given chassis and is populated by \fBovn\-northd\fR from the contents of the \fBOVN_Northbound\[char46]Chassis_Template_Var\fR table\[char46] +.SS "Summary: +.TQ 3.00in +\fBchassis\fR +string (must be unique within table) +.TQ 3.00in +\fBvariables\fR +map of string-string pairs +.SS "Details: +.IP "\fBchassis\fR: string (must be unique within table)" +The chassis this set of variable values applies to\[char46] +.IP "\fBvariables\fR: map of string-string pairs" +The set of variable values for a given chassis\[char46] diff --git a/src/static/support/dist-docs-branch-23.06/ovn-sb.5.html b/src/static/support/dist-docs-branch-23.06/ovn-sb.5.html new file mode 100644 index 00000000..2cd471b8 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-sb.5.html @@ -0,0 +1,3974 @@ +
+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  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
+       northbound to the Cloud Management System, via ovn-northd:
+
+   Database Structure
+       The OVN Southbound database contains classes  of  data  with  different
+       properties, as described in the sections below.
+
+     Physical network
+
+       Physical  network tables contain 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
+       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
+       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ā€
+       pates.
+
+       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
+       and ovn-northd.
+
+       Logical network data is likely to change  more  quickly  than  physical
+       network  data. This is especially true in a container environment where
+       containers are created  and  destroyed  (and  therefore  added  to  and
+       deleted from logical switches) quickly.
+
+       The   Logical_Flow,   Multicast_Group,   Address_Group,   DHCP_Options,
+       DHCPv6_Options, and DNS tables contain logical network data.
+
+     Logical-physical bindings
+
+       These tables link logical and physical components. They show  the  curā€
+       rent  placement of logical components (such as VMs and VIFs) onto chasā€
+       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.
+       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ā€
+       tion, so the consistency needs are minimal.
+
+       The Port_Binding and Datapath_Binding tables contain binding data.
+
+     MAC bindings
+
+       The MAC_Binding table tracks the bindings from IP addresses to Ethernet
+       addresses that are dynamically discovered  using  ARP  (for  IPv4)  and
+       neighbor  discovery (for IPv6). Usually, IP-to-MAC bindings for virtual
+       machines are statically  populated  into  the  Port_Binding  table,  so
+       MAC_Binding  is  primarily  used  to discover bindings on physical netā€
+       works.
+
+   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 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ā€ā€
+                     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
+                     as  entities  in the OVN Northbound database). Individual
+                     key-value pairs in this column may be documented in  some
+                     cases  to  aid  in understanding and troubleshooting, but
+                     the reader should not mistake such documentation as  comā€
+                     prehensive.
+
+TABLE SUMMARY
+       The  following list summarizes the purpose of each of the tables in the
+       OVN_Southbound database.  Each table is described in more detail  on  a
+       later page.
+
+       Table     Purpose
+       SB_Global Southbound configuration
+       Chassis   Physical Network Hypervisor and Gateway Information
+       Chassis_Private
+                 Chassis Private
+       Encap     Encapsulation Types
+       Address_Set
+                 Address Sets
+       Port_Group
+                 Port Groups
+       Logical_Flow
+                 Logical Network Flows
+       Logical_DP_Group
+                 Logical Datapath Groups
+       Multicast_Group
+                 Logical Port Multicast Groups
+       Mirror    Mirror Entry
+       Meter     Meter entry
+       Meter_Band
+                 Band for meter entries
+       Datapath_Binding
+                 Physical-Logical Datapath Bindings
+       Port_Binding
+                 Physical-Logical Port Bindings
+       MAC_Binding
+                 IP to MAC bindings
+       DHCP_Options
+                 DHCP Options supported by native OVN DHCP
+       DHCPv6_Options
+                 DHCPv6 Options supported by native OVN DHCPv6
+       Connection
+                 OVSDB client connections.
+       SSL       SSL configuration.
+       DNS       Native DNS resolution
+       RBAC_Role RBAC_Role configuration.
+       RBAC_Permission
+                 RBAC_Permission configuration.
+       Gateway_Chassis
+                 Gateway_Chassis configuration.
+       HA_Chassis
+                 HA_Chassis configuration.
+       HA_Chassis_Group
+                 HA_Chassis_Group configuration.
+       Controller_Event
+                 Controller Event table
+       IP_Multicast
+                 IP_Multicast configuration.
+       IGMP_Group
+                 IGMP_Group configuration.
+       Service_Monitor
+                 Service_Monitor configuration.
+       Load_Balancer
+                 Load_Balancer configuration.
+       BFD       BFD configuration.
+       FDB       Port to MAC bindings
+       Static_MAC_Binding
+                 IP to MAC bindings
+       Chassis_Template_Var
+                 Chassis_Template_Var configuration.
+
+SB_Global TABLE
+       Southbound  configuration  for  an OVN system. This table must have exā€
+       actly one row.
+
+   Summary:
+       Status:
+         nb_cfg                      integer
+       Common Columns:
+         external_ids                map of string-string pairs
+         options                     map of string-string pairs
+       Common options:
+         options                     map of string-string pairs
+         Options for configuring BFD:
+            options : bfd-min-rx     optional string
+            options : bfd-decay-min-rx
+                                     optional string
+            options : bfd-min-tx     optional string
+            options : bfd-mult       optional string
+            options : debug_drop_domain_id
+                                     optional string
+            options : debug_drop_collector_set
+                                     optional string
+         Options for configuring 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
+       Security Configurations:
+         ipsec                       boolean
+
+   Details:
+     Status:
+
+       This column allow a client to track the overall configuration state  of
+       the system.
+
+       nb_cfg: integer
+              Sequence  number  for the configuration. When a CMS or ovn-nbctl
+              updates the northbound database, it increments the nb_cfg column
+              in the NB_Global table in the northbound database. In turn, when
+              ovn-northd updates the southbound database to  bring  it  up  to
+              date  with  these  changes,  it  updates this column to the same
+              value.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+       options: map of string-string pairs
+
+     Common options:
+
+       options: map of string-string pairs
+              This column provides general key/value settings.  The  supported
+              options are described individually below.
+
+     Options for configuring BFD:
+
+       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
+              interfaces.
+
+       options : bfd-decay-min-rx: optional string
+              BFD  option  decay-min-rx  value  to use when configuring BFD on
+              tunnel interfaces.
+
+       options : bfd-min-tx: optional string
+              BFD option min-tx value to use when configuring  BFD  on  tunnel
+              interfaces.
+
+       options : bfd-mult: optional string
+              BFD  option mult value to use when configuring BFD on tunnel 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   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  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 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 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ā€ā€
+              tion table for more information.
+
+       ssl: optional SSL
+              Global SSL configuration.
+
+     Security Configurations:
+
+       ipsec: boolean
+              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 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
+       equally  unreachable  regardless  of  whether the row is present.) If a
+       chassis shuts down permanently without removing its row, some  kind  of
+       manual  or  automatic  cleanup  is  eventually  needed; we can devise a
+       process for that as necessary.
+
+   Summary:
+       name                          string (must be unique within table)
+       hostname                      string
+       nb_cfg                        integer
+       other_config : ovn-bridge-mappings
+                                     optional string
+       other_config : datapath-type  optional string
+       other_config : iface-types    optional string
+       other_config : ovn-cms-options
+                                     optional string
+       other_config : is-interconn   optional string
+       other_config : is-remote      optional string
+       transport_zones               set of strings
+       other_config : ovn-chassis-mac-mappings
+                                     optional string
+       other_config : port-up-notif  optional string
+       Common Columns:
+         external_ids                map of string-string pairs
+       Encapsulation Configuration:
+         encaps                      set of 1 or more Encaps
+       Gateway Configuration:
+         vtep_logical_switches       set of strings
+
+   Details:
+       name: string (must be unique within table)
+              OVN does not prescribe a particular format  for  chassis  names.
+              ovn-controller  populates this column using external_ids:system-
+              id in the Open_vSwitch databaseā€™s Open_vSwitch  table.  ovn-conā€
+              troller-vtep  populates  this  column  with  name  in  the hardā€
+              ware_vtep databaseā€™s Physical_Switch table.
+
+       hostname: string
+              The hostname of the chassis, if applicable. ovn-controller  will
+              populate this column with the hostname of the host it is running
+              on. ovn-controller-vtep will leave this column empty.
+
+       nb_cfg: integer
+              Deprecated.  This column is replaced by the nb_cfg column of the
+              Chassis_Private table.
+
+       other_config : ovn-bridge-mappings: optional string
+              ovn-controller populates this key with the set  of  bridge  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ā€
+              ured  in the datapath_type column of the Open_vSwitch databaseā€™s
+              Bridge table. Other applications should treat this key as  read-
+              only. See ovn-controller(8) for more information.
+
+       other_config : iface-types: optional string
+              ovn-controller  populates this key with the interface types conā€
+              figured in the iface_types column of the Open_vSwitch databaseā€™s
+              Open_vSwitch table. Other applications should treat this key  as
+              read-only. See ovn-controller(8) for more information.
+
+       other_config : ovn-cms-options: optional string
+              ovn-controller  populates  this key with the set of options 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
+              ovn-controller populates this key with the setting configured in
+              the external_ids:ovn-is-interconn  column  of  the  Open_vSwitch
+              databaseā€™s  Open_vSwitch  table.  If set to true, the chassis is
+              used as an interconnection gateway.  See  ovn-controller(8)  for
+              more information.
+
+       other_config : is-remote: optional string
+              ovn-ic  set  this key to true for remote interconnection gateway
+              chassises learned from the interconnection southbound  database.
+              See ovn-ic(8) for more information.
+
+       transport_zones: set of strings
+              ovn-controller  populates this key with the transport zones conā€
+              figured in the external_ids:ovn-transport-zones  column  of  the
+              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ā€ā€
+              troller(8) for more information.
+
+       other_config : port-up-notif: optional string
+              ovn-controller  populates  this  key  with true when it supports
+              Port_Binding.up.
+
+     Common Columns:
+
+       The overall purpose of these columns is described under Common  Columns
+       at the beginning of this document.
+
+       external_ids: map of string-string pairs
+
+     Encapsulation Configuration:
+
+       OVN  uses  encapsulation  to transmit logical dataplane packets between
+       chassis.
+
+       encaps: set of 1 or more Encaps
+              Points to supported  encapsulation  configurations  to  transmit
+              logical dataplane packets to this chassis. Each entry is a Encap
+              record that describes the configuration.
+
+     Gateway Configuration:
+
+       A  gateway  is  a chassis that forwards traffic between the OVN-managed
+       part of a logical network and a physical VLAN, extending a tunnel-based
+       logical network into a physical network. Gateways are  typically  dediā€
+       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ā€ā€
+              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  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
+       chassis private data update flooding in a large scale deployment.
+
+   Summary:
+       name                          string (must be unique within table)
+       chassis                       optional weak reference to Chassis
+       nb_cfg                        integer
+       nb_cfg_timestamp              integer
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       name: string (must be unique within table)
+              The name of the chassis that owns these chassis-private data.
+
+       chassis: optional weak reference to Chassis
+              The  reference  to Chassis table for the chassis that owns these
+              chassis-private data.
+
+       nb_cfg: integer
+              Sequence number for the configuration. When  ovn-controller  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
+              The timestamp when ovn-controller finishes processing the change
+              corresponding to nb_cfg.
+
+     Common Columns:
+
+       The  overall purpose of these columns is described under Common Columns
+       at the beginning of this document.
+
+       external_ids: map of string-string pairs
+Encap TABLE
+       The encaps column in the Chassis table refers to rows in this table  to
+       identify  how  OVN may transmit logical dataplane packets to this chasā€
+       sis. Each chassis,  via  ovn-controller(8)  or  ovn-controller-vtep(8),
+       adds and updates its own rows and keeps a copy of the remaining rows to
+       determine how to reach other chassis.
+
+   Summary:
+       type                          string, one of geneve, stt, or vxlan
+       options                       map of string-string pairs
+       options : csum                optional string, either true or false
+       options : dst_port            optional string, containing an integer
+       ip                            string
+       chassis_name                  string
+
+   Details:
+       type: string, one of geneve, stt, or vxlan
+              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
+              specific.
+
+       options : csum: optional string, either true or false
+              csum  indicates  whether  this  chassis can transmit and receive
+              packets that include checksums with reasonable  performance.  It
+              hints  to  senders  transmitting  data to this chassis that they
+              should use checksums to  protect  OVN  metadata.  ovn-controller
+              populates  this  key with the value defined in external_ids:ovn-
+              encap-csum column of the  Open_vSwitch  databaseā€™s  Open_vSwitch
+              table.  Other  applications  should treat this key as read-only.
+              See ovn-controller(8) for more information.
+
+              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 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 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
+              checksums well.)
+
+              csum defaults to false for hardware VTEPs and true for all other
+              cases.
+
+              This option applies to geneve and vxlan encapsulations.
+
+       options : dst_port: optional string, containing an integer
+              If set, overrides the UDP (for geneve and  vxlan)  or  TCP  (for
+              stt) destination port.
+
+       ip: string
+              The IPv4 address of the encapsulation tunnel endpoint.
+
+       chassis_name: string
+              The name of the chassis that created this encap.
+
+Address_Set TABLE
+       This  table  contains address sets synced from the Address_Set table in
+       the  OVN_Northbound  database  and  address  sets  generated  from  the
+       Port_Group table in the OVN_Northbound database.
+
+       See the documentation for the Address_Set table and Port_Group table in
+       the OVN_Northbound database for details.
+
+   Summary:
+       name                          string (must be unique within table)
+       addresses                     set of strings
+
+   Details:
+       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
+       in Port_Group in the OVN_Northbound database.
+
+   Summary:
+       name                          string (must be unique within table)
+       ports                         set of strings
+
+   Details:
+       name: string (must be unique within table)
+
+       ports: set of strings
+Logical_Flow TABLE
+       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 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
+       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
+       OpenFlow and OVSDB, to execute them on its behalf.
+
+       At  a high level, OVN passes each packet through the logical datapathā€™s
+       logical ingress pipeline, which may output the packet to  one  or  more
+       logical  port or logical multicast groups. For each such logical output
+       port, OVN passes the  packet  through  the  datapathā€™s  logical  egress
+       pipeline,  which may either drop the packet or deliver it to the 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
+       further details. The next and output actions are special.
+
+       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,
+       flow control returns to the action following next.
+
+       The output action also introduces recursion. Its effect depends on  the
+       current  value of the outport field. Suppose outport designates a 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ā€
+       isters arenā€™t preserve across tunnel encapsulation).
+
+       To execute the egress pipeline, OVN again searches the Logical_Flow taā€
+       ble  for  a  row with correct logical_datapath or a logical_dp_group, a
+       table_id of 0, a match that is true for the packet, but now looking for
+       a pipeline of egress. If no matching row is found, the output becomes a
+       no-op. Otherwise, OVN executes the actions for the matching flow (which
+       is chosen from multiple, if necessary, as already described).
+
+       In the egress pipeline, the next action acts as already described,  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  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  deā€
+       scribed in detail in ovn-northd(8).
+
+   Summary:
+       logical_datapath              optional Datapath_Binding
+       logical_dp_group              optional Logical_DP_Group
+       pipeline                      string, either egress or ingress
+       table_id                      integer, in range 0 to 32
+       priority                      integer, in range 0 to 65,535
+       match                         string
+       actions                       string
+       tags                          map of string-string pairs
+       controller_meter              optional string
+       external_ids : stage-name     optional string
+       external_ids : stage-hint     optional string, containing an uuid
+       external_ids : source         optional string
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       logical_datapath: optional Datapath_Binding
+              The logical datapath to which the logical flow belongs.
+
+       logical_dp_group: optional Logical_DP_Group
+              The  group  of  logical  datapaths to which the logical flow 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ā€ā€
+              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ā€
+              ble number.
+
+       priority: integer, in range 0 to 65,535
+              The flowā€™s priority. Flows with numerically higher priority take
+              precedence  over those with lower. If two logical datapath flows
+              with the same priority both match, then the one actually applied
+              to the packet is undefined.
+
+       match: string
+              A matching expression.  OVN  provides  a  superset  of  OpenFlow
+              matching capabilities, using a syntax similar to Boolean expresā€
+              sions in a programming language.
+
+              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
+              comparisons into a larger expression.
+
+              Matching  expressions also support parentheses for grouping, the
+              logical NOT prefix operator !, and literals 0 and 1  to  express
+              ``falseā€™ā€™ or ``true,ā€™ā€™ respectively. The latter is useful by itā€
+              self as a catch-all expression that matches every packet.
+
+              Match  expressions  also  support a kind of function syntax. The
+              following functions are supported:
+
+              is_chassis_resident(lport)
+                     Evaluates to true on a  chassis  on  which  logical  port
+                     lport  (a quoted string) resides, and to false elsewhere.
+                     This function was introduced in OVN 2.7.
+
+              Symbols
+
+              Type. Symbols have integer or string type. Integer symbols  have
+              a width in bits.
+
+              Kinds. There are three kinds of symbols:
+
+              ā€¢      Fields.  A  field  symbol  represents  a packet header or
+                     metadata field. For example, a field named vlan.tci might
+                     represent the VLAN TCI field in a packet.
+
+                     A field symbol can have integer or string  type.  Integer
+                     fields  can  be nominal or ordinal (see Level of Measureā€ā€
+                     ment, below).
+
+              ā€¢      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  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ā€
+                     nal; other predicates have Boolean level of measurement.
+
+              Level              of              Measurement.              See
+              http://en.wikipedia.org/wiki/Level_of_measurement for  the  staā€
+              tistical  concept  on  which this classification is based. There
+              are three levels:
+
+              ā€¢      Ordinal. In statistics, ordinal values can be ordered  on
+                     a  scale. OVN considers a field (or subfield) to be ordiā€
+                     nal if its bits can be  examined  individually.  This  is
+                     true  for  the  OpenFlow  fields  that  OpenFlow  or Open
+                     vSwitch makes ``maskable.ā€™ā€™
+
+                     Any use of a ordinal field may specify a single bit or  a
+                     range  of  bits,  e.g. vlan.tci[13..15] refers to the PCP
+                     field within the VLAN TCI, and eth.dst[40] refers to  the
+                     multicast bit in the Ethernet destination address.
+
+                     OVN  supports all the usual arithmetic relations (==, !=,
+                     =, >gt;>gt;, and >gt;>gt;=) on ordinal fields and their  subfields,
+                     because  OVN  can  implement  these  in OpenFlow and Open
+                     vSwitch as collections of bitwise tests.
+
+              ā€¢      Nominal. In statistics, nominal values cannot be usefully
+                     compared except for equality. This is  true  of  OpenFlow
+                     port  numbers, Ethernet types, and IP protocols are 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
+                     way for a flow to efficiently implement other comparisons
+                     on  them. (A test for inequality can be sort of built out
+                     of two flows with different priorities, but OVN  matching
+                     expressions  always  generate  flows with a single priorā€
+                     ity.)
+
+                     String fields are always nominal.
+
+              ā€¢      Boolean. A nominal field that has only two values, 0  and
+                     1,  is  somewhat exceptional, since it is easy to support
+                     both equality and inequality tests on such a  field:  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  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 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,
+              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 efā€
+              ficient than that of the other relational operators.
+
+              Constants
+
+              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 inā€
+              tegers, to express CIDR prefixes.
+
+              String constants have the same syntax as quoted strings in  JSON
+              (thus, they are Unicode strings).
+
+              Some  operators  support  sets of constants written inside curly
+              braces { ... }. Commas between elements of a set, and after  the
+              last  elements,  are  optional. With ==, ``field == { constant1,
+              constant2, ... }ā€™ā€™ is syntactic sugar for ``field  ==  constant1
+              || field == constant2 || .... Similarly, ``field != { constant1,
+              constant2,  ...  }ā€™ā€™  is  equivalent  to ``field != constant1 &&&&
+              field != constant2 &&&& ...ā€™ā€™.
+
+              You may refer to a set of IPv4, IPv6, or MAC addresses stored in
+              the Address_Set table by its name. An Address_Set with a name of
+              set1 can be referred to as $set1.
+
+              You may refer to a group of logical switch ports stored  in  the
+              Port_Group  table  by  its  name.  An  Port_Group with a name of
+              port_group1 can be referred to as @port_group1.
+
+              Additionally, you may refer to the set of addresses belonging to
+              a group of logical switch ports stored in the  Port_Group  table
+              by its name followed by a suffix ā€™_ip4ā€™/ā€™_ip6ā€™. The IPv4 address
+              set  of  a Port_Group with a name of port_group1 can be referred
+              to as $port_group1_ip4, and the IPv6 address  set  of  the  same
+              Port_Group can be referred to as $port_group1_ip6
+
+              Miscellaneous
+
+              Comparisons  may  name  the  symbol  or the constant first, e.g.
+              tcp.src == 80 and 80 == tcp.src are both acceptable.
+
+              Tests for a range may be expressed using a syntax like  1024  =
+              tcp.src  =  49151,  which  is  equivalent to 1024 = tcp.src &&&&
+              tcp.src = 49151.
+
+              For a one-bit field or predicate,  a  mention  of  its  name  is
+              equivalent  to  symobl  == 1, e.g. vlan.present is equivalent to
+              vlan.present == 1. The same is true for one-bit subfields,  e.g.
+              vlan.tci[12].  There  is no technical limitation to implementing
+              the same for ordinal fields of all widths, but  the  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  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 || 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;=
+
+              ā€¢      !
+
+              ā€¢      &&&&   ||
+
+              Comments may be introduced by //, which extends to the next new-
+              line. Comments within a line may be bracketed by /* and */. Mulā€
+              tiline comments are not supported.
+
+              Symbols
+
+              Most  of  the  symbols  below have integer type. Only inport and
+              outport have string type. inport names a logical port. Thus, its
+              value is a logical_port name from the Port_Binding  table.  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:
+              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
+
+              ā€¢      xxreg0 xxreg1
+
+              ā€¢      inport outport
+
+              ā€¢      flags.loopback
+
+              ā€¢      pkt.mark
+
+              ā€¢      eth.src eth.dst eth.type
+
+              ā€¢      vlan.tci vlan.vid vlan.pcp vlan.present
+
+              ā€¢      ip.proto ip.dscp ip.ecn ip.ttl ip.frag
+
+              ā€¢      ip4.src ip4.dst
+
+              ā€¢      ip6.src ip6.dst ip6.label
+
+              ā€¢      arp.op arp.spa arp.tpa arp.sha arp.tha
+
+              ā€¢      rarp.op rarp.spa rarp.tpa rarp.sha rarp.tha
+
+              ā€¢      tcp.src tcp.dst tcp.flags
+
+              ā€¢      udp.src udp.dst
+
+              ā€¢      sctp.src sctp.dst
+
+              ā€¢      icmp4.type icmp4.code
+
+              ā€¢      icmp6.type icmp6.code
+
+              ā€¢      nd.target nd.sll nd.tll
+
+              ā€¢      ct_mark ct_label
+
+              ā€¢      ct_state,  which  has  several  Boolean  subfields.   The
+                     ct_next action initializes the following subfields:
+
+                     ā€¢      ct.trk:  Always set to true by ct_next to indicate
+                            that connection  tracking  has  taken  place.  All
+                            other ct subfields have ct.trk as a prerequisite.
+
+                     ā€¢      ct.new: True for a new flow
+
+                     ā€¢      ct.est: True for an established flow
+
+                     ā€¢      ct.rel: True for a related flow
+
+                     ā€¢      ct.rpl: True for a reply flow
+
+                     ā€¢      ct.inv: True for a connection entry in a bad state
+
+                     The  ct_dnat,  ct_snat,  and ct_lb actions initialize the
+                     following subfields:
+
+                     ā€¢      ct.dnat: True for a packet  whose  destination  IP
+                            address has been changed.
+
+                     ā€¢      ct.snat: True for a packet whose source IP address
+                            has been changed.
+
+              The following predicates are supported:
+
+              ā€¢      eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff
+
+              ā€¢      eth.mcast expands to eth.dst[40]
+
+              ā€¢      vlan.present expands to vlan.tci[12]
+
+              ā€¢      ip4 expands to eth.type == 0x800
+
+              ā€¢      ip4.src_mcast expands to ip4.src[28..31] == 0xe
+
+              ā€¢      ip4.mcast expands to ip4.dst[28..31] == 0xe
+
+              ā€¢      ip6 expands to eth.type == 0x86dd
+
+              ā€¢      ip expands to ip4 || ip6
+
+              ā€¢      icmp4 expands to ip4 &&&& ip.proto == 1
+
+              ā€¢      icmp6 expands to ip6 &&&& ip.proto == 58
+
+              ā€¢      icmp expands to icmp4 || icmp6
+
+              ā€¢      ip.is_frag expands to ip.frag[0]
+
+              ā€¢      ip.later_frag expands to ip.frag[1]
+
+              ā€¢      ip.first_frag expands to ip.is_frag &&&& !ip.later_frag
+
+              ā€¢      arp expands to eth.type == 0x806
+
+              ā€¢      rarp expands to eth.type == 0x8035
+
+              ā€¢      nd expands to icmp6.type == {135, 136} &&&& icmp6.code == 0
+                     &&&& ip.ttl == 255
+
+              ā€¢      nd_ns  expands to icmp6.type == 135 &&&& icmp6.code == 0 &&&&
+                     ip.ttl == 255
+
+              ā€¢      nd_na expands to icmp6.type == 136 &&&& icmp6.code == 0  &&&&
+                     ip.ttl == 255
+
+              ā€¢      nd_rs  expands to icmp6.type == 133 &&&& icmp6.code == 0 &&&&
+                     ip.ttl == 255
+
+              ā€¢      nd_ra expands to icmp6.type == 134 &&&& icmp6.code == 0  &&&&
+                     ip.ttl == 255
+
+              ā€¢      tcp expands to ip.proto == 6
+
+              ā€¢      udp expands to ip.proto == 17
+
+              ā€¢      sctp expands to ip.proto == 132
+
+       actions: string
+              Logical  datapath  actions, 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
+              matched packets to be dropped. Otherwise, the column should conā€
+              tain a sequence of actions, each terminated by a semicolon.
+
+              The following actions are defined:
+
+              output;
+                     In the ingress pipeline, this action executes the  egress
+                     pipeline  as  a  subroutine.  If  outport names a logical
+                     port, the egress pipeline executes once; if it is a  mulā€
+                     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
+                     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
+                     behavior, e.g. to send an ARP reply to an ARP request; to
+                     do so, use flags.loopback = 1  to  allow  the  packet  to
+                     "hair-pin" back to the input port.
+
+              next;
+              next(table);
+              next(pipeline=pipeline, table=table);
+                   Executes  the given logical datapath table in pipeline as a
+                   subroutine. The default table is  just  after  the  current
+                   one. If pipeline is specified, it may be ingress or egress;
+                   the  default  pipeline  is the one currently executing. 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
+                   vlan.pcp[2] = 1; or vlan.pcp = 4/4; to set the most signifā€
+                   icant bit of the VLAN PCP.
+
+                   Assigning  to  a  field  with prerequisites implicitly adds
+                   those prerequisites to match; thus,  for  example,  a  flow
+                   that  sets tcp.dst applies only to TCP flows, regardless of
+                   whether its match mentions any TCP field.
+
+                   Not all fields are modifiable (e.g. eth.type  and  ip.proto
+                   are  read-only),  and not all modifiable fields may be parā€
+                   tially modified (e.g. ip.ttl must assigned as a whole). The
+                   outport field is modifiable in the ingress pipeline but not
+                   in the egress pipeline.
+
+              ovn_field = constant;
+                   Sets OVN field ovn_field to constant value constant.
+
+                   OVN supports setting the values of certain fields which are
+                   not yet supported in OpenFlow to set or modify them.
+
+                   Below are the supported OVN fields:
+
+                   ā€¢      icmp4.frag_mtu icmp6.frag_mtu
+
+                          This  field  sets  the  low-order  16  bits  of  the
+                          ICMP{4,6}  header field that is labelled "unused" in
+                          the ICMP specification as defined in  the  RFC  1191
+                          with the value specified in constant.
+
+                          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
+                   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,
+                   they must have the same width.
+
+                   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.
+
+              field1 ->gt;>gt; field2;
+                   Similar  to field1 = field2; except that the two values are
+                   exchanged instead of copied. Both field1  and  field2  must
+                   modifiable.
+
+              push(field);
+                   Push the value of field to the stack top.
+
+              pop(field);
+                   Pop  the stack top and store the value to field, which must
+                   be modifiable.
+
+              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
+                   cases, a higher-priority flow should match on ip.ttl == {0,
+                   1};.)
+
+                   Prerequisite: ip
+
+              ct_next;
+                   Apply  connection  tracking  to  the   flow,   initializing
+                   ct_state  for matching in later tables. Automatically moves
+                   on to the next table, as if followed by next.
+
+                   As a side effect, IP  fragments  will  be  reassembled  for
+                   matching. If a fragmented packet is output, then it will be
+                   sent  with  any overlapping fragments squashed. The 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
+                   in a flow for a router.
+
+                   It  is  possible  to  have actions follow ct_next, but they
+                   will not have access to any of its side-effects and is  not
+                   generally useful.
+
+              ct_commit { };
+              ct_commit { ct_mark=value[/mask]; };
+              ct_commit { ct_label=value[/mask]; };
+              ct_commit { ct_mark=value[/mask]; ct_label=value[/mask]; };
+                   Commit the flow to the connection tracking entry associated
+                   with   it   by   a   previous   call   to   ct_next.   When
+                   ct_mark=value[/mask] and/or ct_label=value[/mask] are  supā€
+                   plied,  ct_mark  and/or  ct_label will be set to the values
+                   indicated by value[/mask] on the connection tracking entry.
+                   ct_mark is a 32-bit field. ct_label is a 128-bit field. The
+                   value[/mask] should be specified in hex string if more than
+                   64bits are to be used. Registers and other named fields can
+                   be used for value. ct_mark  and  ct_label  may  be  sub-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.
+                   You  may  also  leave out next which will commit connection
+                   tracking state, and then drop the  packet.  This  could  be
+                   useful  for  setting ct_mark on a connection tracking entry
+                   before dropping a packet, for example.
+
+              ct_dnat;
+              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
+                   by the connection tracker.
+
+                   ct_dnat(IP) sends the  packet  through  the  DNAT  zone  to
+                   change  the destination IP address of the packet to the one
+                   provided inside the parentheses and commits the connection.
+                   The packet is then automatically sent to the next tables as
+                   if followed by next; action. The next tables will  see  the
+                   changes in the packet caused by the connection tracker.
+
+              ct_snat;
+              ct_snat(IP);
+                   ct_snat  sends  the  packet through the SNAT zone to unSNAT
+                   any packet that was SNATed in the opposite  direction.  The
+                   packet  is automatically sent to the next tables as if 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.
+                   The packet is then automatically sent to the next tables as
+                   if followed by next; action. The next tables will  see  the
+                   changes in the packet caused by the connection tracker.
+
+              ct_dnat_in_czone;
+              ct_dnat_in_czone(IP);
+                   ct_dnat_in_czone  sends  the  packet through the common NAT
+                   zone (used for both DNAT and SNAT) in  connection  tracking
+                   table  to unDNAT any packet that was DNATed in the opposite
+                   direction. The packet is then automatically sent to to  the
+                   next tables as if followed by next; action. The next tables
+                   will see the changes in the packet caused by the connection
+                   tracker.
+
+                   ct_dnat_in_czone(IP)  sends  the  packet through the common
+                   NAT zone to change the destination IP address of the packet
+                   to the one provided inside the parentheses and commits  the
+                   connection.  The  packet  is then automatically sent to the
+                   next tables as if followed by next; action. The next tables
+                   will see the changes in the packet caused by the connection
+                   tracker.
+
+              ct_snat_in_czone;
+              ct_snat_in_czone(IP);
+                   ct_snat_in_czone sends the packet through  the  common  NAT
+                   zone  to  unSNAT any packet that was SNATed in the opposite
+                   direction. The packet is automatically sent to the next 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
+                   next tables as if followed by next; action. The next tables
+                   will see the changes in the packet caused by the connection
+                   tracker.
+
+              ct_clear;
+                   Clears connection tracking state.
+
+              ct_commit_nat;
+                   Applies NAT and commits the connection to the CT. Automatiā€
+                   cally  moves  on to the next table, as if followed by next.
+                   This is very useful for connections  that  are  in  related
+                   state  for  already existing connections and allows the NAT
+                   to be applied to them as well.
+
+              clone { action; ... };
+                   Makes a copy of the packet  being  processed  and  executes
+                   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.
+
+              arp { action; ... };
+                   Temporarily  replaces the IPv4 packet being processed by an
+                   ARP packet and executes  each  nested  action  on  the  ARP
+                   packet.  Actions following the arp action, if any, apply to
+                   the original, unmodified packet.
+
+                   The ARP packet that this action operates on is  initialized
+                   based on the IPv4 packet being processed, as follows. These
+                   are  default  values  that the nested actions will probably
+                   want to change:
+
+                   ā€¢      eth.src unchanged
+
+                   ā€¢      eth.dst unchanged
+
+                   ā€¢      eth.type = 0x0806
+
+                   ā€¢      arp.op = 1 (ARP request)
+
+                   ā€¢      arp.sha copied from eth.src
+
+                   ā€¢      arp.spa copied from ip4.src
+
+                   ā€¢      arp.tha = 00:00:00:00:00:00
+
+                   ā€¢      arp.tpa copied from ip4.dst
+
+                   The ARP packet has the same VLAN header, if any, as the  IP
+                   packet it replaces.
+
+                   Prerequisite: ip4
+
+              get_arp(P, A);
+                   Parameters:  logical port string field P, 32-bit IP address
+                   field A.
+
+                   Looks up A in Pā€™s mac binding table. If an entry is  found,
+                   stores  its  Ethernet  address in eth.dst, otherwise stores
+                   00:00:00:00:00:00 in eth.dst.
+
+                   Example: get_arp(outport, ip4.dst);
+
+              put_arp(P, A, E);
+                   Parameters: logical port string field P, 32-bit IP  address
+                   field A, 48-bit Ethernet address field E.
+
+                   Adds  or updates the entry for IP address A in logical port
+                   Pā€™s mac binding table, setting its Ethernet address to E.
+
+                   Example: put_arp(inport, arp.spa, arp.sha);
+
+              R = lookup_arp(P, A, M);
+                   Parameters: logical port string field P, 32-bit IP  address
+                   field A, 48-bit MAC address field M.
+
+                   Result: stored to a 1-bit subfield R.
+
+                   Looks  up  A and M in Pā€™s mac binding table. If an entry is
+                   found, stores 1 in the 1-bit subfield R, else 0.
+
+                   Example: reg0[0] = lookup_arp(inport, arp.spa, arp.sha);
+
+              R = lookup_arp_ip(P, A);
+                   Parameters: logical port string field P, 32-bit IP  address
+                   field A.
+
+                   Result: stored to a 1-bit subfield R.
+
+                   Looks  up A in Pā€™s mac binding table. If an entry is found,
+                   stores 1 in the 1-bit subfield R, else 0.
+
+                   Example: reg0[0] = lookup_arp_ip(inport, arp.spa);
+
+              P = get_fdb(A);
+                   Parameters:48-bit MAC address field A.
+
+                   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);
+
+              put_fdb(P, A);
+                   Parameters: logical port string field P, 48-bit MAC address
+                   field A.
+
+                   Adds or updates the entry for Ethernet address A in fdb taā€
+                   ble, setting its logical port key to P.
+
+                   Example: put_fdb(inport, arp.spa);
+
+              R = lookup_fdb(P, A);
+                   Parameters: 48-bit MAC address field M, logical port string
+                   field P.
+
+                   Result: stored to a 1-bit subfield R.
+
+                   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);
+
+              nd_ns { action; ... };
+                   Temporarily  replaces the IPv6 packet being processed by an
+                   IPv6 Neighbor Solicitation packet and executes each  nested
+                   action  on  the IPv6 NS packet. Actions following the nd_ns
+                   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.
+                   These are default values that the nested actions will probā€
+                   ably want to change:
+
+                   ā€¢      eth.src unchanged
+
+                   ā€¢      eth.dst set to IPv6 multicast MAC address
+
+                   ā€¢      eth.type = 0x86dd
+
+                   ā€¢      ip6.src copied from ip6.src
+
+                   ā€¢      ip6.dst set to IPv6 Solicited-Node multicast address
+
+                   ā€¢      icmp6.type = 135 (Neighbor Solicitation)
+
+                   ā€¢      nd.target copied from ip6.dst
+
+                   The IPv6 NS packet has the same VLAN header, if any, as the
+                   IP packet it replaces.
+
+                   Prerequisite: ip6
+
+              nd_na { action; ... };
+                   Temporarily  replaces the IPv6 neighbor solicitation packet
+                   being processed 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
+                   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.type = 0x86dd
+
+                   ā€¢      ip6.dst copied from ip6.src
+
+                   ā€¢      ip6.src copied from nd.target
+
+                   ā€¢      icmp6.type = 136 (Neighbor Advertisement)
+
+                   ā€¢      nd.target unchanged
+
+                   ā€¢      nd.sll = 00:00:00:00:00:00
+
+                   ā€¢      nd.tll copied from eth.dst
+
+                   The ND packet has the same VLAN header, if any, as the IPv6
+                   packet it replaces.
+
+                   Prerequisite: nd_ns
+
+              nd_na_router { action; ... };
+                   Temporarily  replaces the IPv6 neighbor solicitation packet
+                   being processed 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
+                   want to change:
+
+                   ā€¢      eth.dst exchanged with eth.src
+
+                   ā€¢      eth.type = 0x86dd
+
+                   ā€¢      ip6.dst copied from ip6.src
+
+                   ā€¢      ip6.src copied from nd.target
+
+                   ā€¢      icmp6.type = 136 (Neighbor Advertisement)
+
+                   ā€¢      nd.target unchanged
+
+                   ā€¢      nd.sll = 00:00:00:00:00:00
+
+                   ā€¢      nd.tll copied from eth.dst
+
+                   The ND packet has the same VLAN header, if any, as the IPv6
+                   packet it replaces.
+
+                   Prerequisite: nd_ns
+
+              get_nd(P, A);
+                   Parameters:  logical  port string field P, 128-bit IPv6 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
+                   00:00:00:00:00:00 in eth.dst.
+
+                   Example: get_nd(outport, ip6.dst);
+
+              put_nd(P, A, E);
+                   Parameters: logical port string field P, 128-bit  IPv6  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
+                   E.
+
+                   Example: put_nd(inport, nd.target, nd.tll);
+
+              R = lookup_nd(P, A, M);
+                   Parameters: logical port string field P, 128-bit IP address
+                   field A, 48-bit MAC address field M.
+
+                   Result: stored to a 1-bit subfield R.
+
+                   Looks up A and M in Pā€™s mac binding table. If an  entry  is
+                   found, stores 1 in the 1-bit subfield R, else 0.
+
+                   Example: reg0[0] = lookup_nd(inport, ip6.src, eth.src);
+
+              R = lookup_nd_ip(P, A);
+                   Parameters: logical port string field P, 128-bit IP address
+                   field A.
+
+                   Result: stored to a 1-bit subfield R.
+
+                   Looks  up A in Pā€™s mac binding table. If an entry is found,
+                   stores 1 in the 1-bit subfield R, else 0.
+
+                   Example: reg0[0] = lookup_nd_ip(inport, ip6.src);
+
+              R = put_dhcp_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
+                   Parameters: one or more DHCP option/value pairs, which must
+                   include an offerip option (with code 0).
+
+                   Result: stored to a 1-bit subfield R.
+
+                   Valid only in the ingress pipeline.
+
+                   When this action  is  applied  to  a  DHCP  request  packet
+                   (DHCPDISCOVER or DHCPREQUEST), it changes the packet into a
+                   DHCP  reply  (DHCPOFFER or DHCPACK, respectively), replaces
+                   the options 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
+                   the packet unchanged and stores 0 in R.
+
+                   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,
+                   7.7.7.7});
+
+              R = put_dhcpv6_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
+                   Parameters: one or more DHCPv6 option/value pairs.
+
+                   Result: stored to a 1-bit subfield R.
+
+                   Valid only in the ingress pipeline.
+
+                   When this action is applied to a DHCPv6 request packet,  it
+                   changes  the  packet  into a DHCPv6 reply, replaces the 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 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,
+                   dns_server={ae70::1,ae70::2});
+
+              set_queue(queue_number);
+                   Parameters: Queue number queue_number, in the  range  0  to
+                   61440.
+
+                   This  is a logical equivalent of the OpenFlow set_queue 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);
+
+              ct_lb;
+              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  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_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ā€
+                   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
+                   state is scoped by the logical port when the action is used
+                   in  a  flow  for a logical switch, so overlapping addresses
+                   may be used. Connection tracking state  is  scoped  by  the
+                   logical  topology  when  the action is used in a flow for a
+                   router.
+
+              ct_lb_mark;
+              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
+                   purpose.
+
+              R = dns_lookup();
+                   Parameters: No parameters.
+
+                   Result: stored to a 1-bit subfield R.
+
+                   Valid only in the ingress pipeline.
+
+                   When this action is applied to a valid DNS request  (a  UDP
+                   packet  typically  directed to port 53), it attempts to 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
+                   this behavior with matches and actions in later tables.
+
+                   Example: reg0[3] = dns_lookup();
+
+                   Prerequisite: udp
+
+              R = put_nd_ra_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
+                   Parameters: The following IPv6 ND Router Advertisement  opā€
+                   tion/value pairs as defined in RFC 4861.
+
+                   ā€¢      addr_mode
+
+                          Mandatory parameter which specifies the address mode
+                          flag  to  be  set  in the RA flag options field. The
+                          value of this option is a string and  the  following
+                          values  can  be defined - "slaac", "dhcpv6_stateful"
+                          and "dhcpv6_stateless".
+
+                   ā€¢      slla
+
+                          Mandatory parameter which specifies  the  link-layer
+                          address  of  the interface from which the Router Adā€
+                          vertisement is sent.
+
+                   ā€¢      mtu
+
+                          Optional parameter which specifies the MTU.
+
+                   ā€¢      prefix
+
+                          Optional parameter which should be specified if  the
+                          addr_mode  is  "slaac"  or  "dhcpv6_stateless".  The
+                          value should be an IPv6 prefix which  will  be  used
+                          for  stateless  IPv6 address configuration. This opā€
+                          tion can be defined multiple times.
+
+                   Result: stored to a 1-bit subfield R.
+
+                   Valid only in the ingress pipeline.
+
+                   When this action is applied to an IPv6 Router  solicitation
+                   request  packet,  it changes the packet into an IPv6 Router
+                   Advertisement reply and adds the options specified  in  the
+                   parameters, and stores 1 in R.
+
+                   When  this action is applied to a non-IPv6 Router solicitaā€
+                   tion packet or an invalid IPv6 request packet ,  it  leaves
+                   the packet unchanged and stores 0 in R.
+
+                   Example: reg0[3] = put_nd_ra_opts(addr_mode = "slaac", slla
+                   = 00:00:00:00:10:02, prefix = aef0::/64, mtu = 1450);
+
+              set_meter(rate);
+              set_meter(rate, burst);
+                   Parameters:  rate  limit int field rate in kbps, burst rate
+                   limits int field burst in kbps.
+
+                   This action sets the rate limit for a flow.
+
+                   Example: set_meter(100, 1000);
+
+              R = check_pkt_larger(L)
+                   Parameters: packet length L to check for in bytes.
+
+                   Result: stored to a 1-bit subfield R.
+
+                   This   is   a   logical   equivalent   of   the    OpenFlow
+                   check_pkt_larger  action.  If the packet is larger than the
+                   length specified in L, it stores 1 in the subfield R.
+
+                   Example: reg0[6] = check_pkt_larger(1000);
+
+              log(key=value, ...);
+                     Causes ovn-controller to log the packet  on  the  chassis
+                     that processes it. Packet logging currently uses the same
+                     logging mechanism as other Open vSwitch and OVN messages,
+                     which  means  that  whether and where log messages appear
+                     depends on the local logging configuration  that  can  be
+                     configured with ovs-appctl, etc.
+
+                     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ā€
+                            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
+                            severity is not provided, the default is info.
+
+                     verdict=value
+                            The verdict for packets  matching  the  flow.  The
+                            value must be one of allow, deny, or reject.
+
+                     meter=string
+                            An  optional  rate-limiting meter to be applied to
+                            the logs. The string should reference a name entry
+                            from the Meter table. The only meter  action  that
+                            is appropriate is drop.
+
+              fwd_group(liveness=bool, childports=port, ...);
+                     Parameters:  optional liveness, either true or false, 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
+                     an OpenFlow group with one bucket for each child port. If
+                     liveness=true is specified, it also integrates the bucket
+                     selection  with BFD status on the tunnel interface correā€
+                     sponding to child port.
+
+                     Example: fwd_group(liveness=true, childports="p1", "p2");
+
+              icmp4 { action; ... };
+              icmp4_error { action; ... };
+                   Temporarily replaces the IPv4 packet being processed by  an
+                   ICMPv4 packet and executes each nested action on the ICMPv4
+                   packet.  Actions  following these actions, if any, apply to
+                   the original, unmodified packet.
+
+                   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.frag = 0 (not a fragment)
+
+                   ā€¢      ip.ttl = 255
+
+                   ā€¢      icmp4.type = 3 (destination unreachable)
+
+                   ā€¢      icmp4.code = 1 (host unreachable)
+
+                   icmp4_error  action  is  expected to be used to generate an
+                   ICMPv4 packet in  response  to  an  error  in  original  IP
+                   packet.  When  this  action generates the ICMPv4 packet, it
+                   also copies the original IP datagram following  the  ICMPv4
+                   header as per RFC 1122: 3.2.2.
+
+                   Prerequisite: ip4
+
+              icmp6 { action; ... };
+              icmp6_error { action; ... };
+                   Temporarily  replaces the IPv6 packet being processed by an
+                   ICMPv6 packet and executes each nested action on the ICMPv6
+                   packet. Actions following the icmp6 action, if  any,  apply
+                   to the original, unmodified packet.
+
+                   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.ttl = 255
+
+                   ā€¢      icmp6.type = 1 (destination unreachable)
+
+                   ā€¢      icmp6.code = 1 (administratively prohibited)
+
+                   icmp6_error action is expected to be used  to  generate  an
+                   ICMPv6  packet  in  response  to  an error in original IPv6
+                   packet.
+
+                   Prerequisite: ip6
+
+              tcp_reset;
+                   This action transforms the current TCP packet according  to
+                   the following pseudocode:
+
+                   if (tcp.ack) {
+                           tcp.seq = tcp.ack;
+                   } else {
+                           tcp.ack = tcp.seq + length(tcp.payload);
+                           tcp.seq = 0;
+                   }
+                   tcp.flags = RST;
+
+                   Then,  the  action  drops all TCP options and payload data,
+                   and updates the TCP checksum. IP ttl is set to 255.
+
+                   Prerequisite: tcp
+
+              reject { action; ... };
+                   If the 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
+                   this action implicitly does that.
+
+              trigger_event;
+                   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 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
+
+              igmp;
+                   This  action  sends the packet to ovn-controller for multiā€
+                   cast snooping.
+
+                   Prerequisite: igmp
+
+              bind_vport(V, P);
+                   Parameters: logical port string field V  of  type  virtual,
+                   logical port string field P.
+
+                   Binds  the virtual logical port V and sets the chassis colā€
+                   umn and virtual_parent  of  the  table  Port_Binding.  virā€ā€
+                   tual_parent is set to P.
+
+              handle_svc_check(P);
+                   Parameters: logical port string field P.
+
+                   Handles  the service monitor reply received from the VIF of
+                   the logical port P. ovn-controller periodically  sends  out
+                   the  service monitor packets for the services configured in
+                   the Service_Monitor table and this action updates the  staā€
+                   tus of those services.
+
+                   Example: handle_svc_check(inport);
+
+              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  reā€
+                   ceived from the delegation server
+
+              R = select(N1[=W1], N2[=W2], ...);
+                   Parameters: Integer N1, N2..., with optional weight W1, W2,
+                   ...
+
+                   Result: stored to a logical field or subfield R.
+
+                   Select  from  a list of integers N1, N2..., each within the
+                   range 0 ~ 65535, and store the selected one in the field R.
+                   There must be 2 or more integers listed, each with  an  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 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  maā€
+                   chine
+
+              R = chk_lb_hairpin();
+                   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
+                   set to 1.
+
+              R = chk_lb_hairpin_reply();
+                   This action checks if the  packet  under  consideration  is
+                   from  one  of the backend IP of a load balancer VIP and the
+                   destination IP is the load balancer VIP. If it is so,  then
+                   the 1-bit destination register R is set to 1.
+
+              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ā€
+                   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
+                   this action to advance the packet to the next stage.
+
+              R = check_in_port_sec();
+                   This action checks if the packet under consideration passes
+                   the  inport  port  security checks. If the packet fails the
+                   port security checks, then 1 is stored in  the  destination
+                   register  R.  Else 0 is stored. The port security values to
+                   check are retrieved from the the inport logical port.
+
+                   This action should be used in the  ingress  logical  switch
+                   pipeline.
+
+                   Example: reg8[0..7] = check_in_port_sec();
+
+              R = check_out_port_sec();
+                   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
+                   check are retrieved from the the outport logical port.
+
+                   This action should be used in  the  egress  logical  switch
+                   pipeline.
+
+                   Example: reg8[0..7] = check_out_port_sec();
+
+              commit_ecmp_nh(ipv6);
+                   Parameters: IPv4/IPv6 traffic.
+
+                   This  action  translates to an openflow "learn" action that
+                   inserts two new flows in tables 76 and 77.
+
+                   ā€¢      Match on the the 5-tuple and the  expected  next-hop
+                          mac  address  in  table  76: nw_src=ip0, nw_dst=ip1,
+                          ip_proto,tp_src=l4_port0,
+                          tp_dst=l4_port1,dl_src=ethaddr and set reg9[5].
+
+                   ā€¢      Match  on  the  5-tuple  in  table  77:  nw_src=ip1,
+                          nw_dst=ip0,        ip_proto,        tp_src=l4_port1,
+                          tp_dst=l4_port0 and set reg9[5] to 1
+
+                   This action is applied if the packet arrives via ECMP route
+                   or if it is routed via an ECMP route
+
+              R = check_ecmp_nh_mac();
+                   This  action  checks  if  the  packet  under  consideration
+                   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
+                   1-bit destination register R is set to 1.
+
+                   commit_lb_aff(vip, backend,  proto,  timeout);  Parameters:
+                   load-balancer  virtual  ip:port  vip, load-balancer backend
+                   ip:port backend,  load-balancer  protocol  proto,  affinity
+                   timeout timeout.
+
+                   This  action  translates to an openflow "learn" action that
+                   inserts a new flow in table 78.
+
+                   ā€¢      Match on the 4-tuple in table 78: nw_src=ip  client,
+                          nw_dst=vip  ip,  ip_proto,  tp_dst=vip  port and set
+                          reg9[6] to 1, reg4 and reg8 to backend ip  and  port
+                          respectively.  For  IPv6  register xxreg1 is used to
+                          store the backend ip.
+
+                   This action is applied for new connections  received  by  a
+                   specific load-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
+                   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
+                   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
+                   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
+                          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ā€ā€
+                          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. 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
+                          be used instead.
+
+       tags: map of string-string pairs
+              Key-value pairs that provide additional information to help ovn-
+              controller  processing the logical flow. Below are the tags used
+              by ovn-controller.
+
+              in_out_port
+                     In the logical flowā€™s "match" column, if a logical port P
+                     is compared with "inport" and the logical flow  is  on  a
+                     logical switch ingress pipeline, or if P is compared with
+                     "outport"  and  the  logical  flow is on a logical switch
+                     egress pipeline, and  the  expression  is  combined  with
+                     other  expressions  (if  any) using the operator &&, then
+                     the port P should be added as the value in this  tag.  If
+                     there  are  multiple logical ports meeting this criteria,
+                     one of them can be added. ovn-controller uses this inforā€
+                     mation to skip parsing flows that are not needed  on  the
+                     chassis.  Failing  to add the tag will affect efficiency,
+                     while adding wrong value will affect correctness.
+
+       controller_meter: optional string
+              The name of the meter in table Meter to be used for all  packets
+              that the logical flow might send to ovn-controller.
+
+       external_ids : stage-name: optional string
+              Human-readable name for this flowā€™s stage in the pipeline.
+
+       external_ids : stage-hint: optional string, containing an uuid
+              UUID of a OVN_Northbound record that caused this logical flow to
+              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
+              the pipeline.
+
+     Common Columns:
+
+       The  overall purpose of these columns is described under Common Columns
+       at the beginning of this document.
+
+       external_ids: map of string-string pairs
+Logical_DP_Group TABLE
+       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ā€ā€
+                                     ings
+
+   Details:
+       datapaths: set of weak reference to Datapath_Bindings
+              List of Datapath_Binding entries.
+
+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
+       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
+       column.
+
+   Summary:
+       datapath                      Datapath_Binding
+       tunnel_key                    integer, in range 32,768 to 65,535
+       name                          string
+       ports                         set of weak reference to Port_Bindings
+
+   Details:
+       datapath: Datapath_Binding
+              The logical datapath in which the multicast group resides.
+
+       tunnel_key: integer, in range 32,768 to 65,535
+              The  value  used to designate this logical egress port in tunnel
+              encapsulations. An index forces the key to be unique within  the
+              datapath.  The unusual range ensures that multicast group IDs do
+              not overlap with logical port IDs.
+
+       name: string
+              The logical multicast groupā€™s name. An index forces the name  to
+              be  unique  within  the  datapath.  Logical flows in the ingress
+              pipeline may output to the group just as for individual  logical
+              ports, by assigning the groupā€™s name to outport and executing an
+              output action.
+
+              Multicast  group  names  and  logical  port names share a single
+              namespace and thus should not overlap (but the  database  schema
+              cannot enforce this). To try to avoid conflicts, ovn-northd uses
+              names that begin with _MC_.
+
+       ports: set of weak reference to Port_Bindings
+              The  logical ports included in the multicast group. All of these
+              ports must be in the datapath logical datapath (but the database
+              schema cannot enforce this).
+
+Mirror TABLE
+       Each row in this table represents a mirror that can be  used  for  port
+       mirroring.  These  mirrors are referenced by the mirror_rules column in
+       the Port_Binding table.
+
+   Summary:
+       name                          string (must be unique within table)
+       filter                        string,  one  of  both,  from-lport,   or
+                                     to-lport
+       sink                          string
+       type                          string, one of erspan, gre, or local
+       index                         integer
+       external_ids                  map of string-string pairs
+
+   Details:
+       name: string (must be unique within table)
+              Represents the name of the mirror.
+
+       filter: string, one of both, from-lport, or to-lport
+              The  value  of  this  field represents selection criteria of the
+              mirror. to-lport mirrors the packets coming into  logical  port.
+              from-lport  mirrors  the packets going out of logical port. both
+              mirrors for both directions.
+
+       sink: string
+              The value of this field represents the destination/sink  of  the
+              mirror.  If  the  type is gre or erspan, the value indicates the
+              tunnel remote IP (either IPv4 or IPv6). For  a  type  of  local,
+              this  field  defines  a  local  interface on the OVS integration
+              bridge to be used as the mirror destination. The interface  must
+              possess external-ids:mirror-id that matches this string.
+
+       type: string, one of erspan, gre, 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. 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
+       rate-limiting.
+
+   Summary:
+       name                          string (must be unique within table)
+       unit                          string, either kbps or pktps
+       bands                         set of 1 or more Meter_Bands
+
+   Details:
+       name: string (must be unique within table)
+              A name for this meter.
+
+              Names that begin with "__" (two underscores)  are  reserved  for
+              OVN internal use and should not be added manually.
+
+       unit: string, either kbps or pktps
+              The  unit for rate and burst_rate parameters in the bands entry.
+              kbps specifies kilobits per second, and pktps specifies  packets
+              per second.
+
+       bands: set of 1 or more Meter_Bands
+              The bands associated with this meter. Each band specifies a rate
+              above  which  the band is to take the action action. If multiple
+              bandsā€™ rates are exceeded, then the band with the  highest  rate
+              among the exceeded bands is selected.
+
+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
+       referenced by the bands column in the Meter table.
+
+   Summary:
+       action                        string, must be drop
+       rate                          integer, in range 1 to 4,294,967,295
+       burst_size                    integer, in range 0 to 4,294,967,295
+
+   Details:
+       action: string, must be drop
+              The action to execute when this band matches. The only supported
+              action is drop.
+
+       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ā€
+              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
+              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ā€
+       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 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
+                                     be unique within table)
+       load_balancers                set of uuids
+       OVN_Northbound Relationship:
+         external_ids : logical-switch
+                                     optional string, containing an uuid
+         external_ids : logical-router
+                                     optional string, containing an uuid
+         external_ids : interconn-ts
+                                     optional string
+         Naming:
+            external_ids : name      optional string
+            external_ids : name2     optional string
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       tunnel_key: integer, in range 1 to 16,777,215 (must be unique within
+       table)
+              The tunnel key value 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ā€
+              tion.
+
+       load_balancers: set of uuids
+              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ā€
+       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ā€ā€
+              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ā€ā€
+              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
+              stores in this key the value of the same interconn-ts key of the
+              external_ids column of the corresponding Logical_Switch  row  in
+              the OVN_Northbound database.
+
+     Naming:
+
+       ovn-northd  copies  these  from  the  name fields in the OVN_Northbound
+       database, either from name and external_ids:neutron:router_name in  the
+       Logical_Router table or from name and external_ids:neutron:network_name
+       in the Logical_Switch table.
+
+       external_ids : name: optional string
+              A name for the logical datapath.
+
+       external_ids : name2: optional string
+              Another name for the logical datapath.
+
+     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
+       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,
+       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ā€ā€
+       tionGuide.rst. (The exceptions are for Port_Binding records  with  type
+       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
+       whose type is virtual.
+
+       When a chassis shuts down gracefully, it should clean  up  the  chassis
+       column  that it previously had populated. (This is not critical because
+       resources hosted on the chassis are equally unreachable  regardless  of
+       whether  their rows are present.) To handle the case where a VM is shut
+       down abruptly on one chassis, then brought up again on a different one,
+       ovn-controller/ovn-controller-vtep must overwrite  the  chassis  column
+       with new information.
+
+   Summary:
+       Core Features:
+         datapath                    Datapath_Binding
+         logical_port                string (must be unique within table)
+         encap                       optional weak reference to Encap
+         additional_encap            set of weak reference to Encaps
+         chassis                     optional weak reference to Chassis
+         additional_chassis          set of weak reference to Chassis
+         gateway_chassis             set of Gateway_Chassises
+         ha_chassis_group            optional HA_Chassis_Group
+         up                          optional boolean
+         tunnel_key                  integer, in range 1 to 32,767
+         mac                         set of strings
+         port_security               set of strings
+         type                        string
+         requested_chassis           optional weak reference to Chassis
+         requested_additional_chassis
+                                     set of weak reference to Chassis
+       mirror_rules                  set of weak reference to Mirrors
+       Patch Options:
+         options : peer              optional string
+         nat_addresses               set of strings
+       L3 Gateway Options:
+         options : peer              optional string
+         options : l3gateway-chassis
+                                     optional string
+         nat_addresses               set of strings
+       Localnet Options:
+         options : network_name      optional string
+         tag                         optional integer, in range 1 to 4,095
+       L2 Gateway Options:
+         options : network_name      optional string
+         options : l2gateway-chassis
+                                     optional string
+         tag                         optional integer, in range 1 to 4,095
+       VTEP Options:
+         options : vtep-physical-switch
+                                     optional string
+         options : vtep-logical-switch
+                                     optional string
+       VMI (or VIF) Options:
+         options : requested-chassis
+                                     optional string
+         options : activation-strategy
+                                     optional string
+         options : additional-chassis-activated
+                                     optional string
+         options : iface-id-ver      optional string
+         options : qos_min_rate      optional string
+         options : qos_max_rate      optional string
+         options : qos_burst         optional string
+         options : qos_physical_network
+                                     optional string
+         options : qdisc_queue_id    optional  string,  containing an integer,
+                                     in range 1 to 61,440
+       Distributed Gateway Port Options:
+         options : chassis-redirect-port
+                                     optional string
+       Chassis Redirect Options:
+         options : distributed-port  optional string
+         options : redirect-type     optional string
+         options : always-redirect   optional string
+       Nested Containers:
+         parent_port                 optional string
+         tag                         optional integer, in range 1 to 4,095
+       Virtual ports:
+         virtual_parent              optional string
+       Naming:
+         external_ids : name         optional string
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+     Core Features:
+
+       datapath: Datapath_Binding
+              The logical datapath to which the logical port belongs.
+
+       logical_port: string (must be unique within table)
+              A logical port. For a logical switch port, this  is  taken  from
+              name in the OVN_Northbound databaseā€™s Logical_Switch_Port table.
+              For  a  logical  router  port,  this  is  taken from name in the
+              OVN_Northbound databaseā€™s Logical_Router_port table. (This means
+              that logical switch ports and router port names must  not  share
+              names in an OVN deployment.) OVN does not prescribe a particular
+              format for the logical port ID.
+
+       encap: optional weak reference to Encap
+              Points to preferred encapsulation configuration to transmit logā€
+              ical  dataplane  packets to this chassis. The entry is reference
+              to a Encap record.
+
+       additional_encap: set of weak reference to Encaps
+              Points to preferred encapsulation configuration to transmit logā€
+              ical dataplane packets to this additional chassis. The entry  is
+              reference to a Encap record. See also additional_chassis.
+
+       chassis: optional weak reference to Chassis
+              The meaning of this column depends on the value of the type colā€
+              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
+                     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
+                     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
+                     network.
+
+              localport
+                     Always  empty. A localport port is present on every chasā€
+                     sis.
+
+              l3gateway
+                     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.
+
+              l2gateway
+                     The physical location of this L2 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:l2gateway-chassis column in this table.
+
+       additional_chassis: set of weak reference to Chassis
+              The  meaning  of this column is the same as for the chassis. The
+              column is used to track an additional physical location  of  the
+              logical port. Used with regular (empty type) port bindings.
+
+       gateway_chassis: set of Gateway_Chassises
+              A list of Gateway_Chassis.
+
+              This  should  only be populated for ports with type set to 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ā€ā€
+              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ā€ā€
+              troller.
+
+       tunnel_key: integer, in range 1 to 32,767
+              A number that represents the logical port in the key  (e.g.  STT
+              key or Geneve TLV) field carried within tunnel protocol packets.
+
+              The tunnel ID must be unique within the scope of a logical dataā€
+              path.
+
+       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ā€ā€
+              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
+              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ā€ā€
+              cal_Switch_Port table in the Northbound database. It follows the
+              same format as that column.
+
+       type: string
+              A type for this logical port. Logical ports can be used to model
+              other types of connectivity into an OVN logical switch. The folā€
+              lowing types are defined:
+
+              (empty string)
+                     VM (or VIF) interface.
+
+              patch  One  of  a pair of logical ports that act as if connected
+                     by a patch cable. Useful for connecting two logical dataā€
+                     paths, e.g. to connect a  logical  router  to  a  logical
+                     switch or to another logical router.
+
+              l3gateway
+                     One  of  a pair of logical ports that act as if connected
+                     by a patch cable across multiple chassis. Useful for conā€
+                     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
+                     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
+                     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
+                     hypervisor.
+
+              l2gateway
+                     An L2 connection to a physical network. The chassis  this
+                     Port_Binding  is  bound to will serve as an L2 gateway to
+                     the network named by options:network_name.
+
+              vtep   A port to a logical switch on a VTEP gateway chassis.  In
+                     order  to  get  this port correctly recognized by the OVN
+                     controller,  the  options:vtep-physical-switch  and   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
+                     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 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 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: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ā€ā€
+              ror table.
+
+     Patch Options:
+
+       These options apply to logical ports with type of patch.
+
+       options : peer: optional string
+              The  logical_port  in the Port_Binding record for the other side
+              of the patch. The named logical_port  must  specify  this  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  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,
+              from the chassis where lport resides. Example: 80:fa:5b:06:72:b7
+              158.36.44.22   158.36.44.24   is_chassis_resident("foo1").  This
+              would result in generation of gratuitous ARPs for  IP  addresses
+              158.36.44.22   and   158.36.44.24   with   a   MAC   address  of
+              80:fa:5b:06:72:b7 from the chassis where the logical port "foo1"
+              resides.
+
+     L3 Gateway Options:
+
+       These options apply to logical ports with type of l3gateway.
+
+       options : peer: optional string
+              The logical_port in the Port_Binding record for the  other  side
+              of  the  ā€™l3gatewayā€™  port.  The named logical_port must specify
+              this logical_port in its own  peer  option.  That  is,  the  two
+              ā€™l3gatewayā€™  logical  ports  must have reversed logical_port and
+              peer values.
+
+       options : l3gateway-chassis: optional string
+              The chassis in which the port resides.
+
+       nat_addresses: set of strings
+              MAC address of the l3gateway port followed by a list of SNAT and
+              DNAT external IP addresses. This is used to send gratuitous ARPs
+              for SNAT and DNAT external IP addresses via  localnet.  Example:
+              80:fa:5b:06:72:b7  158.36.44.22  158.36.44.24. This would result
+              in generation of gratuitous ARPs for IP  addresses  158.36.44.22
+              and  158.36.44.24  with a MAC address of 80:fa:5b:06:72:b7. This
+              is used in OVS version 2.8 and later versions.
+
+     Localnet Options:
+
+       These options apply to logical ports with type of localnet.
+
+       options : network_name: optional string
+              Required.   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
+              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
+              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
+              traffic.
+
+     L2 Gateway Options:
+
+       These options apply to logical ports with type of l2gateway.
+
+       options : network_name: optional string
+              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
+              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 l2gateway port attached, the chassis
+              that  the  l2gateway port is bound to must have a bridge mapping
+              configured to reach the network identified by network_name.
+
+       options : l2gateway-chassis: optional string
+              Required. The chassis in which the port resides.
+
+       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 inā€
+              coming traffic and is also added to outgoing traffic.
+
+     VTEP Options:
+
+       These options apply to logical ports with type of vtep.
+
+       options : vtep-physical-switch: optional string
+              Required. The name of the VTEP gateway.
+
+       options : vtep-logical-switch: optional string
+              Required. A logical switch name connected by the  VTEP  gateway.
+              Must be set when type is vtep.
+
+     VMI (or VIF) Options:
+
+       These options apply to logical ports with type having (empty string)
+
+       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
+              more than one chassis.
+
+              If set to a comma separated list, the first entry identifies the
+              main  chassis  and  the  rest are one or more additional chassis
+              that are allowed to bind the same port.
+
+              When multiple chassis are set for  the  port,  and  the  logical
+              switch  is  connected  to an external network through a localnet
+              port, tunneling is enforced for the port to  guarantee  delivery
+              of  packets  directed to the port to all its locations. This has
+              MTU implications because the network  used  for  tunneling  must
+              have MTU larger than localnet for stable connectivity.
+
+       options : activation-strategy: optional string
+              If  used  with multiple chassis set in requested-chassis, speciā€
+              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
+              useful in live migration scenarios for virtual machines.
+
+       options : additional-chassis-activated: optional string
+              When  activation-strategy is set, this option indicates that the
+              port was activated using the strategy specified.
+
+       options : iface-id-ver: optional string
+              If set, this port will be bound by ovn-controller only  if  this
+              same  key  and value is configured in the external_ids column in
+              the Open_vSwitch databaseā€™s Interface table.
+
+       options : qos_min_rate: optional string
+              If set, indicates the minimum guaranteed rate available for data
+              sent from this interface, in bit/s.
+
+       options : qos_max_rate: optional string
+              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 : 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.
+
+     Distributed Gateway Port Options:
+
+       These options apply to the distributed parent ports  of  logical  ports
+       with type of chasssisredirect.
+
+       options : chassis-redirect-port: optional string
+              The  name of the chassis redirect port derived from this port if
+              this port is a distributed parent of a chassis redirect port.
+
+     Chassis Redirect Options:
+
+       These options apply to logical ports with type of chassisredirect.
+
+       options : distributed-port: optional string
+              The name of the distributed port for which this  chassisredirect
+              port represents a particular instance.
+
+       options : redirect-type: optional string
+              The  value  is  copied from the column options in the OVN_Northā€
+              bound databaseā€™s Logical_Router_Port table for  the  distributed
+              parent of this port.
+
+       options : always-redirect: optional string
+              A  boolean  option that is set to true if the distributed parent
+              of this chassis redirect port does not need distributed processā€
+              ing.
+
+     Nested Containers:
+
+       These columns support containers nested within a VM. Specifically, they
+       are used when type is empty and logical_port identifies  the  interface
+       of  a  container  spawned inside a VM. They are empty for containers or
+       VMs that run directly on a hypervisor.
+
+       parent_port: optional string
+              This is taken from parent_name in the OVN_Northbound  databaseā€™s
+              Logical_Switch_Port table.
+
+       tag: optional integer, in range 1 to 4,095
+              Identifies  the  VLAN tag in the network traffic associated with
+              that containerā€™s network interface.
+
+              This column is used for a different purpose when type is  localā€ā€
+              net  (see  Localnet Options, above) or l2gateway (see L2 Gateway
+              Options, above).
+
+     Virtual ports:
+
+       virtual_parent: optional string
+              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ā€
+              cutes this action with its chassis id.
+
+              ovn-controller sets this column only if the type is "virtual".
+
+     Naming:
+
+       external_ids : name: optional string
+              For  a  logical  switch port, ovn-northd copies this from 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
+              this key.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+              The ovn-northd program populates this column  with  all  entries
+              into the external_ids column of the Logical_Switch_Port and 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
+       machines are usually populated statically into the Port_Binding table.
+
+       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
+       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
+                  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.
+                  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 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 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
+                  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
+                  the MAC_Binding table.
+
+              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  diā€
+                  rectly to the bound Ethernet address.
+
+   Summary:
+       logical_port                  string
+       ip                            string
+       mac                           string
+       timestamp                     integer
+       datapath                      Datapath_Binding
+
+   Details:
+       logical_port: string
+              The logical port on which the binding was discovered.
+
+       ip: string
+              The bound IP address.
+
+       mac: string
+              The Ethernet address to which the IP is bound.
+
+       timestamp: integer
+              The timestamp in msec when the MAC binding was added or updated.
+              Records that existed before this column will have 0.
+
+       datapath: Datapath_Binding
+              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
+       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,
+                                     ipv4, static_routes, str, uint16, uint32,
+                                     or uint8
+
+   Details:
+       name: string
+              Name of the DHCP option.
+
+              Example. name="router"
+
+       code: integer, in range 0 to 254
+              DHCP option code for the DHCP option as defined in the RFC 2132.
+
+              Example. code=3
+
+       type: string, one of bool, domains, host_id, ipv4, static_routes, str,
+       uint16, uint32, or uint8
+              Data type of the DHCP option code.
+
+              value: bool
+                     This  indicates  that  the  value of the DHCP option is a
+                     bool.
+
+                     Example.       "name=ip_forward_enable",       "code=19",
+                     "type=bool".
+
+                     put_dhcp_opts(..., ip_forward_enable = 1,...)
+
+              value: uint8
+                     This  indicates  that  the value of the DHCP option is an
+                     unsigned int8 (8 bits)
+
+                     Example. "name=default_ttl", "code=23", "type=uint8".
+
+                     put_dhcp_opts(..., default_ttl = 50,...)
+
+              value: uint16
+                     This indicates that the value of the DHCP  option  is  an
+                     unsigned int16 (16 bits).
+
+                     Example. "name=mtu", "code=26", "type=uint16".
+
+                     put_dhcp_opts(..., mtu = 1450,...)
+
+              value: uint32
+                     This  indicates  that  the value of the DHCP option is an
+                     unsigned int32 (32 bits).
+
+                     Example. "name=lease_time", "code=51", "type=uint32".
+
+                     put_dhcp_opts(..., lease_time = 86400,...)
+
+              value: ipv4
+                     This indicates that the value of the DHCP  option  is  an
+                     IPv4 address or addresses.
+
+                     Example. "name=router", "code=3", "type=ipv4".
+
+                     put_dhcp_opts(..., router = 10.0.0.1,...)
+
+                     Example. "name=dns_server", "code=6", "type=ipv4".
+
+                     put_dhcp_opts(..., dns_server = {8.8.8.8 7.7.7.7},...)
+
+              value: static_routes
+                     This indicates that the value of the DHCP option contains
+                     a pair of IPv4 route and next hop addresses.
+
+                     Example.    "name=classless_static_route",    "code=121",
+                     "type=static_routes".
+
+                     put_dhcp_opts(...,        classless_static_route        =
+                     {30.0.0.0/24,10.0.0.4,0.0.0.0/0,10.0.0.1}...)
+
+              value: str
+                     This  indicates  that  the  value of the DHCP option is a
+                     string.
+
+                     Example. "name=host_name", "code=12", "type=str".
+
+              value: host_id
+                     This indicates that the value of the  DHCP  option  is  a
+                     host_id. It can either be a host_name or an IP address.
+
+                     Example. "name=tftp_server", "code=66", "type=host_id".
+
+              value: domains
+                     This indicates that the value of the DHCP option is a 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 deā€
+       fined here.
+
+   Summary:
+       name                          string
+       code                          integer, in range 0 to 254
+       type                          string, one of ipv6, mac, or str
+
+   Details:
+       name: string
+              Name of the DHCPv6 option.
+
+              Example. name="ia_addr"
+
+       code: integer, in range 0 to 254
+              DHCPv6  option  code for the DHCPv6 option as defined in the apā€
+              propriate RFC.
+
+              Example. code=3
+
+       type: string, one of ipv6, mac, or str
+              Data type of the DHCPv6 option code.
+
+              value: ipv6
+                     This indicates that the value of the DHCPv6 option is  an
+                     IPv6 address(es).
+
+                     Example. "name=ia_addr", "code=5", "type=ipv6".
+
+                     put_dhcpv6_opts(..., ia_addr = ae70::4,...)
+
+              value: str
+                     This  indicates  that the value of the DHCPv6 option is a
+                     string.
+
+                     Example. "name=domain_search", "code=24", "type=str".
+
+                     put_dhcpv6_opts(..., domain_search = ovn.domain,...)
+
+              value: mac
+                     This indicates that the value of the DHCPv6 option  is  a
+                     MAC address.
+
+                     Example. "name=server_id", "code=2", "type=mac".
+
+                     put_dhcpv6_opts(..., server_id = 01:02:03:04L05:06,...)
+Connection TABLE
+       Configuration  for  a  database  connection to an Open vSwitch database
+       (OVSDB) client.
+
+       This table  primarily  configures  the  Open  vSwitch  database  server
+       (ovsdb-server).
+
+       The  Open vSwitch database server can initiate and maintain active conā€
+       nections to remote clients. It can also  listen  for  database  connecā€
+       tions.
+
+   Summary:
+       Core Features:
+         target                      string (must be unique within table)
+         read_only                   boolean
+         role                        string
+       Client Failure Detection and Handling:
+         max_backoff                 optional integer, at least 1,000
+         inactivity_probe            optional integer
+       Status:
+         is_connected                boolean
+         status : last_error         optional string
+         status : state              optional  string, one of ACTIVE, BACKOFF,
+                                     CONNECTING, IDLE, or VOID
+         status : sec_since_connect  optional string, containing  an  integer,
+                                     at least 0
+         status : sec_since_disconnect
+                                     optional  string,  containing an integer,
+                                     at least 0
+         status : locks_held         optional string
+         status : locks_waiting      optional string
+         status : locks_lost         optional string
+         status : n_connections      optional string, containing  an  integer,
+                                     at least 2
+         status : bound_port         optional string, containing an integer
+       Common Columns:
+         external_ids                map of string-string pairs
+         other_config                map of string-string pairs
+
+   Details:
+     Core Features:
+
+       target: string (must be unique within table)
+              Connection methods for clients.
+
+              The following connection methods are currently supported:
+
+              ssl:host[:port]
+                     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
+                     built as part of Open vSwitch.
+
+              tcp:host[:port]
+                     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  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.
+
+                     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ā€
+                     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 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
+              unique. Duplicate target values yield unspecified results.
+
+       read_only: boolean
+              true  to  restrict  these connections to read-only transactions,
+              false to allow them to modify the database.
+
+       role: string
+              String containing role name for this connection entry.
+
+     Client Failure Detection and Handling:
+
+       max_backoff: optional integer, at least 1,000
+              Maximum number of milliseconds to wait  between  connection  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
+              inactivity probes.
+
+     Status:
+
+       Key-value pair of is_connected is always updated. Other key-value pairs
+       in the status columns may be updated depends on the target type.
+
+       When target specifies a connection method that listens for inbound conā€
+       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ā€
+       ted.
+
+       is_connected: boolean
+              true if currently connected to this client, false otherwise.
+
+       status : last_error: optional string
+              A human-readable description of the last error on the connection
+              to  the  manager; i.e. strerror(errno). This key will exist only
+              if an error has occurred.
+
+       status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
+       IDLE, or VOID
+              The state of the connection to the manager:
+
+              VOID   Connection is disabled.
+
+              BACKOFF
+                     Attempting to reconnect at an increasing period.
+
+              CONNECTING
+                     Attempting to connect.
+
+              ACTIVE Connected, remote host responsive.
+
+              IDLE   Connection is idle. Waiting for response to keep-alive.
+
+              These values may change in the future. They  are  provided  only
+              for human consumption.
+
+       status : sec_since_connect: optional string, containing an integer, at
+       least 0
+              The amount of time since this client last successfully connected
+              to the database (in seconds). Value is empty if client has never
+              successfully been connected.
+
+       status : sec_since_disconnect: optional string, containing an integer,
+       at least 0
+              The  amount of time since this client last disconnected from the
+              database (in seconds). Value is empty if client has  never  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
+              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ā€
+              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
+              locks have been stolen from this connection.
+
+       status : n_connections: optional string, containing an integer, at
+       least 2
+              When  target  specifies a connection method that listens for 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
+              available port.)
+
+     Common Columns:
+
+       The overall purpose of these columns is described under Common  Columns
+       at the beginning of this document.
+
+       external_ids: map of string-string pairs
+
+       other_config: map of string-string pairs
+SSL TABLE
+       SSL configuration for ovn-sb database access.
+
+   Summary:
+       private_key                   string
+       certificate                   string
+       ca_cert                       string
+       bootstrap_ca_cert             boolean
+       ssl_protocols                 string
+       ssl_ciphers                   string
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       private_key: string
+              Name  of  a  PEM  file  containing  the  private key used as the
+              switchā€™s identity for SSL connections to the controller.
+
+       certificate: string
+              Name of a PEM file containing a certificate, signed by the  cerā€
+              tificate authority (CA) used by the controller and manager, that
+              certifies  the  switchā€™s  private key, identifying a trustworthy
+              switch.
+
+       ca_cert: string
+              Name of a PEM file containing the CA certificate used to  verify
+              that the switch is connected to a trustworthy controller.
+
+       bootstrap_ca_cert: boolean
+              If  set to true, then Open vSwitch will attempt to obtain the CA
+              certificate from the controller on its first SSL connection  and
+              save  it to the named PEM file. If it is successful, it will 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 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
+              omitted is HIGH:!aNULL:!MD5.
+
+     Common Columns:
+
+       The  overall purpose of these columns is described under Common Columns
+       at the beginning of this document.
+
+       external_ids: map of string-string pairs
+DNS TABLE
+       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
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       records: map of string-string pairs
+              Key-value pair of DNS records with DNS query name as the key and
+              a  string  of  IP address(es) separated by comma or space as the
+              value. ovn-northd stores the DNS query name in all lowercase  in
+              order to facilitate case-insensitive lookups.
+
+              Example:  "vm1.ovn.org" = "10.0.0.4 aef0::4"
+
+       datapaths: set of 1 or more Datapath_Bindings
+              The  DNS  records  defined in the column records will be applied
+              only to the DNS queries originating from the  datapaths  defined
+              in this column.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+RBAC_Role TABLE
+       Role table for role-based access controls.
+
+   Summary:
+       name                          string
+       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ā€ā€
+              tion table.
+
+       permissions: map of string-weak reference to RBAC_Permission pairs
+              A mapping of table names to rows in the RBAC_Permission table.
+
+RBAC_Permission TABLE
+       Permissions table for role-based access controls.
+
+   Summary:
+       table                         string
+       authorization                 set of strings
+       insert_delete                 boolean
+       update                        set of strings
+
+   Details:
+       table: string
+              Name of table to which this row applies.
+
+       authorization: set of strings
+              Set of strings identifying columns and column:key  pairs  to  be
+              compared with client ID. At least one match is required in order
+              to  be  authorized. A zero-length string is treated as a special
+              value indicating all clients should be considered authorized.
+
+       insert_delete: boolean
+              When "true", row insertions and  authorized  row  deletions  are
+              permitted.
+
+       update: set of strings
+              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
+       redirected to a chassis, or a set of them in high availability configuā€
+       rations.
+
+   Summary:
+       name                          string (must be unique within table)
+       chassis                       optional weak reference to Chassis
+       priority                      integer, in range 0 to 32,767
+       options                       map of string-string pairs
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       name: string (must be unique within table)
+              Name of the Gateway_Chassis.
+
+              A   suggested,   but   not   required   naming   convention   is
+              ${port_name}_${chassis_name}.
+
+       chassis: optional weak reference to Chassis
+              The Chassis to which we send the traffic.
+
+       priority: integer, in range 0 to 32,767
+              This is the  priority  the  specific  Chassis  among  all  Gateā€
+              way_Chassis belonging to the same Port_Binding.
+
+       options: map of string-string pairs
+              Reserved for future use.
+
+     Common Columns:
+
+       The  overall purpose of these columns is described under Common Columns
+       at the beginning of this document.
+
+       external_ids: map of string-string pairs
+HA_Chassis TABLE
+   Summary:
+       chassis                       optional weak reference to Chassis
+       priority                      integer, in range 0 to 32,767
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       chassis: optional weak reference to Chassis
+              The Chassis which provides the HA functionality.
+
+       priority: integer, in range 0 to 32,767
+              Priority of the HA chassis. Chassis with highest  priority  will
+              be the master in the HA chassis group.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+HA_Chassis_Group TABLE
+       Table representing a group of chassis which can provide High 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 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
+       group.
+
+   Summary:
+       name                          string (must be unique within table)
+       ha_chassis                    set of HA_Chassises
+       ref_chassis                   set of weak reference to Chassis
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+       name: string (must be unique within table)
+              Name of the HA_Chassis_Group. Name should be unique.
+
+       ha_chassis: set of HA_Chassises
+              A list of HA_Chassis which belongs to this group.
+
+       ref_chassis: set of weak reference to Chassis
+              The set of Chassis that reference this HA chassis group. To  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:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+Controller_Event TABLE
+       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
+
+   Summary:
+       event_type                    string, must be empty_lb_backends
+       event_info                    map of string-string pairs
+       chassis                       optional weak reference to Chassis
+       seq_num                       integer
+
+   Details:
+       event_type: string, must be empty_lb_backends
+              Event type occurred
+
+       event_info: map of string-string pairs
+              Key-value pairs used to specify event info to the CMS.  Possible
+              values are:
+
+              ā€¢      vip: VIP reported for the empty_lb_backends event
+
+              ā€¢      protocol:    Transport    protocol   reported   for   the
+                     empty_lb_backends event
+
+              ā€¢      load_balancer: UUID of the load balancer reported for the
+                     empty_lb_backends event
+
+       chassis: optional weak reference to Chassis
+              This column is a Chassis record to identify the chassis that has
+              managed a given event.
+
+       seq_num: integer
+              Event sequence number. Global counter for  controller  generated
+              events. It can be used by the CMS to detect possible duplication
+              of the same event.
+IP_Multicast TABLE
+       IP Multicast configuration options. For now only applicable to IGMP.
+
+   Summary:
+       datapath                      weak  reference to Datapath_Binding (must
+                                     be unique within table)
+       enabled                       optional boolean
+       querier                       optional boolean
+       table_size                    optional integer
+       idle_timeout                  optional integer
+       query_interval                optional integer
+       seq_no                        integer
+       Querier configuration options:
+         eth_src                     string
+         ip4_src                     string
+         ip6_src                     string
+         query_max_resp              optional integer
+
+   Details:
+       datapath: weak reference to Datapath_Binding (must be unique within taā€
+       ble)
+              Datapath_Binding entry for which these configuration options are
+              defined.
+
+       enabled: optional boolean
+              Enables/disables multicast snooping. Default: disabled.
+
+       querier: optional boolean
+              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. Deā€
+              fault: 2048 groups per datapath.
+
+       idle_timeout: optional integer
+              Configures the idle timeout (in seconds) for IP multicast groups
+              if multicast snooping is enabled. Default: 300 seconds.
+
+       query_interval: optional integer
+              Configures the  interval  (in  seconds)  for  sending  multicast
+              queries if snooping and querier are enabled. Default: idle_timeā€ā€
+              out/2 seconds.
+
+       seq_no: integer
+              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
+       following columns to determine field values in IGMP/MLD queries that it
+       originates:
+
+       eth_src: string
+              Source Ethernet address.
+
+       ip4_src: string
+              Source IPv4 address.
+
+       ip6_src: string
+              Source IPv6 address.
+
+       query_max_resp: optional integer
+              Value  (in seconds) to be used as "max-response" field in multiā€
+              cast queries. Default: 1 second.
+
+IGMP_Group TABLE
+       Contains learned IGMP groups indexed by address/datapath/chassis.
+
+   Summary:
+       address                       string
+       datapath                      optional weak reference to Datapath_Bindā€ā€
+                                     ing
+       chassis                       optional weak reference to Chassis
+       ports                         set of weak reference to Port_Bindings
+
+   Details:
+       address: string
+              Destination IPv4 address for the IGMP group.
+
+       datapath: optional weak reference to Datapath_Binding
+              Datapath to which this IGMP group belongs.
+
+       chassis: optional weak reference to Chassis
+              Chassis to which this IGMP group belongs.
+
+       ports: set of weak reference to Port_Bindings
+              The destination port bindings for this IGMP group.
+
+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 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
+       check feature offered to the CMS through the northbound database.
+
+   Summary:
+       Configuration:
+         ip                          string
+         protocol                    optional string, either tcp or udp
+         port                        integer, in range 0 to 65,535
+         logical_port                string
+         src_mac                     string
+         src_ip                      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,
+                                     or online
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   Details:
+     Configuration:
+
+       ovn-northd sets these columns and values to configure the service moniā€
+       tor.
+
+       ip: string
+              IP of the service to be monitored. Only IPv4 is supported.
+
+       protocol: optional string, either tcp or udp
+              The protocol of the service.
+
+       port: integer, in range 0 to 65,535
+              The TCP or UDP port of the service.
+
+       logical_port: string
+              The VIF of the logical port on which the service is running. The
+              ovn-controller that binds this logical_port monitors the service
+              by sending periodic monitor packets.
+
+       src_mac: string
+              Source Ethernet address to use in the service monitor packet.
+
+       src_ip: string
+              Source IPv4 address to use in the service monitor packet.
+
+       options : interval: optional string, containing an integer
+              The interval, in seconds, between service monitor checks.
+
+       options : timeout: optional string, containing an integer
+              The time, in seconds, after  which  the  service  monitor  check
+              times out.
+
+       options : success_count: optional string, containing an integer
+              The  number of successful checks after which the service is conā€
+              sidered online.
+
+       options : failure_count: optional string, containing an integer
+              The number of failure checks after which the service is  considā€
+              ered offline.
+
+     Status Reporting:
+
+       The  ovn-controller  on the chassis that hosts the logical_port updates
+       this column to report the serviceā€™s status.
+
+       status: optional string, one of error, offline, or online
+              For TCP service, ovn-controller sends a SYN to the  service  and
+              expects an ACK response to consider the service to be online.
+
+              For  UDP  service, ovn-controller sends a UDP packet to the serā€
+              vice and doesnā€™t expect any reply. If it receives an ICMP reply,
+              then it considers the service to be offline.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+Load_Balancer TABLE
+       Each row represents a load balancer.
+
+   Summary:
+       name                          string
+       vips                          map of string-string pairs
+       protocol                      optional string, one of sctp, tcp, or udp
+       datapaths                     set of Datapath_Bindings
+       datapath_group                optional Logical_DP_Group
+       Load_Balancer options:
+         options : hairpin_snat_ip   optional string
+         options : hairpin_orig_tuple
+                                     optional string, either true or false
+       Common Columns:
+         external_ids                map of string-string pairs
+
+   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ā€
+              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
+              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
+              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
+              in a group.
+
+     Load_Balancer options:
+
+       options : hairpin_snat_ip: optional string
+              IP to be used as source IP for  packets  that  have  been  hair-
+              pinned  after  load balancing. This value is automatically popuā€
+              lated by ovn-northd.
+
+       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
+              packets are stored in registers reg1, reg2, xxreg1.
+
+     Common Columns:
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+BFD TABLE
+       Contains BFD parameter for ovn-controller bfd configuration.
+
+   Summary:
+       Configuration:
+         src_port                    integer, in range 49,152 to 65,535
+         disc                        integer
+         logical_port                string
+         dst_ip                      string
+         min_tx                      integer
+         min_rx                      integer
+         detect_mult                 integer
+         options                     map of string-string pairs
+         external_ids                map of string-string pairs
+       Status Reporting:
+         status                      string, one of admin_down, down, init, or
+                                     up
+
+   Details:
+     Configuration:
+
+       src_port: integer, in range 49,152 to 65,535
+              udp  source  port  used  in bfd control packets. The source port
+              MUST be in the range 49152 through 65535 (RFC5881 section 4).
+
+       disc: integer
+              A unique, nonzero discriminator value generated by the transmitā€
+              ting system, used to demultiplex multiple BFD  sessions  between
+              the same pair of systems.
+
+       logical_port: string
+              OVN logical port when BFD engine is running.
+
+       dst_ip: string
+              BFD peer IP address.
+
+       min_tx: integer
+              This  is  the  minimum interval, in milliseconds, that the local
+              system would like to use when transmitting BFD Control  packets,
+              less any jitter applied. The value zero is reserved.
+
+       min_rx: integer
+              This  is the minimum interval, in milliseconds, between received
+              BFD Control packets that this system is capable  of  supporting,
+              less  any  jitter  applied by the sender. If this value is zero,
+              the transmitting system does not want the remote system to  send
+              any periodic BFD Control packets.
+
+       detect_mult: integer
+              Detection  time  multiplier.  The  negotiated transmit interval,
+              multiplied by this value, provides the Detection  Time  for  the
+              receiving system in Asynchronous mode.
+
+       options: map of string-string pairs
+              Reserved for future use.
+
+       external_ids: map of string-string pairs
+              See External IDs at the beginning of this document.
+
+     Status Reporting:
+
+       status: string, one of admin_down, down, init, or up
+              BFD port logical states. Possible values are:
+
+              ā€¢      admin_down
+
+              ā€¢      down
+
+              ā€¢      init
+
+              ā€¢      up
+FDB TABLE
+       This  table is primarily used to learn the MACs observed on a VIF (or a
+       localnet port with ā€™localnet_learn_fdbā€™ enabled)  which  belongs  to  a
+       Logical_Switch_Port  record  in  OVN_Northbound  whose port security is
+       disabled and ā€™unknownā€™ address set. If port security is disabled  on  a
+       Logical_Switch_Port  record,  OVN  should allow traffic with any source
+       mac from the VIF. This table will be used to deliver a  packet  to  the
+       VIF, If a packetā€™s eth.dst is learnt.
+
+   Summary:
+       mac                           string
+       dp_key                        integer, in range 1 to 16,777,215
+       port_key                      integer, in range 1 to 16,777,215
+
+   Details:
+       mac: string
+              The learnt mac address.
+
+       dp_key: integer, in range 1 to 16,777,215
+              The key of the datapath on which this FDB was learnt.
+
+       port_key: integer, in range 1 to 16,777,215
+              The key of the port binding on which this FDB was learnt.
+
+Static_MAC_Binding TABLE
+       Each record represents a Static_MAC_Binding entry for a logical router.
+
+   Summary:
+       logical_port                  string
+       ip                            string
+       mac                           string
+       override_dynamic_mac          boolean
+       datapath                      Datapath_Binding
+
+   Details:
+       logical_port: string
+              The logical router port for the binding.
+
+       ip: string
+              The bound IP address.
+
+       mac: string
+              The Ethernet address to which the IP is bound.
+
+       override_dynamic_mac: boolean
+              Override dynamically learnt MACs.
+
+       datapath: Datapath_Binding
+              The logical datapath to which the logical router port belongs.
+
+Chassis_Template_Var TABLE
+       Each  record represents the set of template variable instantiations for
+       a given chassis and is populated by ovn-northd from the contents of the
+       OVN_Northbound.Chassis_Template_Var table.
+
+   Summary:
+       chassis                       string (must be unique within table)
+       variables                     map of string-string pairs
+
+   Details:
+       chassis: string (must be unique within table)
+              The chassis this set of variable values applies to.
+
+       variables: map of string-string pairs
+              The set of variable values for a given chassis.
+
+Open vSwitch 23.06.3           DB Schema 20.27.2                     ovn-sb(5)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-sb.5.pdf b/src/static/support/dist-docs-branch-23.06/ovn-sb.5.pdf new file mode 100644 index 00000000..b4186f30 Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-sb.5.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-sb.5.txt b/src/static/support/dist-docs-branch-23.06/ovn-sb.5.txt new file mode 100644 index 00000000..4e4b174e --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-sb.5.txt @@ -0,0 +1,3972 @@ +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 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 + northbound to the Cloud Management System, via ovn-northd: + + Database Structure + The OVN Southbound database contains classes of data with different + properties, as described in the sections below. + + Physical network + + Physical network tables contain 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 + 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 + 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ā€ + pates. + + 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 + and ovn-northd. + + Logical network data is likely to change more quickly than physical + network data. This is especially true in a container environment where + containers are created and destroyed (and therefore added to and + deleted from logical switches) quickly. + + The Logical_Flow, Multicast_Group, Address_Group, DHCP_Options, + DHCPv6_Options, and DNS tables contain logical network data. + + Logical-physical bindings + + These tables link logical and physical components. They show the curā€ + rent placement of logical components (such as VMs and VIFs) onto chasā€ + 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. + 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ā€ + tion, so the consistency needs are minimal. + + The Port_Binding and Datapath_Binding tables contain binding data. + + MAC bindings + + The MAC_Binding table tracks the bindings from IP addresses to Ethernet + addresses that are dynamically discovered using ARP (for IPv4) and + neighbor discovery (for IPv6). Usually, IP-to-MAC bindings for virtual + machines are statically populated into the Port_Binding table, so + MAC_Binding is primarily used to discover bindings on physical netā€ + works. + + 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 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ā€ā€ + 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 + as entities in the OVN Northbound database). Individual + key-value pairs in this column may be documented in some + cases to aid in understanding and troubleshooting, but + the reader should not mistake such documentation as comā€ + prehensive. + +TABLE SUMMARY + The following list summarizes the purpose of each of the tables in the + OVN_Southbound database. Each table is described in more detail on a + later page. + + Table Purpose + SB_Global Southbound configuration + Chassis Physical Network Hypervisor and Gateway Information + Chassis_Private + Chassis Private + Encap Encapsulation Types + Address_Set + Address Sets + Port_Group + Port Groups + Logical_Flow + Logical Network Flows + Logical_DP_Group + Logical Datapath Groups + Multicast_Group + Logical Port Multicast Groups + Mirror Mirror Entry + Meter Meter entry + Meter_Band + Band for meter entries + Datapath_Binding + Physical-Logical Datapath Bindings + Port_Binding + Physical-Logical Port Bindings + MAC_Binding + IP to MAC bindings + DHCP_Options + DHCP Options supported by native OVN DHCP + DHCPv6_Options + DHCPv6 Options supported by native OVN DHCPv6 + Connection + OVSDB client connections. + SSL SSL configuration. + DNS Native DNS resolution + RBAC_Role RBAC_Role configuration. + RBAC_Permission + RBAC_Permission configuration. + Gateway_Chassis + Gateway_Chassis configuration. + HA_Chassis + HA_Chassis configuration. + HA_Chassis_Group + HA_Chassis_Group configuration. + Controller_Event + Controller Event table + IP_Multicast + IP_Multicast configuration. + IGMP_Group + IGMP_Group configuration. + Service_Monitor + Service_Monitor configuration. + Load_Balancer + Load_Balancer configuration. + BFD BFD configuration. + FDB Port to MAC bindings + Static_MAC_Binding + IP to MAC bindings + Chassis_Template_Var + Chassis_Template_Var configuration. + +SB_Global TABLE + Southbound configuration for an OVN system. This table must have exā€ + actly one row. + + Summary: + Status: + nb_cfg integer + Common Columns: + external_ids map of string-string pairs + options map of string-string pairs + Common options: + options map of string-string pairs + Options for configuring BFD: + options : bfd-min-rx optional string + options : bfd-decay-min-rx + optional string + options : bfd-min-tx optional string + options : bfd-mult optional string + options : debug_drop_domain_id + optional string + options : debug_drop_collector_set + optional string + Options for configuring 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 + Security Configurations: + ipsec boolean + + Details: + Status: + + This column allow a client to track the overall configuration state of + the system. + + nb_cfg: integer + Sequence number for the configuration. When a CMS or ovn-nbctl + updates the northbound database, it increments the nb_cfg column + in the NB_Global table in the northbound database. In turn, when + ovn-northd updates the southbound database to bring it up to + date with these changes, it updates this column to the same + value. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + + options: map of string-string pairs + + Common options: + + options: map of string-string pairs + This column provides general key/value settings. The supported + options are described individually below. + + Options for configuring BFD: + + 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 + interfaces. + + options : bfd-decay-min-rx: optional string + BFD option decay-min-rx value to use when configuring BFD on + tunnel interfaces. + + options : bfd-min-tx: optional string + BFD option min-tx value to use when configuring BFD on tunnel + interfaces. + + options : bfd-mult: optional string + BFD option mult value to use when configuring BFD on tunnel 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 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 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 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 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ā€ā€ + tion table for more information. + + ssl: optional SSL + Global SSL configuration. + + Security Configurations: + + ipsec: boolean + 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 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 + equally unreachable regardless of whether the row is present.) If a + chassis shuts down permanently without removing its row, some kind of + manual or automatic cleanup is eventually needed; we can devise a + process for that as necessary. + + Summary: + name string (must be unique within table) + hostname string + nb_cfg integer + other_config : ovn-bridge-mappings + optional string + other_config : datapath-type optional string + other_config : iface-types optional string + other_config : ovn-cms-options + optional string + other_config : is-interconn optional string + other_config : is-remote optional string + transport_zones set of strings + other_config : ovn-chassis-mac-mappings + optional string + other_config : port-up-notif optional string + Common Columns: + external_ids map of string-string pairs + Encapsulation Configuration: + encaps set of 1 or more Encaps + Gateway Configuration: + vtep_logical_switches set of strings + + Details: + name: string (must be unique within table) + OVN does not prescribe a particular format for chassis names. + ovn-controller populates this column using external_ids:system- + id in the Open_vSwitch databaseā€™s Open_vSwitch table. ovn-conā€ + troller-vtep populates this column with name in the hardā€ + ware_vtep databaseā€™s Physical_Switch table. + + hostname: string + The hostname of the chassis, if applicable. ovn-controller will + populate this column with the hostname of the host it is running + on. ovn-controller-vtep will leave this column empty. + + nb_cfg: integer + Deprecated. This column is replaced by the nb_cfg column of the + Chassis_Private table. + + other_config : ovn-bridge-mappings: optional string + ovn-controller populates this key with the set of bridge 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ā€ + ured in the datapath_type column of the Open_vSwitch databaseā€™s + Bridge table. Other applications should treat this key as read- + only. See ovn-controller(8) for more information. + + other_config : iface-types: optional string + ovn-controller populates this key with the interface types conā€ + figured in the iface_types column of the Open_vSwitch databaseā€™s + Open_vSwitch table. Other applications should treat this key as + read-only. See ovn-controller(8) for more information. + + other_config : ovn-cms-options: optional string + ovn-controller populates this key with the set of options 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 + ovn-controller populates this key with the setting configured in + the external_ids:ovn-is-interconn column of the Open_vSwitch + databaseā€™s Open_vSwitch table. If set to true, the chassis is + used as an interconnection gateway. See ovn-controller(8) for + more information. + + other_config : is-remote: optional string + ovn-ic set this key to true for remote interconnection gateway + chassises learned from the interconnection southbound database. + See ovn-ic(8) for more information. + + transport_zones: set of strings + ovn-controller populates this key with the transport zones conā€ + figured in the external_ids:ovn-transport-zones column of the + 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ā€ā€ + troller(8) for more information. + + other_config : port-up-notif: optional string + ovn-controller populates this key with true when it supports + Port_Binding.up. + + Common Columns: + + The overall purpose of these columns is described under Common Columns + at the beginning of this document. + + external_ids: map of string-string pairs + + Encapsulation Configuration: + + OVN uses encapsulation to transmit logical dataplane packets between + chassis. + + encaps: set of 1 or more Encaps + Points to supported encapsulation configurations to transmit + logical dataplane packets to this chassis. Each entry is a Encap + record that describes the configuration. + + Gateway Configuration: + + A gateway is a chassis that forwards traffic between the OVN-managed + part of a logical network and a physical VLAN, extending a tunnel-based + logical network into a physical network. Gateways are typically dediā€ + 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ā€ā€ + 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 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 + chassis private data update flooding in a large scale deployment. + + Summary: + name string (must be unique within table) + chassis optional weak reference to Chassis + nb_cfg integer + nb_cfg_timestamp integer + Common Columns: + external_ids map of string-string pairs + + Details: + name: string (must be unique within table) + The name of the chassis that owns these chassis-private data. + + chassis: optional weak reference to Chassis + The reference to Chassis table for the chassis that owns these + chassis-private data. + + nb_cfg: integer + Sequence number for the configuration. When ovn-controller 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 + The timestamp when ovn-controller finishes processing the change + corresponding to nb_cfg. + + Common Columns: + + The overall purpose of these columns is described under Common Columns + at the beginning of this document. + + external_ids: map of string-string pairs +Encap TABLE + The encaps column in the Chassis table refers to rows in this table to + identify how OVN may transmit logical dataplane packets to this chasā€ + sis. Each chassis, via ovn-controller(8) or ovn-controller-vtep(8), + adds and updates its own rows and keeps a copy of the remaining rows to + determine how to reach other chassis. + + Summary: + type string, one of geneve, stt, or vxlan + options map of string-string pairs + options : csum optional string, either true or false + options : dst_port optional string, containing an integer + ip string + chassis_name string + + Details: + type: string, one of geneve, stt, or vxlan + 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 + specific. + + options : csum: optional string, either true or false + csum indicates whether this chassis can transmit and receive + packets that include checksums with reasonable performance. It + hints to senders transmitting data to this chassis that they + should use checksums to protect OVN metadata. ovn-controller + populates this key with the value defined in external_ids:ovn- + encap-csum column of the Open_vSwitch databaseā€™s Open_vSwitch + table. Other applications should treat this key as read-only. + See ovn-controller(8) for more information. + + 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 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 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 + checksums well.) + + csum defaults to false for hardware VTEPs and true for all other + cases. + + This option applies to geneve and vxlan encapsulations. + + options : dst_port: optional string, containing an integer + If set, overrides the UDP (for geneve and vxlan) or TCP (for + stt) destination port. + + ip: string + The IPv4 address of the encapsulation tunnel endpoint. + + chassis_name: string + The name of the chassis that created this encap. + +Address_Set TABLE + This table contains address sets synced from the Address_Set table in + the OVN_Northbound database and address sets generated from the + Port_Group table in the OVN_Northbound database. + + See the documentation for the Address_Set table and Port_Group table in + the OVN_Northbound database for details. + + Summary: + name string (must be unique within table) + addresses set of strings + + Details: + 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 + in Port_Group in the OVN_Northbound database. + + Summary: + name string (must be unique within table) + ports set of strings + + Details: + name: string (must be unique within table) + + ports: set of strings +Logical_Flow TABLE + 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 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 + 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 + OpenFlow and OVSDB, to execute them on its behalf. + + At a high level, OVN passes each packet through the logical datapathā€™s + logical ingress pipeline, which may output the packet to one or more + logical port or logical multicast groups. For each such logical output + port, OVN passes the packet through the datapathā€™s logical egress + pipeline, which may either drop the packet or deliver it to the 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 + further details. The next and output actions are special. + + 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, + flow control returns to the action following next. + + The output action also introduces recursion. Its effect depends on the + current value of the outport field. Suppose outport designates a 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ā€ + isters arenā€™t preserve across tunnel encapsulation). + + To execute the egress pipeline, OVN again searches the Logical_Flow taā€ + ble for a row with correct logical_datapath or a logical_dp_group, a + table_id of 0, a match that is true for the packet, but now looking for + a pipeline of egress. If no matching row is found, the output becomes a + no-op. Otherwise, OVN executes the actions for the matching flow (which + is chosen from multiple, if necessary, as already described). + + In the egress pipeline, the next action acts as already described, 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 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 deā€ + scribed in detail in ovn-northd(8). + + Summary: + logical_datapath optional Datapath_Binding + logical_dp_group optional Logical_DP_Group + pipeline string, either egress or ingress + table_id integer, in range 0 to 32 + priority integer, in range 0 to 65,535 + match string + actions string + tags map of string-string pairs + controller_meter optional string + external_ids : stage-name optional string + external_ids : stage-hint optional string, containing an uuid + external_ids : source optional string + Common Columns: + external_ids map of string-string pairs + + Details: + logical_datapath: optional Datapath_Binding + The logical datapath to which the logical flow belongs. + + logical_dp_group: optional Logical_DP_Group + The group of logical datapaths to which the logical flow 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ā€ā€ + 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ā€ + ble number. + + priority: integer, in range 0 to 65,535 + The flowā€™s priority. Flows with numerically higher priority take + precedence over those with lower. If two logical datapath flows + with the same priority both match, then the one actually applied + to the packet is undefined. + + match: string + A matching expression. OVN provides a superset of OpenFlow + matching capabilities, using a syntax similar to Boolean expresā€ + sions in a programming language. + + 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 + comparisons into a larger expression. + + Matching expressions also support parentheses for grouping, the + logical NOT prefix operator !, and literals 0 and 1 to express + ``falseā€™ā€™ or ``true,ā€™ā€™ respectively. The latter is useful by itā€ + self as a catch-all expression that matches every packet. + + Match expressions also support a kind of function syntax. The + following functions are supported: + + is_chassis_resident(lport) + Evaluates to true on a chassis on which logical port + lport (a quoted string) resides, and to false elsewhere. + This function was introduced in OVN 2.7. + + Symbols + + Type. Symbols have integer or string type. Integer symbols have + a width in bits. + + Kinds. There are three kinds of symbols: + + ā€¢ Fields. A field symbol represents a packet header or + metadata field. For example, a field named vlan.tci might + represent the VLAN TCI field in a packet. + + A field symbol can have integer or string type. Integer + fields can be nominal or ordinal (see Level of Measureā€ā€ + ment, below). + + ā€¢ 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 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ā€ + nal; other predicates have Boolean level of measurement. + + Level of Measurement. See + http://en.wikipedia.org/wiki/Level_of_measurement for the staā€ + tistical concept on which this classification is based. There + are three levels: + + ā€¢ Ordinal. In statistics, ordinal values can be ordered on + a scale. OVN considers a field (or subfield) to be ordiā€ + nal if its bits can be examined individually. This is + true for the OpenFlow fields that OpenFlow or Open + vSwitch makes ``maskable.ā€™ā€™ + + Any use of a ordinal field may specify a single bit or a + range of bits, e.g. vlan.tci[13..15] refers to the PCP + field within the VLAN TCI, and eth.dst[40] refers to the + multicast bit in the Ethernet destination address. + + OVN supports all the usual arithmetic relations (==, !=, + <, <=, >, and >=) on ordinal fields and their subfields, + because OVN can implement these in OpenFlow and Open + vSwitch as collections of bitwise tests. + + ā€¢ Nominal. In statistics, nominal values cannot be usefully + compared except for equality. This is true of OpenFlow + port numbers, Ethernet types, and IP protocols are 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 + way for a flow to efficiently implement other comparisons + on them. (A test for inequality can be sort of built out + of two flows with different priorities, but OVN matching + expressions always generate flows with a single priorā€ + ity.) + + String fields are always nominal. + + ā€¢ Boolean. A nominal field that has only two values, 0 and + 1, is somewhat exceptional, since it is easy to support + both equality and inequality tests on such a field: 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 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 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, + 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 efā€ + ficient than that of the other relational operators. + + Constants + + 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 inā€ + tegers, to express CIDR prefixes. + + String constants have the same syntax as quoted strings in JSON + (thus, they are Unicode strings). + + Some operators support sets of constants written inside curly + braces { ... }. Commas between elements of a set, and after the + last elements, are optional. With ==, ``field == { constant1, + constant2, ... }ā€™ā€™ is syntactic sugar for ``field == constant1 + || field == constant2 || .... Similarly, ``field != { constant1, + constant2, ... }ā€™ā€™ is equivalent to ``field != constant1 && + field != constant2 && ...ā€™ā€™. + + You may refer to a set of IPv4, IPv6, or MAC addresses stored in + the Address_Set table by its name. An Address_Set with a name of + set1 can be referred to as $set1. + + You may refer to a group of logical switch ports stored in the + Port_Group table by its name. An Port_Group with a name of + port_group1 can be referred to as @port_group1. + + Additionally, you may refer to the set of addresses belonging to + a group of logical switch ports stored in the Port_Group table + by its name followed by a suffix ā€™_ip4ā€™/ā€™_ip6ā€™. The IPv4 address + set of a Port_Group with a name of port_group1 can be referred + to as $port_group1_ip4, and the IPv6 address set of the same + Port_Group can be referred to as $port_group1_ip6 + + Miscellaneous + + Comparisons may name the symbol or the constant first, e.g. + tcp.src == 80 and 80 == tcp.src are both acceptable. + + Tests for a range may be expressed using a syntax like 1024 <= + tcp.src <= 49151, which is equivalent to 1024 <= tcp.src && + tcp.src <= 49151. + + For a one-bit field or predicate, a mention of its name is + equivalent to symobl == 1, e.g. vlan.present is equivalent to + vlan.present == 1. The same is true for one-bit subfields, e.g. + vlan.tci[12]. There is no technical limitation to implementing + the same for ordinal fields of all widths, but the 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 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 || 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ā€ + tiline comments are not supported. + + Symbols + + Most of the symbols below have integer type. Only inport and + outport have string type. inport names a logical port. Thus, its + value is a logical_port name from the Port_Binding table. 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: + 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 + + ā€¢ xxreg0 xxreg1 + + ā€¢ inport outport + + ā€¢ flags.loopback + + ā€¢ pkt.mark + + ā€¢ eth.src eth.dst eth.type + + ā€¢ vlan.tci vlan.vid vlan.pcp vlan.present + + ā€¢ ip.proto ip.dscp ip.ecn ip.ttl ip.frag + + ā€¢ ip4.src ip4.dst + + ā€¢ ip6.src ip6.dst ip6.label + + ā€¢ arp.op arp.spa arp.tpa arp.sha arp.tha + + ā€¢ rarp.op rarp.spa rarp.tpa rarp.sha rarp.tha + + ā€¢ tcp.src tcp.dst tcp.flags + + ā€¢ udp.src udp.dst + + ā€¢ sctp.src sctp.dst + + ā€¢ icmp4.type icmp4.code + + ā€¢ icmp6.type icmp6.code + + ā€¢ nd.target nd.sll nd.tll + + ā€¢ ct_mark ct_label + + ā€¢ ct_state, which has several Boolean subfields. The + ct_next action initializes the following subfields: + + ā€¢ ct.trk: Always set to true by ct_next to indicate + that connection tracking has taken place. All + other ct subfields have ct.trk as a prerequisite. + + ā€¢ ct.new: True for a new flow + + ā€¢ ct.est: True for an established flow + + ā€¢ ct.rel: True for a related flow + + ā€¢ ct.rpl: True for a reply flow + + ā€¢ ct.inv: True for a connection entry in a bad state + + The ct_dnat, ct_snat, and ct_lb actions initialize the + following subfields: + + ā€¢ ct.dnat: True for a packet whose destination IP + address has been changed. + + ā€¢ ct.snat: True for a packet whose source IP address + has been changed. + + The following predicates are supported: + + ā€¢ eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff + + ā€¢ eth.mcast expands to eth.dst[40] + + ā€¢ vlan.present expands to vlan.tci[12] + + ā€¢ ip4 expands to eth.type == 0x800 + + ā€¢ ip4.src_mcast expands to ip4.src[28..31] == 0xe + + ā€¢ ip4.mcast expands to ip4.dst[28..31] == 0xe + + ā€¢ ip6 expands to eth.type == 0x86dd + + ā€¢ ip expands to ip4 || ip6 + + ā€¢ icmp4 expands to ip4 && ip.proto == 1 + + ā€¢ icmp6 expands to ip6 && ip.proto == 58 + + ā€¢ icmp expands to icmp4 || icmp6 + + ā€¢ ip.is_frag expands to ip.frag[0] + + ā€¢ ip.later_frag expands to ip.frag[1] + + ā€¢ ip.first_frag expands to ip.is_frag && !ip.later_frag + + ā€¢ arp expands to eth.type == 0x806 + + ā€¢ rarp expands to eth.type == 0x8035 + + ā€¢ nd expands to icmp6.type == {135, 136} && icmp6.code == 0 + && ip.ttl == 255 + + ā€¢ nd_ns expands to icmp6.type == 135 && icmp6.code == 0 && + ip.ttl == 255 + + ā€¢ nd_na expands to icmp6.type == 136 && icmp6.code == 0 && + ip.ttl == 255 + + ā€¢ nd_rs expands to icmp6.type == 133 && icmp6.code == 0 && + ip.ttl == 255 + + ā€¢ nd_ra expands to icmp6.type == 134 && icmp6.code == 0 && + ip.ttl == 255 + + ā€¢ tcp expands to ip.proto == 6 + + ā€¢ udp expands to ip.proto == 17 + + ā€¢ sctp expands to ip.proto == 132 + + actions: string + Logical datapath actions, 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 + matched packets to be dropped. Otherwise, the column should conā€ + tain a sequence of actions, each terminated by a semicolon. + + The following actions are defined: + + output; + In the ingress pipeline, this action executes the egress + pipeline as a subroutine. If outport names a logical + port, the egress pipeline executes once; if it is a mulā€ + 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 + 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 + behavior, e.g. to send an ARP reply to an ARP request; to + do so, use flags.loopback = 1 to allow the packet to + "hair-pin" back to the input port. + + next; + next(table); + next(pipeline=pipeline, table=table); + Executes the given logical datapath table in pipeline as a + subroutine. The default table is just after the current + one. If pipeline is specified, it may be ingress or egress; + the default pipeline is the one currently executing. 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 + vlan.pcp[2] = 1; or vlan.pcp = 4/4; to set the most signifā€ + icant bit of the VLAN PCP. + + Assigning to a field with prerequisites implicitly adds + those prerequisites to match; thus, for example, a flow + that sets tcp.dst applies only to TCP flows, regardless of + whether its match mentions any TCP field. + + Not all fields are modifiable (e.g. eth.type and ip.proto + are read-only), and not all modifiable fields may be parā€ + tially modified (e.g. ip.ttl must assigned as a whole). The + outport field is modifiable in the ingress pipeline but not + in the egress pipeline. + + ovn_field = constant; + Sets OVN field ovn_field to constant value constant. + + OVN supports setting the values of certain fields which are + not yet supported in OpenFlow to set or modify them. + + Below are the supported OVN fields: + + ā€¢ icmp4.frag_mtu icmp6.frag_mtu + + This field sets the low-order 16 bits of the + ICMP{4,6} header field that is labelled "unused" in + the ICMP specification as defined in the RFC 1191 + with the value specified in constant. + + 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 + 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, + they must have the same width. + + 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. + + field1 <-> field2; + Similar to field1 = field2; except that the two values are + exchanged instead of copied. Both field1 and field2 must + modifiable. + + push(field); + Push the value of field to the stack top. + + pop(field); + Pop the stack top and store the value to field, which must + be modifiable. + + 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 + cases, a higher-priority flow should match on ip.ttl == {0, + 1};.) + + Prerequisite: ip + + ct_next; + Apply connection tracking to the flow, initializing + ct_state for matching in later tables. Automatically moves + on to the next table, as if followed by next. + + As a side effect, IP fragments will be reassembled for + matching. If a fragmented packet is output, then it will be + sent with any overlapping fragments squashed. The 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 + in a flow for a router. + + It is possible to have actions follow ct_next, but they + will not have access to any of its side-effects and is not + generally useful. + + ct_commit { }; + ct_commit { ct_mark=value[/mask]; }; + ct_commit { ct_label=value[/mask]; }; + ct_commit { ct_mark=value[/mask]; ct_label=value[/mask]; }; + Commit the flow to the connection tracking entry associated + with it by a previous call to ct_next. When + ct_mark=value[/mask] and/or ct_label=value[/mask] are supā€ + plied, ct_mark and/or ct_label will be set to the values + indicated by value[/mask] on the connection tracking entry. + ct_mark is a 32-bit field. ct_label is a 128-bit field. The + value[/mask] should be specified in hex string if more than + 64bits are to be used. Registers and other named fields can + be used for value. ct_mark and ct_label may be sub-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. + You may also leave out next which will commit connection + tracking state, and then drop the packet. This could be + useful for setting ct_mark on a connection tracking entry + before dropping a packet, for example. + + ct_dnat; + 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 + by the connection tracker. + + ct_dnat(IP) sends the packet through the DNAT zone to + change the destination IP address of the packet to the one + provided inside the parentheses and commits the connection. + The packet is then automatically sent to the next tables as + if followed by next; action. The next tables will see the + changes in the packet caused by the connection tracker. + + ct_snat; + ct_snat(IP); + ct_snat sends the packet through the SNAT zone to unSNAT + any packet that was SNATed in the opposite direction. The + packet is automatically sent to the next tables as if 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. + The packet is then automatically sent to the next tables as + if followed by next; action. The next tables will see the + changes in the packet caused by the connection tracker. + + ct_dnat_in_czone; + ct_dnat_in_czone(IP); + ct_dnat_in_czone sends the packet through the common NAT + zone (used for both DNAT and SNAT) in connection tracking + table to unDNAT any packet that was DNATed in the opposite + direction. The packet is then automatically sent to to the + next tables as if followed by next; action. The next tables + will see the changes in the packet caused by the connection + tracker. + + ct_dnat_in_czone(IP) sends the packet through the common + NAT zone to change the destination IP address of the packet + to the one provided inside the parentheses and commits the + connection. The packet is then automatically sent to the + next tables as if followed by next; action. The next tables + will see the changes in the packet caused by the connection + tracker. + + ct_snat_in_czone; + ct_snat_in_czone(IP); + ct_snat_in_czone sends the packet through the common NAT + zone to unSNAT any packet that was SNATed in the opposite + direction. The packet is automatically sent to the next 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 + next tables as if followed by next; action. The next tables + will see the changes in the packet caused by the connection + tracker. + + ct_clear; + Clears connection tracking state. + + ct_commit_nat; + Applies NAT and commits the connection to the CT. Automatiā€ + cally moves on to the next table, as if followed by next. + This is very useful for connections that are in related + state for already existing connections and allows the NAT + to be applied to them as well. + + clone { action; ... }; + Makes a copy of the packet being processed and executes + 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. + + arp { action; ... }; + Temporarily replaces the IPv4 packet being processed by an + ARP packet and executes each nested action on the ARP + packet. Actions following the arp action, if any, apply to + the original, unmodified packet. + + The ARP packet that this action operates on is initialized + based on the IPv4 packet being processed, as follows. These + are default values that the nested actions will probably + want to change: + + ā€¢ eth.src unchanged + + ā€¢ eth.dst unchanged + + ā€¢ eth.type = 0x0806 + + ā€¢ arp.op = 1 (ARP request) + + ā€¢ arp.sha copied from eth.src + + ā€¢ arp.spa copied from ip4.src + + ā€¢ arp.tha = 00:00:00:00:00:00 + + ā€¢ arp.tpa copied from ip4.dst + + The ARP packet has the same VLAN header, if any, as the IP + packet it replaces. + + Prerequisite: ip4 + + get_arp(P, A); + Parameters: logical port string field P, 32-bit IP address + field A. + + Looks up A in Pā€™s mac binding table. If an entry is found, + stores its Ethernet address in eth.dst, otherwise stores + 00:00:00:00:00:00 in eth.dst. + + Example: get_arp(outport, ip4.dst); + + put_arp(P, A, E); + Parameters: logical port string field P, 32-bit IP address + field A, 48-bit Ethernet address field E. + + Adds or updates the entry for IP address A in logical port + Pā€™s mac binding table, setting its Ethernet address to E. + + Example: put_arp(inport, arp.spa, arp.sha); + + R = lookup_arp(P, A, M); + Parameters: logical port string field P, 32-bit IP address + field A, 48-bit MAC address field M. + + Result: stored to a 1-bit subfield R. + + Looks up A and M in Pā€™s mac binding table. If an entry is + found, stores 1 in the 1-bit subfield R, else 0. + + Example: reg0[0] = lookup_arp(inport, arp.spa, arp.sha); + + R = lookup_arp_ip(P, A); + Parameters: logical port string field P, 32-bit IP address + field A. + + Result: stored to a 1-bit subfield R. + + Looks up A in Pā€™s mac binding table. If an entry is found, + stores 1 in the 1-bit subfield R, else 0. + + Example: reg0[0] = lookup_arp_ip(inport, arp.spa); + + P = get_fdb(A); + Parameters:48-bit MAC address field A. + + 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); + + put_fdb(P, A); + Parameters: logical port string field P, 48-bit MAC address + field A. + + Adds or updates the entry for Ethernet address A in fdb taā€ + ble, setting its logical port key to P. + + Example: put_fdb(inport, arp.spa); + + R = lookup_fdb(P, A); + Parameters: 48-bit MAC address field M, logical port string + field P. + + Result: stored to a 1-bit subfield R. + + 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); + + nd_ns { action; ... }; + Temporarily replaces the IPv6 packet being processed by an + IPv6 Neighbor Solicitation packet and executes each nested + action on the IPv6 NS packet. Actions following the nd_ns + 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. + These are default values that the nested actions will probā€ + ably want to change: + + ā€¢ eth.src unchanged + + ā€¢ eth.dst set to IPv6 multicast MAC address + + ā€¢ eth.type = 0x86dd + + ā€¢ ip6.src copied from ip6.src + + ā€¢ ip6.dst set to IPv6 Solicited-Node multicast address + + ā€¢ icmp6.type = 135 (Neighbor Solicitation) + + ā€¢ nd.target copied from ip6.dst + + The IPv6 NS packet has the same VLAN header, if any, as the + IP packet it replaces. + + Prerequisite: ip6 + + nd_na { action; ... }; + Temporarily replaces the IPv6 neighbor solicitation packet + being processed 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 + 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.type = 0x86dd + + ā€¢ ip6.dst copied from ip6.src + + ā€¢ ip6.src copied from nd.target + + ā€¢ icmp6.type = 136 (Neighbor Advertisement) + + ā€¢ nd.target unchanged + + ā€¢ nd.sll = 00:00:00:00:00:00 + + ā€¢ nd.tll copied from eth.dst + + The ND packet has the same VLAN header, if any, as the IPv6 + packet it replaces. + + Prerequisite: nd_ns + + nd_na_router { action; ... }; + Temporarily replaces the IPv6 neighbor solicitation packet + being processed 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 + want to change: + + ā€¢ eth.dst exchanged with eth.src + + ā€¢ eth.type = 0x86dd + + ā€¢ ip6.dst copied from ip6.src + + ā€¢ ip6.src copied from nd.target + + ā€¢ icmp6.type = 136 (Neighbor Advertisement) + + ā€¢ nd.target unchanged + + ā€¢ nd.sll = 00:00:00:00:00:00 + + ā€¢ nd.tll copied from eth.dst + + The ND packet has the same VLAN header, if any, as the IPv6 + packet it replaces. + + Prerequisite: nd_ns + + get_nd(P, A); + Parameters: logical port string field P, 128-bit IPv6 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 + 00:00:00:00:00:00 in eth.dst. + + Example: get_nd(outport, ip6.dst); + + put_nd(P, A, E); + Parameters: logical port string field P, 128-bit IPv6 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 + E. + + Example: put_nd(inport, nd.target, nd.tll); + + R = lookup_nd(P, A, M); + Parameters: logical port string field P, 128-bit IP address + field A, 48-bit MAC address field M. + + Result: stored to a 1-bit subfield R. + + Looks up A and M in Pā€™s mac binding table. If an entry is + found, stores 1 in the 1-bit subfield R, else 0. + + Example: reg0[0] = lookup_nd(inport, ip6.src, eth.src); + + R = lookup_nd_ip(P, A); + Parameters: logical port string field P, 128-bit IP address + field A. + + Result: stored to a 1-bit subfield R. + + Looks up A in Pā€™s mac binding table. If an entry is found, + stores 1 in the 1-bit subfield R, else 0. + + Example: reg0[0] = lookup_nd_ip(inport, ip6.src); + + R = put_dhcp_opts(D1 = V1, D2 = V2, ..., Dn = Vn); + Parameters: one or more DHCP option/value pairs, which must + include an offerip option (with code 0). + + Result: stored to a 1-bit subfield R. + + Valid only in the ingress pipeline. + + When this action is applied to a DHCP request packet + (DHCPDISCOVER or DHCPREQUEST), it changes the packet into a + DHCP reply (DHCPOFFER or DHCPACK, respectively), replaces + the options 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 + the packet unchanged and stores 0 in R. + + 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, + 7.7.7.7}); + + R = put_dhcpv6_opts(D1 = V1, D2 = V2, ..., Dn = Vn); + Parameters: one or more DHCPv6 option/value pairs. + + Result: stored to a 1-bit subfield R. + + Valid only in the ingress pipeline. + + When this action is applied to a DHCPv6 request packet, it + changes the packet into a DHCPv6 reply, replaces the 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 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, + dns_server={ae70::1,ae70::2}); + + set_queue(queue_number); + Parameters: Queue number queue_number, in the range 0 to + 61440. + + This is a logical equivalent of the OpenFlow set_queue 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); + + ct_lb; + 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 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_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ā€ + 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 + state is scoped by the logical port when the action is used + in a flow for a logical switch, so overlapping addresses + may be used. Connection tracking state is scoped by the + logical topology when the action is used in a flow for a + router. + + ct_lb_mark; + 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 + purpose. + + R = dns_lookup(); + Parameters: No parameters. + + Result: stored to a 1-bit subfield R. + + Valid only in the ingress pipeline. + + When this action is applied to a valid DNS request (a UDP + packet typically directed to port 53), it attempts to 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 + this behavior with matches and actions in later tables. + + Example: reg0[3] = dns_lookup(); + + Prerequisite: udp + + R = put_nd_ra_opts(D1 = V1, D2 = V2, ..., Dn = Vn); + Parameters: The following IPv6 ND Router Advertisement opā€ + tion/value pairs as defined in RFC 4861. + + ā€¢ addr_mode + + Mandatory parameter which specifies the address mode + flag to be set in the RA flag options field. The + value of this option is a string and the following + values can be defined - "slaac", "dhcpv6_stateful" + and "dhcpv6_stateless". + + ā€¢ slla + + Mandatory parameter which specifies the link-layer + address of the interface from which the Router Adā€ + vertisement is sent. + + ā€¢ mtu + + Optional parameter which specifies the MTU. + + ā€¢ prefix + + Optional parameter which should be specified if the + addr_mode is "slaac" or "dhcpv6_stateless". The + value should be an IPv6 prefix which will be used + for stateless IPv6 address configuration. This opā€ + tion can be defined multiple times. + + Result: stored to a 1-bit subfield R. + + Valid only in the ingress pipeline. + + When this action is applied to an IPv6 Router solicitation + request packet, it changes the packet into an IPv6 Router + Advertisement reply and adds the options specified in the + parameters, and stores 1 in R. + + When this action is applied to a non-IPv6 Router solicitaā€ + tion packet or an invalid IPv6 request packet , it leaves + the packet unchanged and stores 0 in R. + + Example: reg0[3] = put_nd_ra_opts(addr_mode = "slaac", slla + = 00:00:00:00:10:02, prefix = aef0::/64, mtu = 1450); + + set_meter(rate); + set_meter(rate, burst); + Parameters: rate limit int field rate in kbps, burst rate + limits int field burst in kbps. + + This action sets the rate limit for a flow. + + Example: set_meter(100, 1000); + + R = check_pkt_larger(L) + Parameters: packet length L to check for in bytes. + + Result: stored to a 1-bit subfield R. + + This is a logical equivalent of the OpenFlow + check_pkt_larger action. If the packet is larger than the + length specified in L, it stores 1 in the subfield R. + + Example: reg0[6] = check_pkt_larger(1000); + + log(key=value, ...); + Causes ovn-controller to log the packet on the chassis + that processes it. Packet logging currently uses the same + logging mechanism as other Open vSwitch and OVN messages, + which means that whether and where log messages appear + depends on the local logging configuration that can be + configured with ovs-appctl, etc. + + 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ā€ + 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 + severity is not provided, the default is info. + + verdict=value + The verdict for packets matching the flow. The + value must be one of allow, deny, or reject. + + meter=string + An optional rate-limiting meter to be applied to + the logs. The string should reference a name entry + from the Meter table. The only meter action that + is appropriate is drop. + + fwd_group(liveness=bool, childports=port, ...); + Parameters: optional liveness, either true or false, 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 + an OpenFlow group with one bucket for each child port. If + liveness=true is specified, it also integrates the bucket + selection with BFD status on the tunnel interface correā€ + sponding to child port. + + Example: fwd_group(liveness=true, childports="p1", "p2"); + + icmp4 { action; ... }; + icmp4_error { action; ... }; + Temporarily replaces the IPv4 packet being processed by an + ICMPv4 packet and executes each nested action on the ICMPv4 + packet. Actions following these actions, if any, apply to + the original, unmodified packet. + + 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.frag = 0 (not a fragment) + + ā€¢ ip.ttl = 255 + + ā€¢ icmp4.type = 3 (destination unreachable) + + ā€¢ icmp4.code = 1 (host unreachable) + + icmp4_error action is expected to be used to generate an + ICMPv4 packet in response to an error in original IP + packet. When this action generates the ICMPv4 packet, it + also copies the original IP datagram following the ICMPv4 + header as per RFC 1122: 3.2.2. + + Prerequisite: ip4 + + icmp6 { action; ... }; + icmp6_error { action; ... }; + Temporarily replaces the IPv6 packet being processed by an + ICMPv6 packet and executes each nested action on the ICMPv6 + packet. Actions following the icmp6 action, if any, apply + to the original, unmodified packet. + + 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.ttl = 255 + + ā€¢ icmp6.type = 1 (destination unreachable) + + ā€¢ icmp6.code = 1 (administratively prohibited) + + icmp6_error action is expected to be used to generate an + ICMPv6 packet in response to an error in original IPv6 + packet. + + Prerequisite: ip6 + + tcp_reset; + This action transforms the current TCP packet according to + the following pseudocode: + + if (tcp.ack) { + tcp.seq = tcp.ack; + } else { + tcp.ack = tcp.seq + length(tcp.payload); + tcp.seq = 0; + } + tcp.flags = RST; + + Then, the action drops all TCP options and payload data, + and updates the TCP checksum. IP ttl is set to 255. + + Prerequisite: tcp + + reject { action; ... }; + If the 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 + this action implicitly does that. + + trigger_event; + 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 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 + + igmp; + This action sends the packet to ovn-controller for multiā€ + cast snooping. + + Prerequisite: igmp + + bind_vport(V, P); + Parameters: logical port string field V of type virtual, + logical port string field P. + + Binds the virtual logical port V and sets the chassis colā€ + umn and virtual_parent of the table Port_Binding. virā€ā€ + tual_parent is set to P. + + handle_svc_check(P); + Parameters: logical port string field P. + + Handles the service monitor reply received from the VIF of + the logical port P. ovn-controller periodically sends out + the service monitor packets for the services configured in + the Service_Monitor table and this action updates the staā€ + tus of those services. + + Example: handle_svc_check(inport); + + 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 reā€ + ceived from the delegation server + + R = select(N1[=W1], N2[=W2], ...); + Parameters: Integer N1, N2..., with optional weight W1, W2, + ... + + Result: stored to a logical field or subfield R. + + Select from a list of integers N1, N2..., each within the + range 0 ~ 65535, and store the selected one in the field R. + There must be 2 or more integers listed, each with an 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 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 maā€ + chine + + R = chk_lb_hairpin(); + 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 + set to 1. + + R = chk_lb_hairpin_reply(); + This action checks if the packet under consideration is + from one of the backend IP of a load balancer VIP and the + destination IP is the load balancer VIP. If it is so, then + the 1-bit destination register R is set to 1. + + 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ā€ + 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 + this action to advance the packet to the next stage. + + R = check_in_port_sec(); + This action checks if the packet under consideration passes + the inport port security checks. If the packet fails the + port security checks, then 1 is stored in the destination + register R. Else 0 is stored. The port security values to + check are retrieved from the the inport logical port. + + This action should be used in the ingress logical switch + pipeline. + + Example: reg8[0..7] = check_in_port_sec(); + + R = check_out_port_sec(); + 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 + check are retrieved from the the outport logical port. + + This action should be used in the egress logical switch + pipeline. + + Example: reg8[0..7] = check_out_port_sec(); + + commit_ecmp_nh(ipv6); + Parameters: IPv4/IPv6 traffic. + + This action translates to an openflow "learn" action that + inserts two new flows in tables 76 and 77. + + ā€¢ Match on the the 5-tuple and the expected next-hop + mac address in table 76: nw_src=ip0, nw_dst=ip1, + ip_proto,tp_src=l4_port0, + tp_dst=l4_port1,dl_src=ethaddr and set reg9[5]. + + ā€¢ Match on the 5-tuple in table 77: nw_src=ip1, + nw_dst=ip0, ip_proto, tp_src=l4_port1, + tp_dst=l4_port0 and set reg9[5] to 1 + + This action is applied if the packet arrives via ECMP route + or if it is routed via an ECMP route + + R = check_ecmp_nh_mac(); + This action checks if the packet under consideration + 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 + 1-bit destination register R is set to 1. + + commit_lb_aff(vip, backend, proto, timeout); Parameters: + load-balancer virtual ip:port vip, load-balancer backend + ip:port backend, load-balancer protocol proto, affinity + timeout timeout. + + This action translates to an openflow "learn" action that + inserts a new flow in table 78. + + ā€¢ Match on the 4-tuple in table 78: nw_src=ip client, + nw_dst=vip ip, ip_proto, tp_dst=vip port and set + reg9[6] to 1, reg4 and reg8 to backend ip and port + respectively. For IPv6 register xxreg1 is used to + store the backend ip. + + This action is applied for new connections received by a + specific load-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 + 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 + 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 + 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 + 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ā€ā€ + 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. 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 + be used instead. + + tags: map of string-string pairs + Key-value pairs that provide additional information to help ovn- + controller processing the logical flow. Below are the tags used + by ovn-controller. + + in_out_port + In the logical flowā€™s "match" column, if a logical port P + is compared with "inport" and the logical flow is on a + logical switch ingress pipeline, or if P is compared with + "outport" and the logical flow is on a logical switch + egress pipeline, and the expression is combined with + other expressions (if any) using the operator &&, then + the port P should be added as the value in this tag. If + there are multiple logical ports meeting this criteria, + one of them can be added. ovn-controller uses this inforā€ + mation to skip parsing flows that are not needed on the + chassis. Failing to add the tag will affect efficiency, + while adding wrong value will affect correctness. + + controller_meter: optional string + The name of the meter in table Meter to be used for all packets + that the logical flow might send to ovn-controller. + + external_ids : stage-name: optional string + Human-readable name for this flowā€™s stage in the pipeline. + + external_ids : stage-hint: optional string, containing an uuid + UUID of a OVN_Northbound record that caused this logical flow to + 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 + the pipeline. + + Common Columns: + + The overall purpose of these columns is described under Common Columns + at the beginning of this document. + + external_ids: map of string-string pairs +Logical_DP_Group TABLE + 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ā€ā€ + ings + + Details: + datapaths: set of weak reference to Datapath_Bindings + List of Datapath_Binding entries. + +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 + 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 + column. + + Summary: + datapath Datapath_Binding + tunnel_key integer, in range 32,768 to 65,535 + name string + ports set of weak reference to Port_Bindings + + Details: + datapath: Datapath_Binding + The logical datapath in which the multicast group resides. + + tunnel_key: integer, in range 32,768 to 65,535 + The value used to designate this logical egress port in tunnel + encapsulations. An index forces the key to be unique within the + datapath. The unusual range ensures that multicast group IDs do + not overlap with logical port IDs. + + name: string + The logical multicast groupā€™s name. An index forces the name to + be unique within the datapath. Logical flows in the ingress + pipeline may output to the group just as for individual logical + ports, by assigning the groupā€™s name to outport and executing an + output action. + + Multicast group names and logical port names share a single + namespace and thus should not overlap (but the database schema + cannot enforce this). To try to avoid conflicts, ovn-northd uses + names that begin with _MC_. + + ports: set of weak reference to Port_Bindings + The logical ports included in the multicast group. All of these + ports must be in the datapath logical datapath (but the database + schema cannot enforce this). + +Mirror TABLE + Each row in this table represents a mirror that can be used for port + mirroring. These mirrors are referenced by the mirror_rules column in + the Port_Binding table. + + Summary: + name string (must be unique within table) + filter string, one of both, from-lport, or + to-lport + sink string + type string, one of erspan, gre, or local + index integer + external_ids map of string-string pairs + + Details: + name: string (must be unique within table) + Represents the name of the mirror. + + filter: string, one of both, from-lport, or to-lport + The value of this field represents selection criteria of the + mirror. to-lport mirrors the packets coming into logical port. + from-lport mirrors the packets going out of logical port. both + mirrors for both directions. + + sink: string + The value of this field represents the destination/sink of the + mirror. If the type is gre or erspan, the value indicates the + tunnel remote IP (either IPv4 or IPv6). For a type of local, + this field defines a local interface on the OVS integration + bridge to be used as the mirror destination. The interface must + possess external-ids:mirror-id that matches this string. + + type: string, one of erspan, gre, 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. 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 + rate-limiting. + + Summary: + name string (must be unique within table) + unit string, either kbps or pktps + bands set of 1 or more Meter_Bands + + Details: + name: string (must be unique within table) + A name for this meter. + + Names that begin with "__" (two underscores) are reserved for + OVN internal use and should not be added manually. + + unit: string, either kbps or pktps + The unit for rate and burst_rate parameters in the bands entry. + kbps specifies kilobits per second, and pktps specifies packets + per second. + + bands: set of 1 or more Meter_Bands + The bands associated with this meter. Each band specifies a rate + above which the band is to take the action action. If multiple + bandsā€™ rates are exceeded, then the band with the highest rate + among the exceeded bands is selected. + +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 + referenced by the bands column in the Meter table. + + Summary: + action string, must be drop + rate integer, in range 1 to 4,294,967,295 + burst_size integer, in range 0 to 4,294,967,295 + + Details: + action: string, must be drop + The action to execute when this band matches. The only supported + action is drop. + + 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ā€ + 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 + 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ā€ + 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 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 + be unique within table) + load_balancers set of uuids + OVN_Northbound Relationship: + external_ids : logical-switch + optional string, containing an uuid + external_ids : logical-router + optional string, containing an uuid + external_ids : interconn-ts + optional string + Naming: + external_ids : name optional string + external_ids : name2 optional string + Common Columns: + external_ids map of string-string pairs + + Details: + tunnel_key: integer, in range 1 to 16,777,215 (must be unique within + table) + The tunnel key value 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ā€ + tion. + + load_balancers: set of uuids + 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ā€ + 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ā€ā€ + 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ā€ā€ + 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 + stores in this key the value of the same interconn-ts key of the + external_ids column of the corresponding Logical_Switch row in + the OVN_Northbound database. + + Naming: + + ovn-northd copies these from the name fields in the OVN_Northbound + database, either from name and external_ids:neutron:router_name in the + Logical_Router table or from name and external_ids:neutron:network_name + in the Logical_Switch table. + + external_ids : name: optional string + A name for the logical datapath. + + external_ids : name2: optional string + Another name for the logical datapath. + + 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 + 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, + 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ā€ā€ + tionGuide.rst. (The exceptions are for Port_Binding records with type + 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 + whose type is virtual. + + When a chassis shuts down gracefully, it should clean up the chassis + column that it previously had populated. (This is not critical because + resources hosted on the chassis are equally unreachable regardless of + whether their rows are present.) To handle the case where a VM is shut + down abruptly on one chassis, then brought up again on a different one, + ovn-controller/ovn-controller-vtep must overwrite the chassis column + with new information. + + Summary: + Core Features: + datapath Datapath_Binding + logical_port string (must be unique within table) + encap optional weak reference to Encap + additional_encap set of weak reference to Encaps + chassis optional weak reference to Chassis + additional_chassis set of weak reference to Chassis + gateway_chassis set of Gateway_Chassises + ha_chassis_group optional HA_Chassis_Group + up optional boolean + tunnel_key integer, in range 1 to 32,767 + mac set of strings + port_security set of strings + type string + requested_chassis optional weak reference to Chassis + requested_additional_chassis + set of weak reference to Chassis + mirror_rules set of weak reference to Mirrors + Patch Options: + options : peer optional string + nat_addresses set of strings + L3 Gateway Options: + options : peer optional string + options : l3gateway-chassis + optional string + nat_addresses set of strings + Localnet Options: + options : network_name optional string + tag optional integer, in range 1 to 4,095 + L2 Gateway Options: + options : network_name optional string + options : l2gateway-chassis + optional string + tag optional integer, in range 1 to 4,095 + VTEP Options: + options : vtep-physical-switch + optional string + options : vtep-logical-switch + optional string + VMI (or VIF) Options: + options : requested-chassis + optional string + options : activation-strategy + optional string + options : additional-chassis-activated + optional string + options : iface-id-ver optional string + options : qos_min_rate optional string + options : qos_max_rate optional string + options : qos_burst optional string + options : qos_physical_network + optional string + options : qdisc_queue_id optional string, containing an integer, + in range 1 to 61,440 + Distributed Gateway Port Options: + options : chassis-redirect-port + optional string + Chassis Redirect Options: + options : distributed-port optional string + options : redirect-type optional string + options : always-redirect optional string + Nested Containers: + parent_port optional string + tag optional integer, in range 1 to 4,095 + Virtual ports: + virtual_parent optional string + Naming: + external_ids : name optional string + Common Columns: + external_ids map of string-string pairs + + Details: + Core Features: + + datapath: Datapath_Binding + The logical datapath to which the logical port belongs. + + logical_port: string (must be unique within table) + A logical port. For a logical switch port, this is taken from + name in the OVN_Northbound databaseā€™s Logical_Switch_Port table. + For a logical router port, this is taken from name in the + OVN_Northbound databaseā€™s Logical_Router_port table. (This means + that logical switch ports and router port names must not share + names in an OVN deployment.) OVN does not prescribe a particular + format for the logical port ID. + + encap: optional weak reference to Encap + Points to preferred encapsulation configuration to transmit logā€ + ical dataplane packets to this chassis. The entry is reference + to a Encap record. + + additional_encap: set of weak reference to Encaps + Points to preferred encapsulation configuration to transmit logā€ + ical dataplane packets to this additional chassis. The entry is + reference to a Encap record. See also additional_chassis. + + chassis: optional weak reference to Chassis + The meaning of this column depends on the value of the type colā€ + 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 + 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 + 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 + network. + + localport + Always empty. A localport port is present on every chasā€ + sis. + + l3gateway + 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. + + l2gateway + The physical location of this L2 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:l2gateway-chassis column in this table. + + additional_chassis: set of weak reference to Chassis + The meaning of this column is the same as for the chassis. The + column is used to track an additional physical location of the + logical port. Used with regular (empty type) port bindings. + + gateway_chassis: set of Gateway_Chassises + A list of Gateway_Chassis. + + This should only be populated for ports with type set to 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ā€ā€ + 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ā€ā€ + troller. + + tunnel_key: integer, in range 1 to 32,767 + A number that represents the logical port in the key (e.g. STT + key or Geneve TLV) field carried within tunnel protocol packets. + + The tunnel ID must be unique within the scope of a logical dataā€ + path. + + 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ā€ā€ + 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 + 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ā€ā€ + cal_Switch_Port table in the Northbound database. It follows the + same format as that column. + + type: string + A type for this logical port. Logical ports can be used to model + other types of connectivity into an OVN logical switch. The folā€ + lowing types are defined: + + (empty string) + VM (or VIF) interface. + + patch One of a pair of logical ports that act as if connected + by a patch cable. Useful for connecting two logical dataā€ + paths, e.g. to connect a logical router to a logical + switch or to another logical router. + + l3gateway + One of a pair of logical ports that act as if connected + by a patch cable across multiple chassis. Useful for conā€ + 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 + 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 + 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 + hypervisor. + + l2gateway + An L2 connection to a physical network. The chassis this + Port_Binding is bound to will serve as an L2 gateway to + the network named by options:network_name. + + vtep A port to a logical switch on a VTEP gateway chassis. In + order to get this port correctly recognized by the OVN + controller, the options:vtep-physical-switch and 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 + 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 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 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: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ā€ā€ + ror table. + + Patch Options: + + These options apply to logical ports with type of patch. + + options : peer: optional string + The logical_port in the Port_Binding record for the other side + of the patch. The named logical_port must specify this 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 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, + from the chassis where lport resides. Example: 80:fa:5b:06:72:b7 + 158.36.44.22 158.36.44.24 is_chassis_resident("foo1"). This + would result in generation of gratuitous ARPs for IP addresses + 158.36.44.22 and 158.36.44.24 with a MAC address of + 80:fa:5b:06:72:b7 from the chassis where the logical port "foo1" + resides. + + L3 Gateway Options: + + These options apply to logical ports with type of l3gateway. + + options : peer: optional string + The logical_port in the Port_Binding record for the other side + of the ā€™l3gatewayā€™ port. The named logical_port must specify + this logical_port in its own peer option. That is, the two + ā€™l3gatewayā€™ logical ports must have reversed logical_port and + peer values. + + options : l3gateway-chassis: optional string + The chassis in which the port resides. + + nat_addresses: set of strings + MAC address of the l3gateway port followed by a list of SNAT and + DNAT external IP addresses. This is used to send gratuitous ARPs + for SNAT and DNAT external IP addresses via localnet. Example: + 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result + in generation of gratuitous ARPs for IP addresses 158.36.44.22 + and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This + is used in OVS version 2.8 and later versions. + + Localnet Options: + + These options apply to logical ports with type of localnet. + + options : network_name: optional string + Required. 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 + 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 + 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 + traffic. + + L2 Gateway Options: + + These options apply to logical ports with type of l2gateway. + + options : network_name: optional string + 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 + 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 l2gateway port attached, the chassis + that the l2gateway port is bound to must have a bridge mapping + configured to reach the network identified by network_name. + + options : l2gateway-chassis: optional string + Required. The chassis in which the port resides. + + 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 inā€ + coming traffic and is also added to outgoing traffic. + + VTEP Options: + + These options apply to logical ports with type of vtep. + + options : vtep-physical-switch: optional string + Required. The name of the VTEP gateway. + + options : vtep-logical-switch: optional string + Required. A logical switch name connected by the VTEP gateway. + Must be set when type is vtep. + + VMI (or VIF) Options: + + These options apply to logical ports with type having (empty string) + + 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 + more than one chassis. + + If set to a comma separated list, the first entry identifies the + main chassis and the rest are one or more additional chassis + that are allowed to bind the same port. + + When multiple chassis are set for the port, and the logical + switch is connected to an external network through a localnet + port, tunneling is enforced for the port to guarantee delivery + of packets directed to the port to all its locations. This has + MTU implications because the network used for tunneling must + have MTU larger than localnet for stable connectivity. + + options : activation-strategy: optional string + If used with multiple chassis set in requested-chassis, speciā€ + 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 + useful in live migration scenarios for virtual machines. + + options : additional-chassis-activated: optional string + When activation-strategy is set, this option indicates that the + port was activated using the strategy specified. + + options : iface-id-ver: optional string + If set, this port will be bound by ovn-controller only if this + same key and value is configured in the external_ids column in + the Open_vSwitch databaseā€™s Interface table. + + options : qos_min_rate: optional string + If set, indicates the minimum guaranteed rate available for data + sent from this interface, in bit/s. + + options : qos_max_rate: optional string + 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 : 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. + + Distributed Gateway Port Options: + + These options apply to the distributed parent ports of logical ports + with type of chasssisredirect. + + options : chassis-redirect-port: optional string + The name of the chassis redirect port derived from this port if + this port is a distributed parent of a chassis redirect port. + + Chassis Redirect Options: + + These options apply to logical ports with type of chassisredirect. + + options : distributed-port: optional string + The name of the distributed port for which this chassisredirect + port represents a particular instance. + + options : redirect-type: optional string + The value is copied from the column options in the OVN_Northā€ + bound databaseā€™s Logical_Router_Port table for the distributed + parent of this port. + + options : always-redirect: optional string + A boolean option that is set to true if the distributed parent + of this chassis redirect port does not need distributed processā€ + ing. + + Nested Containers: + + These columns support containers nested within a VM. Specifically, they + are used when type is empty and logical_port identifies the interface + of a container spawned inside a VM. They are empty for containers or + VMs that run directly on a hypervisor. + + parent_port: optional string + This is taken from parent_name in the OVN_Northbound databaseā€™s + Logical_Switch_Port table. + + tag: optional integer, in range 1 to 4,095 + Identifies the VLAN tag in the network traffic associated with + that containerā€™s network interface. + + This column is used for a different purpose when type is localā€ā€ + net (see Localnet Options, above) or l2gateway (see L2 Gateway + Options, above). + + Virtual ports: + + virtual_parent: optional string + 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ā€ + cutes this action with its chassis id. + + ovn-controller sets this column only if the type is "virtual". + + Naming: + + external_ids : name: optional string + For a logical switch port, ovn-northd copies this from 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 + this key. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + + The ovn-northd program populates this column with all entries + into the external_ids column of the Logical_Switch_Port and 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 + machines are usually populated statically into the Port_Binding table. + + 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 + 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 + 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. + 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 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 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 + 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 + the MAC_Binding table. + + 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 diā€ + rectly to the bound Ethernet address. + + Summary: + logical_port string + ip string + mac string + timestamp integer + datapath Datapath_Binding + + Details: + logical_port: string + The logical port on which the binding was discovered. + + ip: string + The bound IP address. + + mac: string + The Ethernet address to which the IP is bound. + + timestamp: integer + The timestamp in msec when the MAC binding was added or updated. + Records that existed before this column will have 0. + + datapath: Datapath_Binding + 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 + 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, + ipv4, static_routes, str, uint16, uint32, + or uint8 + + Details: + name: string + Name of the DHCP option. + + Example. name="router" + + code: integer, in range 0 to 254 + DHCP option code for the DHCP option as defined in the RFC 2132. + + Example. code=3 + + type: string, one of bool, domains, host_id, ipv4, static_routes, str, + uint16, uint32, or uint8 + Data type of the DHCP option code. + + value: bool + This indicates that the value of the DHCP option is a + bool. + + Example. "name=ip_forward_enable", "code=19", + "type=bool". + + put_dhcp_opts(..., ip_forward_enable = 1,...) + + value: uint8 + This indicates that the value of the DHCP option is an + unsigned int8 (8 bits) + + Example. "name=default_ttl", "code=23", "type=uint8". + + put_dhcp_opts(..., default_ttl = 50,...) + + value: uint16 + This indicates that the value of the DHCP option is an + unsigned int16 (16 bits). + + Example. "name=mtu", "code=26", "type=uint16". + + put_dhcp_opts(..., mtu = 1450,...) + + value: uint32 + This indicates that the value of the DHCP option is an + unsigned int32 (32 bits). + + Example. "name=lease_time", "code=51", "type=uint32". + + put_dhcp_opts(..., lease_time = 86400,...) + + value: ipv4 + This indicates that the value of the DHCP option is an + IPv4 address or addresses. + + Example. "name=router", "code=3", "type=ipv4". + + put_dhcp_opts(..., router = 10.0.0.1,...) + + Example. "name=dns_server", "code=6", "type=ipv4". + + put_dhcp_opts(..., dns_server = {8.8.8.8 7.7.7.7},...) + + value: static_routes + This indicates that the value of the DHCP option contains + a pair of IPv4 route and next hop addresses. + + Example. "name=classless_static_route", "code=121", + "type=static_routes". + + put_dhcp_opts(..., classless_static_route = + {30.0.0.0/24,10.0.0.4,0.0.0.0/0,10.0.0.1}...) + + value: str + This indicates that the value of the DHCP option is a + string. + + Example. "name=host_name", "code=12", "type=str". + + value: host_id + This indicates that the value of the DHCP option is a + host_id. It can either be a host_name or an IP address. + + Example. "name=tftp_server", "code=66", "type=host_id". + + value: domains + This indicates that the value of the DHCP option is a 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 deā€ + fined here. + + Summary: + name string + code integer, in range 0 to 254 + type string, one of ipv6, mac, or str + + Details: + name: string + Name of the DHCPv6 option. + + Example. name="ia_addr" + + code: integer, in range 0 to 254 + DHCPv6 option code for the DHCPv6 option as defined in the apā€ + propriate RFC. + + Example. code=3 + + type: string, one of ipv6, mac, or str + Data type of the DHCPv6 option code. + + value: ipv6 + This indicates that the value of the DHCPv6 option is an + IPv6 address(es). + + Example. "name=ia_addr", "code=5", "type=ipv6". + + put_dhcpv6_opts(..., ia_addr = ae70::4,...) + + value: str + This indicates that the value of the DHCPv6 option is a + string. + + Example. "name=domain_search", "code=24", "type=str". + + put_dhcpv6_opts(..., domain_search = ovn.domain,...) + + value: mac + This indicates that the value of the DHCPv6 option is a + MAC address. + + Example. "name=server_id", "code=2", "type=mac". + + put_dhcpv6_opts(..., server_id = 01:02:03:04L05:06,...) +Connection TABLE + Configuration for a database connection to an Open vSwitch database + (OVSDB) client. + + This table primarily configures the Open vSwitch database server + (ovsdb-server). + + The Open vSwitch database server can initiate and maintain active conā€ + nections to remote clients. It can also listen for database connecā€ + tions. + + Summary: + Core Features: + target string (must be unique within table) + read_only boolean + role string + Client Failure Detection and Handling: + max_backoff optional integer, at least 1,000 + inactivity_probe optional integer + Status: + is_connected boolean + status : last_error optional string + status : state optional string, one of ACTIVE, BACKOFF, + CONNECTING, IDLE, or VOID + status : sec_since_connect optional string, containing an integer, + at least 0 + status : sec_since_disconnect + optional string, containing an integer, + at least 0 + status : locks_held optional string + status : locks_waiting optional string + status : locks_lost optional string + status : n_connections optional string, containing an integer, + at least 2 + status : bound_port optional string, containing an integer + Common Columns: + external_ids map of string-string pairs + other_config map of string-string pairs + + Details: + Core Features: + + target: string (must be unique within table) + Connection methods for clients. + + The following connection methods are currently supported: + + ssl:host[:port] + 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 + built as part of Open vSwitch. + + tcp:host[:port] + 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 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. + + 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ā€ + 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 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 + unique. Duplicate target values yield unspecified results. + + read_only: boolean + true to restrict these connections to read-only transactions, + false to allow them to modify the database. + + role: string + String containing role name for this connection entry. + + Client Failure Detection and Handling: + + max_backoff: optional integer, at least 1,000 + Maximum number of milliseconds to wait between connection 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 + inactivity probes. + + Status: + + Key-value pair of is_connected is always updated. Other key-value pairs + in the status columns may be updated depends on the target type. + + When target specifies a connection method that listens for inbound conā€ + 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ā€ + ted. + + is_connected: boolean + true if currently connected to this client, false otherwise. + + status : last_error: optional string + A human-readable description of the last error on the connection + to the manager; i.e. strerror(errno). This key will exist only + if an error has occurred. + + status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING, + IDLE, or VOID + The state of the connection to the manager: + + VOID Connection is disabled. + + BACKOFF + Attempting to reconnect at an increasing period. + + CONNECTING + Attempting to connect. + + ACTIVE Connected, remote host responsive. + + IDLE Connection is idle. Waiting for response to keep-alive. + + These values may change in the future. They are provided only + for human consumption. + + status : sec_since_connect: optional string, containing an integer, at + least 0 + The amount of time since this client last successfully connected + to the database (in seconds). Value is empty if client has never + successfully been connected. + + status : sec_since_disconnect: optional string, containing an integer, + at least 0 + The amount of time since this client last disconnected from the + database (in seconds). Value is empty if client has never 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 + 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ā€ + 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 + locks have been stolen from this connection. + + status : n_connections: optional string, containing an integer, at + least 2 + When target specifies a connection method that listens for 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 + available port.) + + Common Columns: + + The overall purpose of these columns is described under Common Columns + at the beginning of this document. + + external_ids: map of string-string pairs + + other_config: map of string-string pairs +SSL TABLE + SSL configuration for ovn-sb database access. + + Summary: + private_key string + certificate string + ca_cert string + bootstrap_ca_cert boolean + ssl_protocols string + ssl_ciphers string + Common Columns: + external_ids map of string-string pairs + + Details: + private_key: string + Name of a PEM file containing the private key used as the + switchā€™s identity for SSL connections to the controller. + + certificate: string + Name of a PEM file containing a certificate, signed by the cerā€ + tificate authority (CA) used by the controller and manager, that + certifies the switchā€™s private key, identifying a trustworthy + switch. + + ca_cert: string + Name of a PEM file containing the CA certificate used to verify + that the switch is connected to a trustworthy controller. + + bootstrap_ca_cert: boolean + If set to true, then Open vSwitch will attempt to obtain the CA + certificate from the controller on its first SSL connection and + save it to the named PEM file. If it is successful, it will 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 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 + omitted is HIGH:!aNULL:!MD5. + + Common Columns: + + The overall purpose of these columns is described under Common Columns + at the beginning of this document. + + external_ids: map of string-string pairs +DNS TABLE + 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 + Common Columns: + external_ids map of string-string pairs + + Details: + records: map of string-string pairs + Key-value pair of DNS records with DNS query name as the key and + a string of IP address(es) separated by comma or space as the + value. ovn-northd stores the DNS query name in all lowercase in + order to facilitate case-insensitive lookups. + + Example: "vm1.ovn.org" = "10.0.0.4 aef0::4" + + datapaths: set of 1 or more Datapath_Bindings + The DNS records defined in the column records will be applied + only to the DNS queries originating from the datapaths defined + in this column. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +RBAC_Role TABLE + Role table for role-based access controls. + + Summary: + name string + 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ā€ā€ + tion table. + + permissions: map of string-weak reference to RBAC_Permission pairs + A mapping of table names to rows in the RBAC_Permission table. + +RBAC_Permission TABLE + Permissions table for role-based access controls. + + Summary: + table string + authorization set of strings + insert_delete boolean + update set of strings + + Details: + table: string + Name of table to which this row applies. + + authorization: set of strings + Set of strings identifying columns and column:key pairs to be + compared with client ID. At least one match is required in order + to be authorized. A zero-length string is treated as a special + value indicating all clients should be considered authorized. + + insert_delete: boolean + When "true", row insertions and authorized row deletions are + permitted. + + update: set of strings + 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 + redirected to a chassis, or a set of them in high availability configuā€ + rations. + + Summary: + name string (must be unique within table) + chassis optional weak reference to Chassis + priority integer, in range 0 to 32,767 + options map of string-string pairs + Common Columns: + external_ids map of string-string pairs + + Details: + name: string (must be unique within table) + Name of the Gateway_Chassis. + + A suggested, but not required naming convention is + ${port_name}_${chassis_name}. + + chassis: optional weak reference to Chassis + The Chassis to which we send the traffic. + + priority: integer, in range 0 to 32,767 + This is the priority the specific Chassis among all Gateā€ + way_Chassis belonging to the same Port_Binding. + + options: map of string-string pairs + Reserved for future use. + + Common Columns: + + The overall purpose of these columns is described under Common Columns + at the beginning of this document. + + external_ids: map of string-string pairs +HA_Chassis TABLE + Summary: + chassis optional weak reference to Chassis + priority integer, in range 0 to 32,767 + Common Columns: + external_ids map of string-string pairs + + Details: + chassis: optional weak reference to Chassis + The Chassis which provides the HA functionality. + + priority: integer, in range 0 to 32,767 + Priority of the HA chassis. Chassis with highest priority will + be the master in the HA chassis group. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +HA_Chassis_Group TABLE + Table representing a group of chassis which can provide High 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 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 + group. + + Summary: + name string (must be unique within table) + ha_chassis set of HA_Chassises + ref_chassis set of weak reference to Chassis + Common Columns: + external_ids map of string-string pairs + + Details: + name: string (must be unique within table) + Name of the HA_Chassis_Group. Name should be unique. + + ha_chassis: set of HA_Chassises + A list of HA_Chassis which belongs to this group. + + ref_chassis: set of weak reference to Chassis + The set of Chassis that reference this HA chassis group. To 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: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +Controller_Event TABLE + 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 + + Summary: + event_type string, must be empty_lb_backends + event_info map of string-string pairs + chassis optional weak reference to Chassis + seq_num integer + + Details: + event_type: string, must be empty_lb_backends + Event type occurred + + event_info: map of string-string pairs + Key-value pairs used to specify event info to the CMS. Possible + values are: + + ā€¢ vip: VIP reported for the empty_lb_backends event + + ā€¢ protocol: Transport protocol reported for the + empty_lb_backends event + + ā€¢ load_balancer: UUID of the load balancer reported for the + empty_lb_backends event + + chassis: optional weak reference to Chassis + This column is a Chassis record to identify the chassis that has + managed a given event. + + seq_num: integer + Event sequence number. Global counter for controller generated + events. It can be used by the CMS to detect possible duplication + of the same event. +IP_Multicast TABLE + IP Multicast configuration options. For now only applicable to IGMP. + + Summary: + datapath weak reference to Datapath_Binding (must + be unique within table) + enabled optional boolean + querier optional boolean + table_size optional integer + idle_timeout optional integer + query_interval optional integer + seq_no integer + Querier configuration options: + eth_src string + ip4_src string + ip6_src string + query_max_resp optional integer + + Details: + datapath: weak reference to Datapath_Binding (must be unique within taā€ + ble) + Datapath_Binding entry for which these configuration options are + defined. + + enabled: optional boolean + Enables/disables multicast snooping. Default: disabled. + + querier: optional boolean + 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. Deā€ + fault: 2048 groups per datapath. + + idle_timeout: optional integer + Configures the idle timeout (in seconds) for IP multicast groups + if multicast snooping is enabled. Default: 300 seconds. + + query_interval: optional integer + Configures the interval (in seconds) for sending multicast + queries if snooping and querier are enabled. Default: idle_timeā€ā€ + out/2 seconds. + + seq_no: integer + 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 + following columns to determine field values in IGMP/MLD queries that it + originates: + + eth_src: string + Source Ethernet address. + + ip4_src: string + Source IPv4 address. + + ip6_src: string + Source IPv6 address. + + query_max_resp: optional integer + Value (in seconds) to be used as "max-response" field in multiā€ + cast queries. Default: 1 second. + +IGMP_Group TABLE + Contains learned IGMP groups indexed by address/datapath/chassis. + + Summary: + address string + datapath optional weak reference to Datapath_Bindā€ā€ + ing + chassis optional weak reference to Chassis + ports set of weak reference to Port_Bindings + + Details: + address: string + Destination IPv4 address for the IGMP group. + + datapath: optional weak reference to Datapath_Binding + Datapath to which this IGMP group belongs. + + chassis: optional weak reference to Chassis + Chassis to which this IGMP group belongs. + + ports: set of weak reference to Port_Bindings + The destination port bindings for this IGMP group. + +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 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 + check feature offered to the CMS through the northbound database. + + Summary: + Configuration: + ip string + protocol optional string, either tcp or udp + port integer, in range 0 to 65,535 + logical_port string + src_mac string + src_ip 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, + or online + Common Columns: + external_ids map of string-string pairs + + Details: + Configuration: + + ovn-northd sets these columns and values to configure the service moniā€ + tor. + + ip: string + IP of the service to be monitored. Only IPv4 is supported. + + protocol: optional string, either tcp or udp + The protocol of the service. + + port: integer, in range 0 to 65,535 + The TCP or UDP port of the service. + + logical_port: string + The VIF of the logical port on which the service is running. The + ovn-controller that binds this logical_port monitors the service + by sending periodic monitor packets. + + src_mac: string + Source Ethernet address to use in the service monitor packet. + + src_ip: string + Source IPv4 address to use in the service monitor packet. + + options : interval: optional string, containing an integer + The interval, in seconds, between service monitor checks. + + options : timeout: optional string, containing an integer + The time, in seconds, after which the service monitor check + times out. + + options : success_count: optional string, containing an integer + The number of successful checks after which the service is conā€ + sidered online. + + options : failure_count: optional string, containing an integer + The number of failure checks after which the service is considā€ + ered offline. + + Status Reporting: + + The ovn-controller on the chassis that hosts the logical_port updates + this column to report the serviceā€™s status. + + status: optional string, one of error, offline, or online + For TCP service, ovn-controller sends a SYN to the service and + expects an ACK response to consider the service to be online. + + For UDP service, ovn-controller sends a UDP packet to the serā€ + vice and doesnā€™t expect any reply. If it receives an ICMP reply, + then it considers the service to be offline. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +Load_Balancer TABLE + Each row represents a load balancer. + + Summary: + name string + vips map of string-string pairs + protocol optional string, one of sctp, tcp, or udp + datapaths set of Datapath_Bindings + datapath_group optional Logical_DP_Group + Load_Balancer options: + options : hairpin_snat_ip optional string + options : hairpin_orig_tuple + optional string, either true or false + Common Columns: + external_ids map of string-string pairs + + 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ā€ + 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 + 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 + 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 + in a group. + + Load_Balancer options: + + options : hairpin_snat_ip: optional string + IP to be used as source IP for packets that have been hair- + pinned after load balancing. This value is automatically popuā€ + lated by ovn-northd. + + 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 + packets are stored in registers reg1, reg2, xxreg1. + + Common Columns: + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + +BFD TABLE + Contains BFD parameter for ovn-controller bfd configuration. + + Summary: + Configuration: + src_port integer, in range 49,152 to 65,535 + disc integer + logical_port string + dst_ip string + min_tx integer + min_rx integer + detect_mult integer + options map of string-string pairs + external_ids map of string-string pairs + Status Reporting: + status string, one of admin_down, down, init, or + up + + Details: + Configuration: + + src_port: integer, in range 49,152 to 65,535 + udp source port used in bfd control packets. The source port + MUST be in the range 49152 through 65535 (RFC5881 section 4). + + disc: integer + A unique, nonzero discriminator value generated by the transmitā€ + ting system, used to demultiplex multiple BFD sessions between + the same pair of systems. + + logical_port: string + OVN logical port when BFD engine is running. + + dst_ip: string + BFD peer IP address. + + min_tx: integer + This is the minimum interval, in milliseconds, that the local + system would like to use when transmitting BFD Control packets, + less any jitter applied. The value zero is reserved. + + min_rx: integer + This is the minimum interval, in milliseconds, between received + BFD Control packets that this system is capable of supporting, + less any jitter applied by the sender. If this value is zero, + the transmitting system does not want the remote system to send + any periodic BFD Control packets. + + detect_mult: integer + Detection time multiplier. The negotiated transmit interval, + multiplied by this value, provides the Detection Time for the + receiving system in Asynchronous mode. + + options: map of string-string pairs + Reserved for future use. + + external_ids: map of string-string pairs + See External IDs at the beginning of this document. + + Status Reporting: + + status: string, one of admin_down, down, init, or up + BFD port logical states. Possible values are: + + ā€¢ admin_down + + ā€¢ down + + ā€¢ init + + ā€¢ up +FDB TABLE + This table is primarily used to learn the MACs observed on a VIF (or a + localnet port with ā€™localnet_learn_fdbā€™ enabled) which belongs to a + Logical_Switch_Port record in OVN_Northbound whose port security is + disabled and ā€™unknownā€™ address set. If port security is disabled on a + Logical_Switch_Port record, OVN should allow traffic with any source + mac from the VIF. This table will be used to deliver a packet to the + VIF, If a packetā€™s eth.dst is learnt. + + Summary: + mac string + dp_key integer, in range 1 to 16,777,215 + port_key integer, in range 1 to 16,777,215 + + Details: + mac: string + The learnt mac address. + + dp_key: integer, in range 1 to 16,777,215 + The key of the datapath on which this FDB was learnt. + + port_key: integer, in range 1 to 16,777,215 + The key of the port binding on which this FDB was learnt. + +Static_MAC_Binding TABLE + Each record represents a Static_MAC_Binding entry for a logical router. + + Summary: + logical_port string + ip string + mac string + override_dynamic_mac boolean + datapath Datapath_Binding + + Details: + logical_port: string + The logical router port for the binding. + + ip: string + The bound IP address. + + mac: string + The Ethernet address to which the IP is bound. + + override_dynamic_mac: boolean + Override dynamically learnt MACs. + + datapath: Datapath_Binding + The logical datapath to which the logical router port belongs. + +Chassis_Template_Var TABLE + Each record represents the set of template variable instantiations for + a given chassis and is populated by ovn-northd from the contents of the + OVN_Northbound.Chassis_Template_Var table. + + Summary: + chassis string (must be unique within table) + variables map of string-string pairs + + Details: + chassis: string (must be unique within table) + The chassis this set of variable values applies to. + + variables: map of string-string pairs + The set of variable values for a given chassis. + +Open vSwitch 23.06.3 DB Schema 20.27.2 ovn-sb(5) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-sbctl.8 b/src/static/support/dist-docs-branch-23.06/ovn-sbctl.8 new file mode 100644 index 00000000..64bd47f5 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-sbctl.8 @@ -0,0 +1,658 @@ +'\" p +.\" -*- nroff -*- +.TH "ovn-sbctl" 8 "ovn-sbctl" "OVN 23\[char46]06\[char46]3" "OVN Manual" +.fp 5 L CR \\" Make fixed-width font available as \\fL. +.de TQ +. br +. ns +. TP "\\$1" +.. +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +.de SU +. PP +. I "\\$1" +.. +.PP +.SH "NAME" +.PP +.PP +ovn-sbctl \- Open Virtual Network southbound db management utility +.SH "SYNOPSIS" +.PP +\fBovn\-sbctl\fR [\fIoptions\fR] \fIcommand\fR [\fIarg\fR\[char46]\[char46]\[char46]] +.SH "DESCRIPTION" +.PP +.PP +The \fBovn\-sbctl\fR program configures the \fBOVN_Southbound\fR database by providing a high-level interface to its configuration database\[char46] See \fBovn\-sb\fR(5) for comprehensive documentation of the database schema\[char46] +.PP +.PP +\fBovn\-sbctl\fR connects to an \fBovsdb\-server\fR process that maintains an OVN_Southbound configuration database\[char46] Using this connection, it queries and possibly applies changes to the database, depending on the supplied commands\[char46] +.PP +.PP +\fBovn\-sbctl\fR can perform any number of commands in a single run, implemented as a single atomic transaction against the database\[char46] +.PP +.PP +The \fBovn\-sbctl\fR command line begins with global options (see \fBOPTIONS\fR below for details)\[char46] The global options are followed by one or more commands\[char46] Each command should begin with \fB\-\-\fR by itself as a command-line argument, to separate it from the following commands\[char46] (The \fB\-\-\fR before the first command is optional\[char46]) The command itself starts with command-specific options, if any, followed by the command name and any arguments\[char46] +.SH "DAEMON MODE" +.PP +.PP +When it is invoked in the most ordinary way, \fBovn\-sbctl\fR 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\(cqs reply\[char46] In common interactive use, this is fine, but if the database is large, the step in which \fBovn\-sbctl\fR retrieves a partial copy of the database can take a long time, which yields poor performance overall\[char46] +.PP +.PP +To improve performance in such a case, \fBovn\-sbctl\fR offers a \(dqdaemon mode,\(dq in which the user first starts \fBovn\-sbctl\fR running in the background and afterward uses the daemon to execute operations\[char46] Over several \fBovn\-sbctl\fR command invocations, this performs better overall because it retrieves a copy of the database only once at the beginning, not once per program run\[char46] +.PP +.PP +Use the \fB\-\-detach\fR option to start an \fBovn\-sbctl\fR daemon\[char46] With this option, \fBovn\-sbctl\fR prints the name of a control socket to stdout\[char46] The client should save this name in environment variable \fBOVN_SB_DAEMON\fR\[char46] Under the Bourne shell this might be done like this: +.PP +.nf +\fL +.br +\fL export OVN_SB_DAEMON=$(ovn\-sbctl \-\-pidfile \-\-detach) +.br +\fL \fR +.fi +.PP +.PP +When \fBOVN_SB_DAEMON\fR is set, \fBovn\-sbctl\fR automatically and transparently uses the daemon to execute its commands\[char46] +.PP +.PP +When the daemon is no longer needed, kill it and unset the environment variable, e\[char46]g\[char46]: +.PP +.nf +\fL +.br +\fL kill $(cat $OVN_RUNDIR/ovn\-sbctl\[char46]pid) +.br +\fL unset OVN_SB_DAEMON +.br +\fL \fR +.fi +.PP +.PP +When using daemon mode, an alternative to the \fBOVN_SB_DAEMON\fR environment variable is to specify a path for the Unix socket\[char46] When starting the ovn-sbctl daemon, specify the \fB\-u\fR option with a full path to the location of the socket file\[char46] Here is an exmple: +.PP +.nf +\fL +.br +\fL ovn\-sbctl \-\-detach \-u /tmp/mysock\[char46]ctl +.br +\fL \fR +.fi +.PP +.PP +Then to connect to the running daemon, use the \fB\-u\fR option with the full path to the socket created when the daemon was started: +.PP +.nf +\fL +.br +\fL ovn\-sbctl \-u /tmp/mysock\[char46]ctl show +.br +\fL \fR +.fi +.ST "Daemon Commands" +.PP +.PP +Daemon mode is internally implemented using the same mechanism used by \fBovn\-appctl\fR\[char46] One may also use \fBovn\-appctl\fR directly with the following commands: +.RS +.TP +\fBrun\fR [\fIoptions\fR] \fIcommand\fR [\fIarg\fR\[char46]\[char46]\[char46]] [\fB\-\-\fR [\fIoptions\fR] \fIcommand\fR [\fIarg\fR\[char46]\[char46]\[char46]] \[char46]\[char46]\[char46]] +Instructs the daemon process to run one or more \fBovn\-sbctl\fR commands described above and reply with the results of running these commands\[char46] Accepts the \fB\-\-no\-wait\fR, \fB\-\-wait\fR, \fB\-\-timeout\fR, \fB\-\-dry\-run\fR, \fB\-\-oneline\fR, and the options described under \fBTable Formatting Options\fR in addition to the the command-specific options\[char46] +.TP +\fBexit\fR +Causes \fBovn\-sbctl\fR to gracefully terminate\[char46] +.RE +.SH "OPTIONS" +.PP +.PP +The options listed below affect the behavior of \fBovn\-sbctl\fR as a whole\[char46] Some individual commands also accept their own options, which are given just before the command name\[char46] If the first command on the command line has options, then those options must be separated from the global options by \fB\-\-\fR\[char46] +.PP +.PP +\fBovn\-sbctl\fR also accepts options from the \fBOVN_SBCTL_OPTIONS\fR environment variable, in the same format as on the command line\[char46] Options from the command line override those in the environment\[char46] +.RS +.TP +\fB\-\-db\fR \fIdatabase\fR +The OVSDB database remote to contact\[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, but this default is unlikely to be useful outside of single-machine OVN test environments\[char46] +.TP +\fB\-\-leader\-only\fR +.TQ .5in +\fB\-\-no\-leader\-only\fR +By default, or with \fB\-\-leader\-only\fR, when the database server is a clustered database, \fBovn\-sbctl\fR will avoid servers other than the cluster leader\[char46] This ensures that any data that \fBovn\-sbctl\fR reads and reports is up-to-date\[char46] With \fB\-\-no\-leader\-only\fR, \fBovn\-sbctl\fR 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 \fB\-\-no\-leader\-only\fR)\[char46] Refer to \fBUnderstanding Cluster Consistency\fR in \fBovsdb\fR(7) for more information\[char46] +.TP +\fB\-\-shuffle\-remotes\fR +.TQ .5in +\fB\-\-no\-shuffle\-remotes\fR +By default, or with \fB\-\-shuffle\-remotes\fR, when there are multiple remotes specified in the OVSDB connection string specified by \fB\-\-db\fR or the \fBOVN_SB_DB\fR environment variable, the order of the remotes will be shuffled before the client tries to connect\[char46] The remotes will be shuffled only once to a new order before the first connection attempt\[char46] The following retries, if any, will follow the same new order\[char46] The default behavior is to make sure clients of a clustered database can distribute evenly to all members of the cluster\[char46] With \fB\-\-no\-shuffle\-remotes\fR, \fBovn\-sbctl\fR will use the original order specified in the connection string to connect\[char46] This allows user to specify the preferred order, which is particularly useful for testing\[char46] +.TP +\fB\-\-no\-syslog\fR +By default, \fBovn\-sbctl\fR logs its arguments and the details of any changes that it makes to the system log\[char46] This option disables this logging\[char46] +.IP +This option is equivalent to \fB\-\-verbose=sbctl:syslog:warn\fR\[char46] +.TP +\fB\-\-oneline\fR +Modifies the output format so that the output for each command is printed on a single line\[char46] New-line characters that would otherwise separate lines are printed as \efB\e\en\efR, and any instances of \efB\e\e\efR that would otherwise appear in the output are doubled\[char46] Prints a blank line for each command that has no output\[char46] This option does not affect the formatting of output from the \fBlist\fR or \fBfind\fR commands; see \fBTable Formatting Options\fR below\[char46] +.TP +\fB\-\-dry\-run\fR +Prevents \fBovn\-sbctl\fR from actually modifying the database\[char46] +.TP +\fB\-t \fIsecs\fB\fR +.TQ .5in +\fB\-\-timeout=\fIsecs\fB\fR +By default, or with a \fIsecs\fR of \fB0\fR, \fBovn\-sbctl\fR waits forever for a response from the database\[char46] This option limits runtime to approximately \fIsecs\fR seconds\[char46] If the timeout expires, \fBovn\-sbctl\fR will exit with a \fBSIGALRM\fR signal\[char46] (A timeout would normally happen only if the database cannot be contacted, or if the system is overloaded\[char46]) +.RE +.SS "Daemon Options" +.TP +\fB\-\-pidfile\fR[\fB=\fR\fIpidfile\fR] +Causes a file (by default, \fB\fIprogram\fB\[char46]pid\fR) to be created indicating the PID of the running process\[char46] If the \fIpidfile\fR argument is not specified, or if it does not begin with \fB/\fR, then it is created in \fB\fR\[char46] +.IP +If \fB\-\-pidfile\fR is not specified, no pidfile is created\[char46] +.TP +\fB\-\-overwrite\-pidfile\fR +By default, when \fB\-\-pidfile\fR is specified and the specified pidfile already exists and is locked by a running process, the daemon refuses to start\[char46] Specify \fB\-\-overwrite\-pidfile\fR to cause it to instead overwrite the pidfile\[char46] +.IP +When \fB\-\-pidfile\fR is not specified, this option has no effect\[char46] +.TP +\fB\-\-detach\fR +Runs this program as a background process\[char46] 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 \fB\-\-no\-chdir\fR is specified)\[char46] After the child completes its initialization, the parent exits\[char46] +.TP +\fB\-\-monitor\fR +Creates an additional process to monitor this program\[char46] If it dies due to a signal that indicates a programming error (\fBSIGABRT\fR, \fBSIGALRM\fR, \fBSIGBUS\fR, \fBSIGFPE\fR, \fBSIGILL\fR, \fBSIGPIPE\fR, \fBSIGSEGV\fR, \fBSIGXCPU\fR, or \fBSIGXFSZ\fR) then the monitor process starts a new copy of it\[char46] If the daemon dies or exits for another reason, the monitor process exits\[char46] +.IP +This option is normally used with \fB\-\-detach\fR, but it also functions without it\[char46] +.TP +\fB\-\-no\-chdir\fR +By default, when \fB\-\-detach\fR is specified, the daemon changes its current working directory to the root directory after it detaches\[char46] Otherwise, invoking the daemon from a carelessly chosen directory would prevent the administrator from unmounting the file system that holds that directory\[char46] +.IP +Specifying \fB\-\-no\-chdir\fR suppresses this behavior, preventing the daemon from changing its current working directory\[char46] 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\[char46] +.IP +This option has no effect when \fB\-\-detach\fR is not specified\[char46] +.TP +\fB\-\-no\-self\-confinement\fR +By default this daemon will try to self-confine itself to work with files under well-known directories determined at build time\[char46] 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\[char46] Note that in contrast to other access control implementations that are typically enforced from kernel-space (e\[char46]g\[char46] 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 additional layer of security\[char46] +.TP +\fB\-\-user=\fR\fIuser\fR\fB:\fR\fIgroup\fR +Causes this program to run as a different user specified in \fIuser\fR\fB:\fR\fIgroup\fR, thus dropping most of the root privileges\[char46] Short forms \fIuser\fR and \fB:\fR\fIgroup\fR are also allowed, with current user or group assumed, respectively\[char46] Only daemons started by the root user accepts this argument\[char46] +.IP +On Linux, daemons will be granted \fBCAP_IPC_LOCK\fR and \fBCAP_NET_BIND_SERVICES\fR before dropping root privileges\[char46] Daemons that interact with a datapath, such as \fBovs\-vswitchd\fR, will be granted three additional capabilities, namely \fBCAP_NET_ADMIN\fR, \fBCAP_NET_BROADCAST\fR and \fBCAP_NET_RAW\fR\[char46] The capability change will apply even if the new user is root\[char46] +.IP +On Windows, this option is not currently supported\[char46] For security reasons, specifying this option will cause the daemon process not to start\[char46] +.SS "Logging options" +.TP +\fB\-v\fR[\fIspec\fR] +.TQ .5in +\fB\-\-verbose=\fR[\fIspec\fR] +Sets logging levels\[char46] Without any \fIspec\fR, sets the log level for every module and destination to \fBdbg\fR\[char46] Otherwise, \fIspec\fR is a list of words separated by spaces or commas or colons, up to one from each category below: +.RS +.IP \(bu +A valid module name, as displayed by the \fBvlog/list\fR command on \fBovs\-appctl\fR(8), limits the log level change to the specified module\[char46] +.IP \(bu +\fBsyslog\fR, \fBconsole\fR, or \fBfile\fR, to limit the log level change to only to the system log, to the console, or to a file, respectively\[char46] (If \fB\-\-detach\fR is specified, the daemon closes its standard file descriptors, so logging to the console will have no effect\[char46]) +.IP +On Windows platform, \fBsyslog\fR is accepted as a word and is only useful along with the \fB\-\-syslog\-target\fR option (the word has no effect otherwise)\[char46] +.IP \(bu +\fBoff\fR, \fBemer\fR, \fBerr\fR, \fBwarn\fR, \fBinfo\fR, or \fBdbg\fR, to control the log level\[char46] Messages of the given severity or higher will be logged, and messages of lower severity will be filtered out\[char46] \fBoff\fR filters out all messages\[char46] See \fBovs\-appctl\fR(8) for a definition of each log level\[char46] +.RE +.IP +Case is not significant within \fIspec\fR\[char46] +.IP +Regardless of the log levels set for \fBfile\fR, logging to a file will not take place unless \fB\-\-log\-file\fR is also specified (see below)\[char46] +.IP +For compatibility with older versions of OVS, \fBany\fR is accepted as a word but has no effect\[char46] +.TP +\fB\-v\fR +.TQ .5in +\fB\-\-verbose\fR +Sets the maximum logging verbosity level, equivalent to \fB\-\-verbose=dbg\fR\[char46] +.TP +\fB\-vPATTERN:\fR\fIdestination\fR\fB:\fR\fIpattern\fR +.TQ .5in +\fB\-\-verbose=PATTERN:\fR\fIdestination\fR\fB:\fR\fIpattern\fR +Sets the log pattern for \fIdestination\fR to \fIpattern\fR\[char46] Refer to \fBovs\-appctl\fR(8) for a description of the valid syntax for \fIpattern\fR\[char46] +.TP +\fB\-vFACILITY:\fR\fIfacility\fR +.TQ .5in +\fB\-\-verbose=FACILITY:\fR\fIfacility\fR +Sets the RFC5424 facility of the log message\[char46] \fIfacility\fR can be one of \fBkern\fR, \fBuser\fR, \fBmail\fR, \fBdaemon\fR, \fBauth\fR, \fBsyslog\fR, \fBlpr\fR, \fBnews\fR, \fBuucp\fR, \fBclock\fR, \fBftp\fR, \fBntp\fR, \fBaudit\fR, \fBalert\fR, \fBclock2\fR, \fBlocal0\fR, \fBlocal1\fR, \fBlocal2\fR, \fBlocal3\fR, \fBlocal4\fR, \fBlocal5\fR, \fBlocal6\fR or \fBlocal7\fR\[char46] If this option is not specified, \fBdaemon\fR is used as the default for the local system syslog and \fBlocal0\fR is used while sending a message to the target provided via the \fB\-\-syslog\-target\fR option\[char46] +.TP +\fB\-\-log\-file\fR[\fB=\fR\fIfile\fR] +Enables logging to a file\[char46] If \fIfile\fR is specified, then it is used as the exact name for the log file\[char46] The default log file name used if \fIfile\fR is omitted is \fB/usr/local/var/log/ovn/\fIprogram\fB\[char46]log\fR\[char46] +.TP +\fB\-\-syslog\-target=\fR\fIhost\fR\fB:\fR\fIport\fR +Send syslog messages to UDP \fIport\fR on \fIhost\fR, in addition to the system syslog\[char46] The \fIhost\fR must be a numerical IP address, not a hostname\[char46] +.TP +\fB\-\-syslog\-method=\fR\fImethod\fR +Specify \fImethod\fR as how syslog messages should be sent to syslog daemon\[char46] The following forms are supported: +.RS +.IP \(bu +\fBlibc\fR, to use the libc \fBsyslog()\fR function\[char46] Downside of using this options is that libc adds fixed prefix to every message before it is actually sent to the syslog daemon over \fB/dev/log\fR UNIX domain socket\[char46] +.IP \(bu +\fBunix:\fIfile\fB\fR, to use a UNIX domain socket directly\[char46] It is possible to specify arbitrary message format with this option\[char46] However, \fBrsyslogd 8\[char46]9\fR and older versions use hard coded parser function anyway that limits UNIX domain socket use\[char46] If you want to use arbitrary message format with older \fBrsyslogd\fR versions, then use UDP socket to localhost IP address instead\[char46] +.IP \(bu +\fBudp:\fIip\fB:\fIport\fB\fR, to use a UDP socket\[char46] With this method it is possible to use arbitrary message format also with older \fBrsyslogd\fR\[char46] When sending syslog messages over UDP socket extra precaution needs to be taken into account, for example, 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\[char46] +.IP \(bu +\fBnull\fR, to discard all messages logged to syslog\[char46] +.RE +.IP +The default is taken from the \fBOVS_SYSLOG_METHOD\fR environment variable; if it is unset, the default is \fBlibc\fR\[char46] +.SS "Table Formatting Options" +These options control the format of output from the \fBlist\fR and \fBfind\fR commands\[char46] +.RS +.TP +\fB\-f\fR \fIformat\fR +.TQ .5in +\fB\-\-format=\fR\fIformat\fR +Sets the type of table formatting\[char46] The following types of \fIformat\fR are available: +.RS +.TP +\fBtable\fR +2-D text tables with aligned columns\[char46] +.TP +\fBlist\fR (default) +A list with one column per line and rows separated by a blank line\[char46] +.TP +\fBhtml\fR +HTML tables\[char46] +.TP +\fBcsv\fR +Comma-separated values as defined in RFC 4180\[char46] +.TP +\fBjson\fR +JSON format as defined in RFC 4627\[char46] The output is a sequence of JSON objects, each of which corresponds to one table\[char46] Each JSON object has the following members with the noted values: +.RS +.TP +\fBcaption\fR +The table\(cqs caption\[char46] This member is omitted if the table has no caption\[char46] +.TP +\fBheadings\fR +An array with one element per table column\[char46] Each array element is a string giving the corresponding column\(cqs heading\[char46] +.TP +\fBdata\fR +An array with one element per table row\[char46] Each element is also an array with one element per table column\[char46] The elements of this second-level array are the cells that constitute the table\[char46] Cells that represent OVSDB data or data types are expressed in the format described in the OVSDB specification; other cells are simply expressed as text strings\[char46] +.RE +.RE +.TP +\fB\-d\fR \fIformat\fR +.TQ .5in +\fB\-\-data=\fR\fIformat\fR +Sets the formatting for cells within output tables unless the table format is set to \fBjson\fR, in which case \fBjson\fR formatting is always used when formatting cells\[char46] The following types of \fIformat\fR are available: +.RS +.TP +\fBstring\fR (default) +The simple format described in the \fBDatabase Values\fR section of \fBovs\-vsctl\fR(8)\[char46] +.TP +\fBbare\fR +The simple format with punctuation stripped off: \fB[]\fR and \fB{}\fR are omitted around sets, maps, and empty columns, items within sets and maps are space-separated, and strings are never quoted\[char46] This format may be easier for scripts to parse\[char46] +.TP +\fBjson\fR +The RFC 4627 JSON format as described above\[char46] +.RE +.TP +\fB\-\-no\-headings\fR +This option suppresses the heading row that otherwise appears in the first row of table output\[char46] +.TP +\fB\-\-pretty\fR +By default, JSON in output is printed as compactly as possible\[char46] This option causes JSON in output to be printed in a more readable fashion\[char46] Members of objects and elements of arrays are printed one per line, with indentation\[char46] +.IP +This option does not affect JSON in tables, which is always printed compactly\[char46] +.TP +\fB\-\-bare\fR +Equivalent to \fB\-\-format=list \-\-data=bare \-\-no\-headings\fR\[char46] +.RE +.SS "PKI Options" +.PP +.PP +PKI configuration is required to use SSL for the connection to the database\[char46] +.RS +.TP +\fB\-p\fR \fIprivkey\[char46]pem\fR +.TQ .5in +\fB\-\-private\-key=\fR\fIprivkey\[char46]pem\fR +Specifies a PEM file containing the private key used as identity for outgoing SSL connections\[char46] +.TP +\fB\-c\fR \fIcert\[char46]pem\fR +.TQ .5in +\fB\-\-certificate=\fR\fIcert\[char46]pem\fR +Specifies a PEM file containing a certificate that certifies the private key specified on \fB\-p\fR or \fB\-\-private\-key\fR to be trustworthy\[char46] The certificate must be signed by the certificate authority (CA) that the peer in SSL connections will use to verify it\[char46] +.TP +\fB\-C\fR \fIcacert\[char46]pem\fR +.TQ .5in +\fB\-\-ca\-cert=\fR\fIcacert\[char46]pem\fR +Specifies a PEM file containing the CA certificate for verifying certificates presented to this program by SSL peers\[char46] (This may be the same certificate that SSL peers use to verify the certificate specified on \fB\-c\fR or \fB\-\-certificate\fR, or it may be a different one, depending on the PKI design in use\[char46]) +.TP +\fB\-C none\fR +.TQ .5in +\fB\-\-ca\-cert=none\fR +Disables verification of certificates presented by SSL peers\[char46] This introduces a security risk, because it means that certificates cannot be verified to be those of known trusted hosts\[char46] +.RE +.RS +.TP +\fB\-\-bootstrap\-ca\-cert=\fR\fIcacert\[char46]pem\fR +When \fIcacert\[char46]pem\fR exists, this option has the same effect as \fB\-C\fR or \fB\-\-ca\-cert\fR\[char46] If it does not exist, then the executable will attempt to obtain the CA certificate from the SSL peer on its first SSL connection and save it to the named PEM file\[char46] 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\[char46] +.IP +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\[char46] +.IP +This option is only useful if the SSL peer sends its CA certificate as part of the SSL certificate chain\[char46] The SSL protocol does not require the server to send the CA certificate\[char46] +.IP +This option is mutually exclusive with \fB\-C\fR and \fB\-\-ca\-cert\fR\[char46] +.RE +.SS "Other Options" +.TP +\fB\-h\fR +.TQ .5in +\fB\-\-help\fR +Prints a brief help message to the console\[char46] +.TP +\fB\-V\fR +.TQ .5in +\fB\-\-version\fR +Prints version information to the console\[char46] +.SH "COMMANDS" +.PP +.PP +The following sections describe the commands that \fBovn\-sbctl\fR supports\[char46] +.SS "OVN_Southbound Commands" +.PP +.PP +These commands work with an \fBOVN_Southbound\fR database as a whole\[char46] +.RS +.TP +\fBinit\fR +Initializes the database, if it is empty\[char46] If the database has already been initialized, this command has no effect\[char46] +.TP +\fBshow\fR +Prints a brief overview of the database contents\[char46] +.RE +.SS "Chassis Commands" +.PP +.PP +These commands manipulate \fBOVN_Southbound\fR chassis\[char46] +.RS +.TP +[\fB\-\-may\-exist\fR] \fBchassis\-add \fIchassis\fB \fIencap-type\fB \fIencap-ip\fB\fR +Creates a new chassis named \fIchassis\fR\[char46] \fIencap-type\fR is a comma-separated list of tunnel types\[char46] The chassis will have one encap entry for each specified tunnel type with \fIencap-ip\fR as the destination IP for each\[char46] +.IP +Without \fB\-\-may\-exist\fR, attempting to create a chassis that exists is an error\[char46] With \fB\-\-may\-exist\fR, this command does nothing if \fIchassis\fR already exists\[char46] +.TP +[\fB\-\-if\-exists\fR] \fIchassis-del \fIchassis\fI\fR +Deletes \fIchassis\fR and its \fIencaps\fR and \fIgateway_ports\fR\[char46] +.IP +Without \fB\-\-if\-exists\fR, attempting to delete a chassis that does not exist is an error\[char46] With \fB\-\-if\-exists\fR attempting to delete a chassis that does not exist has no effect\[char46] +.RE +.SS "Port Binding Commands" +.PP +.PP +These commands manipulate \fBOVN_Southbound\fR port bindings\[char46] +.RS +.TP +[\fB\-\-may\-exist\fR] \fBlsp\-bind \fIlogical-port\fB \fIchassis\fB\fR +Binds the logical port named \fIlogical-port\fR to \fIchassis\fR\[char46] +.IP +Without \fB\-\-may\-exist\fR, attempting to bind a logical port that has already been bound is an error\[char46] With \fB\-\-may\-exist\fR, this command does nothing if \fIlogical-port\fR has already been bound to a chassis\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBlsp\-unbind \fIlogical-port\fB\fR +Removes the binding of \fIlogical-port\fR\[char46] +.IP +Without \fB\-\-if\-exists\fR, attempting to unbind a logical port that is not bound is an error\[char46] With \fB\-\-if\-exists\fR, attempting to unbind logical port that is not bound has no effect\[char46] +.RE +.SS "Logical Flow Commands" +.TP +[\fB\-\-uuid\fR] [\fB\-\-ovs\fR[\fB=\fIremote\fB]\fR] [\fB\-\-stats\fR] [\fB\-\-vflows\fR] \fBlflow\-list\fR [\fIlogical-datapath\fR] [\fIlflow\fR\[char46]\[char46]\[char46]] +List logical flows\[char46] If \fIlogical-datapath\fR is specified, only list flows for that logical datapath\[char46] The \fIlogical-datapath\fR may be given as a UUID or as a datapath name (reporting an error if multiple datapaths have the same name)\[char46] +.IP +If at least one \fIlflow\fR is given, only matching logical flows, if any, are listed\[char46] Each \fIlflow\fR may be specified as a UUID or the first few characters of a UUID, optionally prefixed by \fB0x\fR\[char46] (Because \fBovn\-controller\fR sets OpenFlow flow cookies to the first 32 bits of the corresponding logical flow\(cqs UUID, this makes it easy to look up the logical flow that generated a particular OpenFlow flow\[char46]) +.IP +If \fB\-\-uuid\fR is specified, the output includes the first 32 bits of each logical flow\(cqs UUID\[char46] This makes it easier to find the OpenFlow flows that correspond to a given logical flow\[char46] +.IP +If \fB\-\-ovs\fR is included, \fBovn\-sbctl\fR attempts to obtain and display the OpenFlow flows that correspond to each OVN logical flow\[char46] To do so, \fBovn\-sbctl\fR connects to \fIremote\fR (by default, \fBunix:/br\-int\[char46]mgmt\fR) over OpenFlow and retrieves the flows\[char46] If \fIremote\fR is specified, it must be an active OpenFlow connection method described in \fBovsdb\fR(7)\[char46] Please see the discussion of the similar \fB\-\-ovs\fR option in \fBovn\-trace\fR(8) for more information about the OpenFlow flow output\[char46] +.IP +By default, OpenFlow flow output includes only match and actions\[char46] Add \fB\-\-stats\fR to include all OpenFlow information, such as packet and byte counters, duration, and timeouts\[char46] +.IP +If \fB\-\-vflows\fR is included, other southbound database records directly used for generating OpenFlow flows are also listed\[char46] This includes: \fIport-bindings\fR, \fImac-bindings\fR, \fImulticast-groups\fR, \fIchassis\fR\[char46] The \fB\-\-ovs\fR and \fB\-\-stats\fR can also be used in conjunction with \fB\-\-vflows\fR\[char46] +.TP +[\fB\-\-uuid\fR] \fBdump\-flows\fR [\fIlogical-datapath\fR] +Alias for \fBlflow\-list\fR\[char46] +.TP +\fBcount\-flows\fR [\fIlogical-datapath\fR] +prints numbers of logical flows per table and per datapath\[char46] +.SS "Remote Connectivity Commands" +.PP +.PP +These commands manipulate the \fBconnections\fR column in the \fBSB_Global\fR table and rows in the \fBConnection\fR table\[char46] When \fBovsdb\-server\fR is configured to use the \fBconnections\fR column for OVSDB connections, this allows the administrator to use \efBovn\e-sbctl\efR to configure database connections\[char46] +.RS +.TP +\fBget\-connection\fR +Prints the configured connection(s)\[char46] +.TP +\fBdel\-connection\fR +Deletes the configured connection(s)\[char46] +.TP +[\fB\-\-inactivity\-probe=\fR\fImsecs\fR] \fBset\-connection\fR \fItarget\fR\[char46]\[char46]\[char46] +Sets the configured manager target or targets\[char46] Use \fB\-\-inactivity\-probe=\fR\fImsecs\fR to override the default idle connection inactivity probe time\[char46] Use 0 to disable inactivity probes\[char46] +.RE +.SS "SSL Configuration Commands" +.PP +.PP +When \fBovsdb\-server\fR is configured to connect using SSL, the following parameters are required: +.RS +.TP +\fIprivate-key\fR +Specifies a PEM file containing the private key used for SSL connections\[char46] +.TP +\fIcertificate\fR +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\[char46] +.TP +\fIca-cert\fR +Specifies a PEM file containing the CA certificate used to verify that the connection peers are trustworthy\[char46] +.RE +.PP +.PP +These SSL settings apply to all SSL connections made by the southbound database server\[char46] +.RS +.TP +\fBget\-ssl\fR +Prints the SSL configuration\[char46] +.TP +\fBdel\-ssl\fR +Deletes the current SSL configuration\[char46] +.TP +[\fB\-\-bootstrap\fR] \fBset\-ssl\fR \fIprivate-key\fR \fIcertificate\fR \fIca-cert\fR [\fIssl-protocol-list\fR [\fIssl-cipher-list\fR]] +Sets the SSL configuration\[char46] +.RE +.SS "Database Commands" +.PP +.PP +These commands query and modify the contents of \fBovsdb\fR tables\[char46] They are a slight abstraction of the \fBovsdb\fR interface and as such they operate at a lower level than other \fBovn\-sbctl\fR commands\[char46] +.PP +\fIIdentifying Tables, Records, and Columns\fR +.PP +.PP +Each of these commands has a \fItable\fR parameter to identify a table within the database\[char46] Many of them also take a \fIrecord\fR parameter that identifies a particular record within a table\[char46] The \fIrecord\fR 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\[char46] Many tables offer additional ways to identify records\[char46] Some commands also take \fIcolumn\fR parameters that identify a particular field within the records in a table\[char46] +.PP +.PP +For a list of tables and their columns, see \fBovn\-sb\fR(5) or see the table listing from the \fB\-\-help\fR option\[char46] +.PP +.PP +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\[char46] Names of tables and columns are not case-sensitive, and \fB\-\fR and \fB_\fR are treated interchangeably\[char46] Unique abbreviations of table and column names are acceptable, e\[char46]g\[char46] \fBd\fR or \fBdhcp\fR is sufficient to identify the \fBDHCP_Options\fR table\[char46] +.PP +.PP +.PP +\fIDatabase Values\fR +.PP +.PP +Each column in the database accepts a fixed type of data\[char46] The currently defined basic types, and their representations, are: +.RS +.TP +integer +A decimal integer in the range \-2**63 to 2**63\-1, inclusive\[char46] +.TP +real +A floating-point number\[char46] +.TP +Boolean +True or false, written \fBtrue\fR or \fBfalse\fR, respectively\[char46] +.TP +string +An arbitrary Unicode string, except that null bytes are not allowed\[char46] Quotes are optional for most strings that begin with an English letter or underscore and consist only of letters, underscores, hyphens, and periods\[char46] However, \fBtrue\fR and \fBfalse\fR and strings that match the syntax of UUIDs (see below) must be enclosed in double quotes to distinguish them from other basic types\[char46] When double quotes are used, the syntax is that of strings in JSON, e\[char46]g\[char46] backslashes may be used to escape special characters\[char46] The empty string must be represented as a pair of double quotes (\fB\(dq\(dq\fR)\[char46] +.TP +UUID +Either a universally unique identifier in the style of RFC 4122, e\[char46]g\[char46] \fBf81d4fae\-7dec\-11d0\-a765\-00a0c91e6bf6\fR, or an \fB@\fR\fIname\fR defined by a \fBget\fR or \fBcreate\fR command within the same \fBovs\-vsctl\fR invocation\[char46] +.RE +.PP +.PP +Multiple values in a single column may be separated by spaces or a single comma\[char46] When multiple values are present, duplicates are not allowed, and order is not important\[char46] Conversely, some database columns can have an empty set of values, represented as \fB[]\fR, and square brackets may optionally enclose other non-empty sets or single values as well\[char46] +.PP +.PP +A few database columns are ``maps\(cq\(cq of key-value pairs, where the key and the value are each some fixed database type\[char46] These are specified in the form \fIkey\fR\fB=\fR\fIvalue\fR, where \fIkey\fR and \fIvalue\fR follow the syntax for the column\(cqs key type and value type, respectively\[char46] When multiple pairs are present (separated by spaces or a comma), duplicate keys are not allowed, and again the order is not important\[char46] Duplicate values are allowed\[char46] An empty map is represented as \fB{}\fR\[char46] Curly braces may optionally enclose non-empty maps as well (but use quotes to prevent the shell from expanding \fBother\-config={0=x,1=y}\fR into \fBother\-config=0=x +other\-config=1=y\fR, which may not have the desired effect)\[char46] +.PP +\fIDatabase Command Syntax\fR +.RS +.TP +[\fB\-\-if\-exists\fR] [\fB\-\-columns=\fR\fIcolumn\fR[\fB,\fR\fIcolumn\fR]\[char46]\[char46]\[char46]] \fBlist\fR \fItable\fR [\fIrecord\fR]\[char46]\[char46]\[char46] +Lists the data in each specified \fIrecord\fR\[char46] If no records are specified, lists all the records in \fItable\fR\[char46] +.IP +If \fB\-\-columns\fR is specified, only the requested columns are listed, in the specified order\[char46] Otherwise, all columns are listed, in alphabetical order by column name\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if any specified \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, the command ignores any \fIrecord\fR that does not exist, without producing any output\[char46] +.TP +[\fB\-\-columns=\fR\fIcolumn\fR[\fB,\fR\fIcolumn\fR]\[char46]\[char46]\[char46]] \fBfind\fR \fItable\fR [\fIcolumn\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR]\[char46]\[char46]\[char46] +Lists the data in each record in \fItable\fR whose \fIcolumn\fR equals \fIvalue\fR or, if \fIkey\fR is specified, whose \fIcolumn\fR contains a \fIkey\fR with the specified \fIvalue\fR\[char46] The following operators may be used where \fB=\fR is written in the syntax summary: +.RS +.TP +\fB= != < > <= >=\fR +Selects records in which \fIcolumn\fR[\fB:\fR\fIkey\fR] equals, does not equal, is less than, is greater than, is less than or equal to, or is greater than or equal to \fIvalue\fR, respectively\[char46] +.IP +Consider \fIcolumn\fR[\fB:\fR\fIkey\fR] and \fIvalue\fR as sets of elements\[char46] Identical sets are considered equal\[char46] Otherwise, if the sets have different numbers of elements, then the set with more elements is considered to be larger\[char46] Otherwise, consider a element from each set pairwise, in increasing order within each set\[char46] The first pair that differs determines the result\[char46] (For a column that contains key-value pairs, first all the keys are compared, and values are considered only if the two sets contain identical keys\[char46]) +.TP +\fB{=} {!=}\fR +Test for set equality or inequality, respectively\[char46] +.TP +\fB{<=}\fR +Selects records in which \fIcolumn\fR[\fB:\fR\fIkey\fR] is a subset of \fIvalue\fR\[char46] For example, \fBflood\-vlans{<=}1,2\fR selects records in which the \fBflood\-vlans\fR column is the empty set or contains 1 or 2 or both\[char46] +.TP +\fB{<}\fR +Selects records in which \fIcolumn\fR[\fB:\fR\fIkey\fR] is a proper subset of \fIvalue\fR\[char46] For example, \fBflood\-vlans{<}1,2\fR selects records in which the \fBflood\-vlans\fR column is the empty set or contains 1 or 2 but not both\[char46] +.TP +\fB{>=} {>}\fR +Same as \fB{<=}\fR and \fB{<}\fR, respectively, except that the relationship is reversed\[char46] For example, \fBflood\-vlans{>=}1,2\fR selects records in which the \fBflood\-vlans\fR column contains both 1 and 2\[char46] +.RE +.IP +The following operators are available only in Open vSwitch 2\[char46]16 and later: +.RS +.TP +\fB{in}\fR +Selects records in which every element in \fIcolumn\fR[\fB:\fR\fIkey\fR] is also in \fIvalue\fR\[char46] (This is the same as \fB{<=}\fR\[char46]) +.TP +\fB{not\-in}\fR +Selects records in which every element in \fIcolumn\fR[\fB:\fR\fIkey\fR] is not in \fIvalue\fR\[char46] +.RE +.IP +For arithmetic operators (\fB= != < > <= >=\fR), when \fIkey\fR is specified but a particular record\(cqs \fIcolumn\fR does not contain \fIkey\fR, the record is always omitted from the results\[char46] Thus, the condition \fBother\-config:mtu!=1500\fR matches records that have a \fBmtu\fR key whose value is not 1500, but not those that lack an \fBmtu\fR key\[char46] +.IP +For the set operators, when \fIkey\fR is specified but a particular record\(cqs \fIcolumn\fR does not contain \fIkey\fR, the comparison is done against an empty set\[char46] Thus, the condition \fBother\-config:mtu{!=}1500\fR matches records that have a \fBmtu\fR key whose value is not 1500 and those that lack an \fBmtu\fR key\[char46] +.IP +Don\(cqt forget to escape \fB<\fR or \fB>\fR from interpretation by the shell\[char46] +.IP +If \fB\-\-columns\fR is specified, only the requested columns are listed, in the specified order\[char46] Otherwise all columns are listed, in alphabetical order by column name\[char46] +.IP +The UUIDs shown for rows created in the same \fBovs\-vsctl\fR invocation will be wrong\[char46] +.TP +[\fB\-\-if\-exists\fR] [\fB\-\-id=@\fR\fIname\fR] \fBget\fR \fItable record\fR [\fIcolumn\fR[\fB:\fR\fIkey\fR]]\[char46]\[char46]\[char46] +Prints the value of each specified \fIcolumn\fR in the given \fIrecord\fR in \fItable\fR\[char46] For map columns, a \fIkey\fR may optionally be specified, in which case the value associated with \fIkey\fR in the column is printed, instead of the entire map\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist or \fIkey\fR is specified, if \fIkey\fR does not exist in \fIrecord\fR\[char46] With \fB\-\-if\-exists\fR, a missing \fIrecord\fR yields no output and a missing \fIkey\fR prints a blank line\[char46] +.IP +If \fB@\fR\fIname\fR is specified, then the UUID for \fIrecord\fR may be referred to by that name later in the same \fBovs\-vsctl\fR invocation in contexts where a UUID is expected\[char46] +.IP +Both \fB\-\-id\fR and the \fIcolumn\fR arguments are optional, but usually at least one or the other should be specified\[char46] If both are omitted, then \fBget\fR has no effect except to verify that \fIrecord\fR exists in \fItable\fR\[char46] +.IP +\fB\-\-id\fR and \fB\-\-if\-exists\fR cannot be used together\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBset\fR \fItable record column\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR\[char46]\[char46]\[char46] +Sets the value of each specified \fIcolumn\fR in the given \fIrecord\fR in \fItable\fR to \fIvalue\fR\[char46] For map columns, a \fIkey\fR may optionally be specified, in which case the value associated with \fIkey\fR in that column is changed (or added, if none exists), instead of the entire map\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, this command does nothing if \fIrecord\fR does not exist\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBadd\fR \fItable record column\fR [\fIkey\fR\fB=\fR]\fIvalue\fR\[char46]\[char46]\[char46] +Adds the specified value or key-value pair to \fIcolumn\fR in \fIrecord\fR in \fItable\fR\[char46] If \fIcolumn\fR is a map, then \fIkey\fR is required, otherwise it is prohibited\[char46] If \fIkey\fR already exists in a map column, then the current \fIvalue\fR is not replaced (use the \fBset\fR command to replace an existing value)\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, this command does nothing if \fIrecord\fR does not exist\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBremove\fR \fItable record column value\fR\[char46]\[char46]\[char46] +.IP +[\fB\-\-if\-exists\fR] \fBremove\fR \fItable record column key\fR\[char46]\[char46]\[char46] +.IP +[\fB\-\-if\-exists\fR] \fBremove\fR \fItable record column key\fR\fB=\fR\fIvalue\fR\[char46]\[char46]\[char46] +Removes the specified values or key-value pairs from \fIcolumn\fR in \fIrecord\fR in \fItable\fR\[char46] The first form applies to columns that are not maps: each specified \fIvalue\fR is removed from the column\[char46] The second and third forms apply to map columns: if only a \fIkey\fR is specified, then any key-value pair with the given \fIkey\fR is removed, regardless of its value; if a \fIvalue\fR is given then a pair is removed only if both key and value match\[char46] +.IP +It is not an error if the column does not contain the specified key or value or pair\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, this command does nothing if \fIrecord\fR does not exist\[char46] +.TP +[\fB\-\-if\-exists\fR] \fBclear\fR \fItable record column\fR\[char46]\[char46]\[char46] +Sets each \fIcolumn\fR in \fIrecord\fR in \fItable\fR to the empty set or empty map, as appropriate\[char46] This command applies only to columns that are allowed to be empty\[char46] +.IP +Without \fB\-\-if\-exists\fR, it is an error if \fIrecord\fR does not exist\[char46] With \fB\-\-if\-exists\fR, this command does nothing if \fIrecord\fR does not exist\[char46] +.TP +[\fB\-\-id=(@\fR\fIname\fR|\fIuuid\fR)] \fBcreate\fR \fItable column\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR\[char46]\[char46]\[char46] +Creates a new record in \fItable\fR and sets the initial values of each \fIcolumn\fR\[char46] Columns not explicitly set will receive their default values\[char46] Outputs the UUID of the new row\[char46] +.IP +If \fB@\fR\fIname\fR is specified, then the UUID for the new row may be referred to by that name elsewhere in the same \fB\e*(PN\fR invocation in contexts where a UUID is expected\[char46] Such references may precede or follow the \fBcreate\fR command\[char46] +.IP +If a valid \fIuuid\fR is specified, then it is used as the UUID of the new row\[char46] +.RS +.TP +Caution (ovs-vsctl as example) +Records in the Open vSwitch database are significant only when they can be reached directly or indirectly from the \fBOpen_vSwitch\fR table\[char46] Except for records in the \fBQoS\fR or \fBQueue\fR tables, records that are not reachable from the \fBOpen_vSwitch\fR table are automatically deleted from the database\[char46] This deletion happens immediately, without waiting for additional \fBovs\-vsctl\fR commands or other database activity\[char46] Thus, a \fBcreate\fR command must generally be accompanied by additional commands \fIwithin the same\fR \fBovs\-vsctl\fR \fIinvocation\fR to add a chain of references to the newly created record from the top-level \fBOpen_vSwitch\fR record\[char46] The \fBEXAMPLES\fR section gives some examples that show how to do this\[char46] +.RE +.TP +[\fB\-\-if\-exists\fR] \fBdestroy\fR \fItable record\fR\[char46]\[char46]\[char46] +Deletes each specified \fIrecord\fR from \fItable\fR\[char46] Unless \fB\-\-if\-exists\fR is specified, each \fIrecord\fRs must exist\[char46] +.TP +\fB\-\-all destroy\fR \fItable\fR +Deletes all records from the \fItable\fR\[char46] +.RS +.TP +Caution (ovs-vsctl as example) +The \fBdestroy\fR command is only useful for records in the \fBQoS\fR or \fBQueue\fR tables\[char46] Records in other tables are automatically deleted from the database when they become unreachable from the \fBOpen_vSwitch\fR table\[char46] This means that deleting the last reference to a record is sufficient for deleting the record itself\[char46] For records in these tables, \fBdestroy\fR is silently ignored\[char46] See the \fBEXAMPLES\fR section below for more information\[char46] +.RE +.TP +\fBwait\-until\fR \fItable record\fR [\fIcolumn\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR]\[char46]\[char46]\[char46] +Waits until \fItable\fR contains a record named \fIrecord\fR whose \fIcolumn\fR equals \fIvalue\fR or, if \fIkey\fR is specified, whose \fIcolumn\fR contains a \fIkey\fR with the specified \fIvalue\fR\[char46] This command supports the same operators and semantics described for the \fBfind\fR command above\[char46] +.IP +If no \fIcolumn\fR[\fB:\fR\fIkey\fR]\fB=\fR\fIvalue\fR arguments are given, this command waits only until \fIrecord\fR exists\[char46] If more than one such argument is given, the command waits until all of them are satisfied\[char46] +.RS +.TP +Caution (ovs-vsctl as example) +Usually \fBwait\-until\fR should be placed at the beginning of a set of \fBovs\-vsctl\fR commands\[char46] For example, \fBwait\-until bridge br0 +\-\- get bridge br0 datapath_id\fR waits until a bridge named \fBbr0\fR is created, then prints its \fBdatapath_id\fR column, whereas \fBget bridge br0 datapath_id \-\- wait\-until bridge br0\fR will abort if no bridge named \fBbr0\fR exists when \fBovs\-vsctl\fR initially connects to the database\[char46] +.RE +.IP +Consider specifying \fB\-\-timeout=0\fR along with \fB\-\-wait\-until\fR, to prevent \fBovs\-vsctl\fR from terminating after waiting only at most 5 seconds\[char46] +.TP +\fBcomment\fR [\fIarg\fR]\[char46]\[char46]\[char46] +This command has no effect on behavior, but any database log record created by the command will include the command and its arguments\[char46] +.RE +.SH "ENVIRONMENT" +.TP +\fBOVN_SB_DAEMON\fR +If set, this should name the Unix domain socket for an \fBovn\-sbctl\fR server process\[char46] See \fBDaemon Mode\fR, above, for more information\[char46] +.TP +\fBOVN_SBCTL_OPTIONS\fR +If set, a set of options for \fBovn\-sbctl\fR to apply automatically, in the same form as on the command line\[char46] +.TP +\fBOVN_SB_DB\fR +If set, the default database to contact when the \fB\-\-db\fR option is not used\[char46] +.SH "EXIT STATUS" +.TP +0 +Successful program execution\[char46] +.TP +1 +Usage, syntax, or network error\[char46] +.SH "SEE ALSO" +\fBovn\-sb\fR(5), \fBovn\-appctl\fR(8)\[char46] diff --git a/src/static/support/dist-docs-branch-23.06/ovn-sbctl.8.html b/src/static/support/dist-docs-branch-23.06/ovn-sbctl.8.html new file mode 100644 index 00000000..0de872ac --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-sbctl.8.html @@ -0,0 +1,979 @@ +
+ovn-sbctl(8)                      OVN Manual                      ovn-sbctl(8)
+
+NAME
+       ovn-sbctl - Open Virtual Network southbound db management utility
+
+SYNOPSIS
+       ovn-sbctl [options] command [arg...]
+
+DESCRIPTION
+       The ovn-sbctl program configures the OVN_Southbound database by providā€
+       ing a high-level interface to its configuration database. See ovn-sb(5)
+       for comprehensive documentation of the database schema.
+
+       ovn-sbctl  connects  to  an  ovsdb-server  process  that  maintains  an
+       OVN_Southbound  configuration  database.  Using  this  connection,   it
+       queries  and possibly applies changes to the database, depending on the
+       supplied commands.
+
+       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 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ā€
+       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
+       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.
+
+       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 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
+       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
+       uses the daemon to execute its commands.
+
+       When the daemon is no longer needed, kill it and unset the  environment
+       variable, e.g.:
+
+             kill $(cat $OVN_RUNDIR/ovn-sbctl.pid)
+             unset OVN_SB_DAEMON
+
+
+       When using daemon mode, an alternative to the OVN_SB_DAEMON environment
+       variable  is  to  specify a path for the Unix socket. When starting the
+       ovn-sbctl daemon, specify the -u option with a full path to  the  locaā€
+       tion of the socket file. Here is an exmple:
+
+             ovn-sbctl --detach -u /tmp/mysock.ctl
+
+
+       Then  to connect to the running daemon, use the -u option with the full
+       path to the socket created when the daemon was started:
+
+             ovn-sbctl -u /tmp/mysock.ctl show
+
+
+     Daemon Commands
+
+       Daemon mode is internally implemented using the same mechanism used  by
+       ovn-appctl.  One  may  also  use ovn-appctl directly with the following
+       commands:
+
+              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  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.
+       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 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
+       command line override those in the environment.
+
+              --db database
+                     The OVSDB database remote to contact.  If  the  OVN_SB_DB
+                     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
+                   By default, or with --leader-only, when the database server
+                   is a clustered database, ovn-sbctl will avoid servers other
+                   than the cluster leader. This ensures that  any  data  that
+                   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
+                   database are always serialized even with --no-leader-only).
+                   Refer to Understanding Cluster Consistency in ovsdb(7)  for
+                   more information.
+
+              --shuffle-remotes
+              --no-shuffle-remotes
+                   By  default, or with --shuffle-remotes, when there are mulā€
+                   tiple remotes specified  in  the  OVSDB  connection  string
+                   specified  by  --db  or the OVN_SB_DB environment variable,
+                   the order of the remotes will be shuffled before the client
+                   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,
+                   which is particularly useful for testing.
+
+              --no-syslog
+                   By default, ovn-sbctl logs its arguments and the details of
+                   any changes that it makes to the system  log.  This  option
+                   disables this logging.
+
+                   This option is equivalent to --verbose=sbctl:syslog:warn.
+
+              --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
+                   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.
+
+              --dry-run
+                   Prevents ovn-sbctl from actually modifying the database.
+
+              -t secs
+              --timeout=secs
+                   By default, or with a secs of 0,  ovn-sbctl  waits  forever
+                   for  a  response from the database. This option limits runā€
+                   time to approximately secs seconds. If the timeout expires,
+                   ovn-sbctl will exit with a SIGALRM signal. (A timeout would
+                   normally happen only if the database cannot  be  contacted,
+                   or if the system is overloaded.)
+
+   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
+              specified, or if it does not begin with /, then it is created in
+              .
+
+              If --pidfile is not specified, no pidfile is created.
+
+       --overwrite-pidfile
+              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.
+
+              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
+              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
+              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ā€ā€
+              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ā€
+              tions without it.
+
+       --no-chdir
+              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.
+
+              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-
+              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.
+
+       --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
+              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
+              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
+              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
+            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
+                   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,  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
+                   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
+                   definition of each log level.
+
+            Case is not significant within spec.
+
+            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
+            word but has no effect.
+
+       -v
+       --verbose
+            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-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,
+            local4, local5, local6 or local7. If this option is not specified,
+            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
+            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.
+
+       --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ā€
+            name.
+
+       --syslog-method=method
+            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
+                   /dev/log UNIX domain socket.
+
+            ā€¢      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 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ā€
+       mands.
+
+              -f format
+              --format=format
+                   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
+                          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
+                          members with the noted values:
+
+                          caption
+                                 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
+                                 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-
+                                 level array are the cells that constitute the
+                                 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
+                   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:
+
+                   string (default)
+                          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
+                          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  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
+                   arrays are printed one per line, with indentation.
+
+                   This option does not affect JSON in tables, which is always
+                   printed compactly.
+
+              --bare
+                   Equivalent to --format=list --data=bare --no-headings.
+
+   PKI Options
+       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
+                   identity for outgoing SSL connections.
+
+              -c cert.pem
+              --certificate=cert.pem
+                   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
+                   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
+                   verify the certificate specified on -c or --certificate, or
+                   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
+                   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ā€
+                     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.
+
+                     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
+                     certificate as part of the SSL certificate chain. The SSL
+                     protocol  does not require the server to send the CA cerā€
+                     tificate.
+
+                     This option is mutually exclusive with -C and --ca-cert.
+
+   Other Options
+       -h
+       --help
+            Prints a brief help message to the console.
+
+       -V
+       --version
+            Prints version information to the console.
+
+COMMANDS
+       The following sections describe the commands that ovn-sbctl supports.
+
+   OVN_Southbound Commands
+       These commands work with an OVN_Southbound database as a whole.
+
+              init   Initializes the database, if it is empty. If the database
+                     has already been initialized, this command has no effect.
+
+              show   Prints a brief overview of the database contents.
+
+   Chassis Commands
+       These commands manipulate OVN_Southbound chassis.
+
+              [--may-exist] chassis-add chassis encap-type encap-ip
+                     Creates a new chassis  named  chassis.  encap-type  is  a
+                     comma-separated  list  of  tunnel types. The chassis will
+                     have one encap entry for each specified tunnel type  with
+                     encap-ip as the destination IP for each.
+
+                     Without  --may-exist, attempting to create a chassis that
+                     exists is an error. With --may-exist, this  command  does
+                     nothing if chassis already exists.
+
+              [--if-exists] chassis-del chassis
+                     Deletes chassis and its encaps and gateway_ports.
+
+                     Without  --if-exists, attempting to delete a chassis that
+                     does not exist is an error. With  --if-exists  attempting
+                     to delete a chassis that does not exist has no effect.
+
+   Port Binding Commands
+       These commands manipulate OVN_Southbound port bindings.
+
+              [--may-exist] lsp-bind logical-port chassis
+                     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-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 efā€
+                     fect.
+
+   Logical Flow Commands
+       [--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
+              given as a UUID or as a datapath name  (reporting  an  error  if
+              multiple datapaths have the same name).
+
+              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. (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.)
+
+              If --uuid is specified, the output includes the first 32 bits of
+              each logical flowā€™s UUID. This makes it easier to find the Openā€
+              Flow flows that correspond to a given logical flow.
+
+              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 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 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 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.
+
+       count-flows [logical-datapath]
+              prints numbers of logical flows per table and per datapath.
+
+   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  adā€
+       ministrator to use \fBovn\-sbctl\fR to configure database connections.
+
+              get-connection
+                     Prints the configured connection(s).
+
+              del-connection
+                     Deletes the configured connection(s).
+
+              [--inactivity-probe=msecs] set-connection target...
+                     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 paā€
+       rameters are required:
+
+              private-key
+                     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
+                     trustworthy peer.
+
+              ca-cert
+                     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
+       database server.
+
+              get-ssl
+                     Prints the SSL configuration.
+
+              del-ssl
+                     Deletes the current SSL configuration.
+
+              [--bootstrap] set-ssl private-key certificate ca-cert [ssl-proā€
+              tocol-list [ssl-cipher-list]]
+                     Sets the SSL configuration.
+
+   Database Commands
+       These  commands query and modify the contents of ovsdb tables. They are
+       a slight abstraction of the ovsdb interface and as such they operate at
+       a lower level than other ovn-sbctl commands.
+
+       Identifying Tables, Records, and Columns
+
+       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
+       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
+       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,
+       e.g. d or dhcp is sufficient to identify the DHCP_Options table.
+
+       Database Values
+
+       Each column in the database accepts a fixed type of data. The currently
+       defined basic types, and their representations, are:
+
+              integer
+                     A decimal integer in the range -2**63 to 2**63-1,  incluā€
+                     sive.
+
+              real   A floating-point number.
+
+              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ā€
+                     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
+                     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
+                     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 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  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
+              [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
+                     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  igā€
+                     nores  any  record that does not exist, without producing
+                     any output.
+
+              [--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ā€
+                     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
+                            value, respectively.
+
+                            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
+                            pairs, first all the keys are compared, and values
+                            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
+                            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 the flood-vlans column is
+                            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
+                            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
+                            {=}.)
+
+                     {not-in}
+                            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
+                     not those that lack an mtu key.
+
+                     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
+                     key.
+
+                     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
+                     invocation will be wrong.
+
+              [--if-exists] [--id=@name] get table record [column[:key]]...
+                     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
+                     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 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
+                     both are omitted, then get has no effect except to verify
+                     that record exists in table.
+
+                     --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  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
+                     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  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
+                     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ā€
+                     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
+                     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.
+
+                     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
+                     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
+                     record does not exist.
+
+              [--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
+                     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
+                     references may precede or follow the create command.
+
+                     If a valid uuid is specified, then it is used as the UUID
+                     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 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
+                            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
+                            some examples that show how to do this.
+
+              [--if-exists] destroy table record...
+                     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
+                            for more information.
+
+              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
+                     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
+                     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ā€ā€
+                            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
+                            ovs-vsctl initially connects to the database.
+
+                     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ā€
+                     mand and its arguments.
+
+ENVIRONMENT
+       OVN_SB_DAEMON
+              If set, this should name the Unix domain socket for an ovn-sbctl
+              server process. See Daemon Mode, above, for more information.
+
+       OVN_SBCTL_OPTIONS
+              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
+              not used.
+
+EXIT STATUS
+       0      Successful program execution.
+
+       1      Usage, syntax, or network error.
+
+SEE ALSO
+       ovn-sb(5), ovn-appctl(8).
+
+OVN 23.06.3                        ovn-sbctl                      ovn-sbctl(8)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-sbctl.8.pdf b/src/static/support/dist-docs-branch-23.06/ovn-sbctl.8.pdf new file mode 100644 index 00000000..9d0805f6 Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-sbctl.8.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-sbctl.8.txt b/src/static/support/dist-docs-branch-23.06/ovn-sbctl.8.txt new file mode 100644 index 00000000..7e87b34a --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-sbctl.8.txt @@ -0,0 +1,977 @@ +ovn-sbctl(8) OVN Manual ovn-sbctl(8) + +NAME + ovn-sbctl - Open Virtual Network southbound db management utility + +SYNOPSIS + ovn-sbctl [options] command [arg...] + +DESCRIPTION + The ovn-sbctl program configures the OVN_Southbound database by providā€ + ing a high-level interface to its configuration database. See ovn-sb(5) + for comprehensive documentation of the database schema. + + ovn-sbctl connects to an ovsdb-server process that maintains an + OVN_Southbound configuration database. Using this connection, it + queries and possibly applies changes to the database, depending on the + supplied commands. + + 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 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ā€ + 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 + 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. + + 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 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 + 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 + uses the daemon to execute its commands. + + When the daemon is no longer needed, kill it and unset the environment + variable, e.g.: + + kill $(cat $OVN_RUNDIR/ovn-sbctl.pid) + unset OVN_SB_DAEMON + + + When using daemon mode, an alternative to the OVN_SB_DAEMON environment + variable is to specify a path for the Unix socket. When starting the + ovn-sbctl daemon, specify the -u option with a full path to the locaā€ + tion of the socket file. Here is an exmple: + + ovn-sbctl --detach -u /tmp/mysock.ctl + + + Then to connect to the running daemon, use the -u option with the full + path to the socket created when the daemon was started: + + ovn-sbctl -u /tmp/mysock.ctl show + + + Daemon Commands + + Daemon mode is internally implemented using the same mechanism used by + ovn-appctl. One may also use ovn-appctl directly with the following + commands: + + 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 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. + 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 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 + command line override those in the environment. + + --db database + The OVSDB database remote to contact. If the OVN_SB_DB + 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 + By default, or with --leader-only, when the database server + is a clustered database, ovn-sbctl will avoid servers other + than the cluster leader. This ensures that any data that + 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 + database are always serialized even with --no-leader-only). + Refer to Understanding Cluster Consistency in ovsdb(7) for + more information. + + --shuffle-remotes + --no-shuffle-remotes + By default, or with --shuffle-remotes, when there are mulā€ + tiple remotes specified in the OVSDB connection string + specified by --db or the OVN_SB_DB environment variable, + the order of the remotes will be shuffled before the client + 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, + which is particularly useful for testing. + + --no-syslog + By default, ovn-sbctl logs its arguments and the details of + any changes that it makes to the system log. This option + disables this logging. + + This option is equivalent to --verbose=sbctl:syslog:warn. + + --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 + 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. + + --dry-run + Prevents ovn-sbctl from actually modifying the database. + + -t secs + --timeout=secs + By default, or with a secs of 0, ovn-sbctl waits forever + for a response from the database. This option limits runā€ + time to approximately secs seconds. If the timeout expires, + ovn-sbctl will exit with a SIGALRM signal. (A timeout would + normally happen only if the database cannot be contacted, + or if the system is overloaded.) + + 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 + specified, or if it does not begin with /, then it is created in + . + + If --pidfile is not specified, no pidfile is created. + + --overwrite-pidfile + 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. + + 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 + 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 + 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ā€ā€ + 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ā€ + tions without it. + + --no-chdir + 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. + + 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- + 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. + + --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 + 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 + 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 + 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 + 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 + 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, 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 + 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 + definition of each log level. + + Case is not significant within spec. + + 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 + word but has no effect. + + -v + --verbose + 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-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, + local4, local5, local6 or local7. If this option is not specified, + 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 + 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. + + --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ā€ + name. + + --syslog-method=method + 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 + /dev/log UNIX domain socket. + + ā€¢ 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 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ā€ + mands. + + -f format + --format=format + 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 + 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 + members with the noted values: + + caption + 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 + 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- + level array are the cells that constitute the + 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 + 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: + + string (default) + 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 + 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 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 + arrays are printed one per line, with indentation. + + This option does not affect JSON in tables, which is always + printed compactly. + + --bare + Equivalent to --format=list --data=bare --no-headings. + + PKI Options + 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 + identity for outgoing SSL connections. + + -c cert.pem + --certificate=cert.pem + 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 + 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 + verify the certificate specified on -c or --certificate, or + 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 + 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ā€ + 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. + + 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 + certificate as part of the SSL certificate chain. The SSL + protocol does not require the server to send the CA cerā€ + tificate. + + This option is mutually exclusive with -C and --ca-cert. + + Other Options + -h + --help + Prints a brief help message to the console. + + -V + --version + Prints version information to the console. + +COMMANDS + The following sections describe the commands that ovn-sbctl supports. + + OVN_Southbound Commands + These commands work with an OVN_Southbound database as a whole. + + init Initializes the database, if it is empty. If the database + has already been initialized, this command has no effect. + + show Prints a brief overview of the database contents. + + Chassis Commands + These commands manipulate OVN_Southbound chassis. + + [--may-exist] chassis-add chassis encap-type encap-ip + Creates a new chassis named chassis. encap-type is a + comma-separated list of tunnel types. The chassis will + have one encap entry for each specified tunnel type with + encap-ip as the destination IP for each. + + Without --may-exist, attempting to create a chassis that + exists is an error. With --may-exist, this command does + nothing if chassis already exists. + + [--if-exists] chassis-del chassis + Deletes chassis and its encaps and gateway_ports. + + Without --if-exists, attempting to delete a chassis that + does not exist is an error. With --if-exists attempting + to delete a chassis that does not exist has no effect. + + Port Binding Commands + These commands manipulate OVN_Southbound port bindings. + + [--may-exist] lsp-bind logical-port chassis + 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-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 efā€ + fect. + + Logical Flow Commands + [--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 + given as a UUID or as a datapath name (reporting an error if + multiple datapaths have the same name). + + 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. (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.) + + If --uuid is specified, the output includes the first 32 bits of + each logical flowā€™s UUID. This makes it easier to find the Openā€ + Flow flows that correspond to a given logical flow. + + 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 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 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 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. + + count-flows [logical-datapath] + prints numbers of logical flows per table and per datapath. + + 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 adā€ + ministrator to use \fBovn\-sbctl\fR to configure database connections. + + get-connection + Prints the configured connection(s). + + del-connection + Deletes the configured connection(s). + + [--inactivity-probe=msecs] set-connection target... + 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 paā€ + rameters are required: + + private-key + 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 + trustworthy peer. + + ca-cert + 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 + database server. + + get-ssl + Prints the SSL configuration. + + del-ssl + Deletes the current SSL configuration. + + [--bootstrap] set-ssl private-key certificate ca-cert [ssl-proā€ + tocol-list [ssl-cipher-list]] + Sets the SSL configuration. + + Database Commands + These commands query and modify the contents of ovsdb tables. They are + a slight abstraction of the ovsdb interface and as such they operate at + a lower level than other ovn-sbctl commands. + + Identifying Tables, Records, and Columns + + 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 + 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 + 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, + e.g. d or dhcp is sufficient to identify the DHCP_Options table. + + Database Values + + Each column in the database accepts a fixed type of data. The currently + defined basic types, and their representations, are: + + integer + A decimal integer in the range -2**63 to 2**63-1, incluā€ + sive. + + real A floating-point number. + + 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ā€ + 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 + 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 + 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 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 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 + [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 + 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 igā€ + nores any record that does not exist, without producing + any output. + + [--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ā€ + 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 + value, respectively. + + 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 + pairs, first all the keys are compared, and values + 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 + 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 the flood-vlans column is + 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 + 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 + {<=}.) + + {not-in} + 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 + not those that lack an mtu key. + + 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 + key. + + 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 + invocation will be wrong. + + [--if-exists] [--id=@name] get table record [column[:key]]... + 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 + 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 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 + both are omitted, then get has no effect except to verify + that record exists in table. + + --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 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 + 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 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 + 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ā€ + 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 + 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. + + 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 + 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 + record does not exist. + + [--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 + 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 + references may precede or follow the create command. + + If a valid uuid is specified, then it is used as the UUID + 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 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 + 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 + some examples that show how to do this. + + [--if-exists] destroy table record... + 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 + for more information. + + 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 + 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 + 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ā€ā€ + 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 + ovs-vsctl initially connects to the database. + + 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ā€ + mand and its arguments. + +ENVIRONMENT + OVN_SB_DAEMON + If set, this should name the Unix domain socket for an ovn-sbctl + server process. See Daemon Mode, above, for more information. + + OVN_SBCTL_OPTIONS + 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 + not used. + +EXIT STATUS + 0 Successful program execution. + + 1 Usage, syntax, or network error. + +SEE ALSO + ovn-sb(5), ovn-appctl(8). + +OVN 23.06.3 ovn-sbctl ovn-sbctl(8) diff --git a/src/static/support/dist-docs-branch-23.06/ovn-trace.8 b/src/static/support/dist-docs-branch-23.06/ovn-trace.8 new file mode 100644 index 00000000..c1c37b2c --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-trace.8 @@ -0,0 +1,418 @@ +'\" p +.\" -*- nroff -*- +.TH "ovn-trace" 8 "ovn-trace" "OVN 23\[char46]06\[char46]3" "OVN Manual" +.fp 5 L CR \\" Make fixed-width font available as \\fL. +.de TQ +. br +. ns +. TP "\\$1" +.. +.de ST +. PP +. RS -0.15in +. I "\\$1" +. RE +.. +.de SU +. PP +. I "\\$1" +.. +.PP +.SH "NAME" +.PP +.PP +ovn-trace \- Open Virtual Network logical network tracing utility +.SH "SYNOPSIS" +.PP +\fBovn\-trace\fR [\fIoptions\fR] \fI[datapath]\fR \fImicroflow\fR +.PP +\fBovn\-trace\fR [\fIoptions\fR] \fB\-\-detach\fR +.SH "DESCRIPTION" +.PP +.PP +This utility simulates packet forwarding within an OVN logical network\[char46] It can be used to run through ``what-if\(cq\(cq scenarios: if a packet originates at a logical port, what will happen to it and where will it ultimately end up? Users already familiar with the Open vSwitch \fBofproto/trace\fR command described in \fBovs\-vswitch\fR(8) will find \fBovn\-trace\fR to be a similar tool for logical networks\[char46] +.PP +.PP +\fBovn\-trace\fR works by reading the \fBLogical_Flow\fR and other tables from the OVN southbound database (see \fBovn\-sb\fR(5))\[char46] It simulates a packet\(cqs path through logical networks by repeatedly looking it up in the logical flow table, following the entire tree of possibilities\[char46] +.PP +.PP +\fBovn\-trace\fR simulates only the OVN logical network\[char46] It does not simulate the physical elements on which the logical network is layered\[char46] This means that, for example, it is unimportant how VMs are distributed among hypervisors, or whether their hypervisors are functioning and reachable, so \fBovn\-trace\fR will yield the same results regardless\[char46] There is one important exception: \fBovn\-northd\fR, the daemon that generates the logical flows that \fBovn\-trace\fR simulates, treats logical ports differently based on whether they are up or down\[char46] Thus, if you see surprising results, ensure that the ports involved in a simulation are up\[char46] +.PP +.PP +The simplest way to use \fBovn\-trace\fR is to provide the \fImicroflow\fR (and optional \fIdatapath\fR) arguments on the command line\[char46] In this case, it simulates the behavior of a single packet and exits\[char46] For an alternate usage model, see \fBDaemon Mode\fR below\[char46] +.PP +.PP +The optional \fIdatapath\fR argument specifies the name of a logical datapath\[char46] Acceptable names are the \fBname\fR from the northbound \fBLogical_Switch\fR or \fBLogical_Router\fR table, the UUID of a record from one of those tables, or the UUID of a record from the southbound \fBDatapath_Binding\fR table\[char46] (The \fBdatapath\fR is optional because \fBovn\-trace\fR can figure it out from the \fIinport\fR that the \fImicroflow\fR matches\[char46]) +.PP +.PP +The \fImicroflow\fR argument describes the packet whose forwarding is to be simulated, in the syntax of an OVN logical expression, as described in \fBovn\-sb\fR(5), to express constraints\[char46] The parser understands prerequisites; for example, if the expression refers to \fBip4\[char46]src\fR, there is no need to explicitly state \fBip4\fR or \fBeth\[char46]type == 0x800\fR\[char46] +.PP +.PP +For reasonable L2 behavior, the microflow should include at least \fBinport\fR and \fBeth\[char46]dst\fR, plus \fBeth\[char46]src\fR if port security is enabled\[char46] For example: +.PP +.nf +\fB +.br +\fB inport == \(dqlp11\(dq && eth\[char46]src == 00:01:02:03:04:05 && eth\[char46]dst == ff:ff:ff:ff:ff:ff +.br +\fB \fR +.fi +.PP +.PP +For reasonable L3 behavior, \fImicroflow\fR should also include \fBip4\[char46]src\fR and \fBip4\[char46]dst\fR (or \fBip6\[char46]src\fR and \fBip6\[char46]dst\fR) and \fBip\[char46]ttl\fR\[char46] For example: +.PP +.nf +\fB +.br +\fB inport == \(dqlp111\(dq && eth\[char46]src == f0:00:00:00:01:11 && eth\[char46]dst == 00:00:00:00:ff:11 +.br +\fB && ip4\[char46]src == 192\[char46]168\[char46]11\[char46]1 && ip4\[char46]dst == 192\[char46]168\[char46]22\[char46]2 && ip\[char46]ttl == 64 +.br +\fB \fR +.fi +.PP +.PP +Here\(cqs an ARP microflow example: +.PP +.nf +\fB +.br +\fB inport == \(dqlp123\(dq +.br +\fB && eth\[char46]dst == ff:ff:ff:ff:ff:ff && eth\[char46]src == f0:00:00:00:01:11 +.br +\fB && arp\[char46]op == 1 && arp\[char46]sha == f0:00:00:00:01:11 && arp\[char46]spa == 192\[char46]168\[char46]1\[char46]11 +.br +\fB && arp\[char46]tha == ff:ff:ff:ff:ff:ff && arp\[char46]tpa == 192\[char46]168\[char46]2\[char46]22 +.br +\fB \fR +.fi +.PP +.PP +\fBovn\-trace\fR will reject erroneous microflow expressions, which beyond syntax errors fall into two categories\[char46] First, they can be ambiguous\[char46] For example, \fBtcp\[char46]src == 80\fR is ambiguous because it does not state IPv4 or IPv6 as the Ethernet type\[char46] \fBip4 +&& tcp\[char46]src > 1024\fR is also ambiguous because it does not constrain bits of \fBtcp\[char46]src\fR to particular values\[char46] Second, they can be contradictory, e\[char46]g\[char46] \fBip4 && ip6\fR\[char46] +.SH "OUTPUT" +.PP +.PP +\fBovn\-trace\fR supports the three different forms of output, each described in a separate section below\[char46] Regardless of the selected output format, \fBovn\-trace\fR starts the output with a line that shows the microflow being traced in OpenFlow syntax\[char46] +.SS "Detailed Output" +.PP +.PP +The detailed form of output is also the default form\[char46] This form groups output into sections headed up by the ingress or egress pipeline being traversed\[char46] Each pipeline lists each table that was visited (by number and name), the \fBovn\-northd\fR source file and line number of the code that added the flow, the match expression and priority of the logical flow that was matched, and the actions that were executed\[char46] +.PP +.PP +The execution of OVN logical actions naturally forms a ``control stack\(cq\(cq that resembles that of a program in conventional programming languages such as C or Java\[char46] Because the \fBnext\fR action that calls into another logical flow table for a lookup is a recursive construct, OVN ``programs\(cq\(cq in practice tend to form deep control stacks that, displayed in the obvious way using additional indentation for each level, quickly use up the horizontal space on all but the widest displays\[char46] To make detailed output more readable, without loss of generality, \fBovn\-trace\fR omits indentation for ``tail recursion,\(cq\(cq that is, when \fBnext\fR is the last action in a logical flow, it does not indent details of the next table lookup more deeply\[char46] Output still uses indentation when it is needed for clarity\[char46] +.PP +.PP +OVN ``programs\(cq\(cq traces also tend to encounter long strings of logical flows with match expression \fB1\fR (which matches every packet) and the single action \fBnext;\fR\[char46] These are uninteresting and merely clutter output, so \fBovn\-trace\fR omits them entirely even from detailed output\[char46] +.PP +.PP +The following excerpt from detailed \fBovn\-trace\fR output shows a section for a packet traversing the ingress pipeline of logical datapath \fBls1\fR with ingress logical port \fBlp111\fR\[char46] The packet matches a logical flow in table 0 (aka \fBls_in_port_sec_l2\fR) with priority 50 and executes \fBnext(1);\fR to pass to table 1\[char46] Tables 1 through 11 are trivial and omitted\[char46] In table 19 (aka \fBls_in_l2_lkup\fR), the packet matches a flow with priority 50 based on its Ethernet destination address and the flow\(cqs actions output the packet to the \fBlrp11\-attachement\fR logical port\[char46] +.PP +.nf +\fL +.br +\fL ingress(dp=\(dqls1\(dq, inport=\(dqlp111\(dq) +.br +\fL \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- +.br +\fL 0\[char46] ls_in_port_sec_l2: inport == \(dqlp111\(dq, priority 50 +.br +\fL next(1); +.br +\fL 19\[char46] ls_in_l2_lkup: eth\[char46]dst == 00:00:00:00:ff:11, priority 50 +.br +\fL outport = \(dqlrp11\-attachment\(dq; +.br +\fL output; +.br +\fL \fR +.fi +.SS "Summary Output" +.PP +.PP +Summary output includes the logical pipelines visited by a packet and the logical actions executed on it\[char46] Compared to the detailed output, however, it removes details of tables and logical flows traversed by a packet\[char46] It uses a format closer to that of a programming language and does not attempt to avoid indentation\[char46] The summary output equivalent to the above detailed output fragment is: +.PP +.nf +\fL +.br +\fL ingress(dp=\(dqls1\(dq, inport=\(dqlp111\(dq) { +.br +\fL outport = \(dqlrp11\-attachment\(dq; +.br +\fL output; +.br +\fL \[char46]\[char46]\[char46] +.br +\fL }; +.br +\fL \fR +.fi +.SS "Minimal Output" +.PP +.PP +Minimal output includes only actions that modify packet data (not including OVN registers or metadata such as \fBoutport\fR) and \fBoutput\fR actions that actually deliver a packet to a logical port (excluding patch ports)\[char46] The operands of actions that modify packet data are displayed reduced to constants, e\[char46]g\[char46] \fBip4\[char46]dst = +reg0;\fR might be show as \fBip4\[char46]dst = 192\[char46]168\[char46]0\[char46]1;\fR if that was the value actually loaded\[char46] This yields output even simpler than the summary format\[char46] (Users familiar with Open vSwitch may recognize this as similar in spirit to the datapath actions listed at the bottom of \fBofproto/trace\fR output\[char46]) +.PP +.PP +The minimal output format reflects the externally seen behavior of the logical networks more than it does the implementation\[char46] This makes this output format the most suitable for use in regression tests, because it is least likely to change when logical flow tables are rearranged without semantic change\[char46] +.SH "STATEFUL ACTIONS" +.PP +.PP +Some OVN logical actions use or update state that is not available in the southbound database\[char46] \fBovn\-trace\fR handles these actions as described below: +.RS +.TP +\fBct_next\fR +By default \fBovn\-trace\fR treats flows as ``tracked\(cq\(cq and ``established\[char46]\(cq\(cq See the description of the \fB\-\-ct\fR option for a way to override this behavior\[char46] +.TP +\fBct_dnat\fR (without an argument) +Forks the pipeline\[char46] In one fork, advances to the next table as if \fBnext;\fR were executed\[char46] The packet is not changed, on the assumption that no NAT state was available\[char46] In the other fork, the pipeline continues without change after the \fBct_dnat\fR action\[char46] +.TP +\fBct_snat\fR (without an argument) +This action distinguishes between gateway routers and distributed routers\[char46] A gateway router is defined as a logical datapath that contains an \fBl3gateway\fR port; any other logical datapath is a distributed router\[char46] On a gateway router, \fBct_snat;\fR is treated as a no-op\[char46] On a distributed router, it is treated the same way as \fBct_dnat;\fR\[char46] +.TP +\fBct_dnat(\fIip\fB)\fR +.TQ .5in +\fBct_snat(\fIip\fB)\fR +Forks the pipeline\[char46] In one fork, sets \fBip4\[char46]dst\fR (or \fBip4\[char46]src\fR) to \fIip\fR and \fBct\[char46]dnat\fR (or \fBct\[char46]snat\fR) to 1 and advances to the next table as if \fBnext;\fR were executed\[char46] In the other fork, the pipeline continues without change after the \fBct_dnat\fR (or \fBct_snat\fR) action\[char46] +.TP +\fBct_lb;\fR +.TQ .5in +\fBct_lb(\fIip\fB\fR[\fB:\fIport\fB\fR]\[char46]\[char46]\[char46]\fB);\fR +Forks the pipeline\[char46] In one fork, sets \fBip4\[char46]dst\fR (or \fBip6\[char46]dst\fR) to one of the load-balancer addresses and the destination port to its associated port, if any, and sets \fBct\[char46]dnat\fR to 1\[char46] With one or more arguments, gives preference to the address specified on \fB\-\-lb\-dst\fR, if any; without arguments, uses the address and port specified on \fB\-\-lb\-dst\fR\[char46] In the other fork, the pipeline continues without change after the \fBct_lb\fR action\[char46] +.TP +\fBct_commit\fR +.TQ .5in +\fBput_arp\fR +.TQ .5in +\fBput_nd\fR +These actions are treated as no-ops\[char46] +.RE +.SH "DAEMON MODE" +.PP +.PP +If \fBovn\-trace\fR is invoked with the \fB\-\-detach\fR option (see \fBDaemon Options\fR, below), it runs in the background as a daemon and accepts commands from \fBovs\-appctl\fR (or another JSON-RPC client) indefinitely\[char46] The currently supported commands are described below\[char46] +.PP +.PP +.RS +.TP +\fBtrace\fR [\fIoptions\fR] [\fIdatapath\fR] \fImicroflow\fR +Traces \fImicroflow\fR through \fIdatapath\fR and replies with the results of the trace\[char46] Accepts the \fIoptions\fR described under \fBTrace Options\fR below\[char46] +.TP +\fBexit\fR +Causes \fBovn\-trace\fR to gracefully terminate\[char46] +.RE +.SH "OPTIONS" +.SS "Trace Options" +.TP +\fB\-\-detailed\fR +.TQ .5in +\fB\-\-summary\fR +.TQ .5in +\fB\-\-minimal\fR +These options control the form and level of detail in \fBovn\-trace\fR output\[char46] 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\[char46] If none of these options is given, \fB\-\-detailed\fR is the default\[char46] See \fBOutput\fR, above, for a description of each kind of output\[char46] +.TP +\fB\-\-all\fR +Selects all three forms of output\[char46] +.TP +\fB\-\-ovs\fR[\fB=\fR\fIremote\fR] +Makes \fBovn\-trace\fR attempt to obtain and display the OpenFlow flows that correspond to each OVN logical flow\[char46] To do so, \fBovn\-trace\fR connects to \fIremote\fR (by default, \fBunix:/br\-int\[char46]mgmt\fR) over OpenFlow and retrieves the flows\[char46] If \fIremote\fR is specified, it must be an active OpenFlow connection method described in \fBovsdb\fR(7)\[char46] +.IP +To make the best use of the output, it is important to understand the relationship between logical flows and OpenFlow flows\[char46] \fBovn\-architecture\fR(7), under \fBArchitectural Physical Life +Cycle of a Packet\fR, describes this relationship\[char46] Keep in mind the following points: +.RS +.IP \(bu +\fBovn\-trace\fR currently shows all the OpenFlow flows to which a logical flow corresponds, even though an actual packet ordinarily matches only one of these\[char46] +.IP \(bu +Some logical flows can map to the Open vSwitch ``conjunctive match\(cq\(cq extension (see \fBovs\-fields\fR(7))\[char46] Currently \fBovn\-trace\fR cannot display the flows with \fBconjunction\fR actions that effectively produce the \fBconj_id\fR match\[char46] +.IP \(bu +Some logical flows may not be represented in the OpenFlow tables on a given hypervisor, if they could not be used on that hypervisor\[char46] +.IP \(bu +Some OpenFlow flows do not correspond to logical flows, such as OpenFlow flows that map between physical and logical ports\[char46] These flows will never show up in a trace\[char46] +.IP \(bu +When \fBovn\-trace\fR omits uninteresting logical flows from output, it does not look up the corresponding OpenFlow flows\[char46] +.RE +.TP +\fB\-\-ct=\fIflags\fB\fR +This option sets the \fBct_state\fR flags that a \fBct_next\fR logical action will report\[char46] The \fIflags\fR must be a comma- or space-separated list of the following connection tracking flags: +.RS +.IP \(bu +\fBtrk\fR: Include to indicate connection tracking has taken place\[char46] (This bit is set automatically even if not listed in \fIflags\fR\[char46] +.IP \(bu +\fBnew\fR: Include to indicate a new flow\[char46] +.IP \(bu +\fBest\fR: Include to indicate an established flow\[char46] +.IP \(bu +\fBrel\fR: Include to indicate a related flow\[char46] +.IP \(bu +\fBrpl\fR: Include to indicate a reply flow\[char46] +.IP \(bu +\fBinv\fR: Include to indicate a connection entry in a bad state\[char46] +.IP \(bu +\fBdnat\fR: Include to indicate a packet whose destination IP address has been changed\[char46] +.IP \(bu +\fBsnat\fR: Include to indicate a packet whose source IP address has been changed\[char46] +.RE +.IP +The \fBct_next\fR action is used to implement the OVN distributed firewall\[char46] For testing, useful flag combinations include: +.RS +.IP \(bu +\fBtrk,new\fR: A packet in a flow in either direction through a firewall that has not yet been committed (with \fBct_commit\fR)\[char46] +.IP \(bu +\fBtrk,est\fR: A packet in an established flow going out through a firewall\[char46] +.IP \(bu +\fBtrk,rpl\fR: A packet coming in through a firewall in reply to an established flow\[char46] +.IP \(bu +\fBtrk,inv\fR: An invalid packet in either direction\[char46] +.RE +.IP +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\[char46] Use multiple \fB\-\-ct\fR options to specify the flags for multiple \fBct_next\fR actions\[char46] +.IP +When \fB\-\-ct\fR is unspecified, or when there are fewer \fB\-\-ct\fR options than \fBct_next\fR actions, the \fIflags\fR default to \fBtrk,est\fR\[char46] +.TP +\fB\-\-lb\-dst=\fR\fIip\fR[\fB:\fIport\fB\fR] +Sets the IP from VIP pool to use as destination of the packet\[char46] \fB\-\-lb\-dst\fR is not available in daemon mode\[char46] +.TP +\fB\-\-select\-id=\fR\fIid\fR +Specify the \fIid\fR to be selected by the \fBselect\fR action\[char46] \fIid\fR must be one of the values listed in the \fBselect\fR action\[char46] Otherwise, a random id is selected from the list, as if \fB\-\-select\-id\fR were not specified\[char46] \fB\-\-select\-id\fR is not available in daemon mode\[char46] +.TP +\fB\-\-friendly\-names\fR +.TQ .5in +\fB\-\-no\-friendly\-names\fR +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\[char46] They do usually include friendlier names, but the long, hard-to-read names are the ones that appear in matches and actions\[char46] By default, or with \fB\-\-friendly\-names\fR, \fBovn\-trace\fR substitutes these friendlier names for the long names in its output\[char46] Use \fB\-\-no\-friendly\-names\fR to disable this behavior; this option might be useful, for example, if a program is going to parse \fBovn\-trace\fR output\[char46] +.SS "Daemon Options" +.TP +\fB\-\-pidfile\fR[\fB=\fR\fIpidfile\fR] +Causes a file (by default, \fB\fIprogram\fB\[char46]pid\fR) to be created indicating the PID of the running process\[char46] If the \fIpidfile\fR argument is not specified, or if it does not begin with \fB/\fR, then it is created in \fB\fR\[char46] +.IP +If \fB\-\-pidfile\fR is not specified, no pidfile is created\[char46] +.TP +\fB\-\-overwrite\-pidfile\fR +By default, when \fB\-\-pidfile\fR is specified and the specified pidfile already exists and is locked by a running process, the daemon refuses to start\[char46] Specify \fB\-\-overwrite\-pidfile\fR to cause it to instead overwrite the pidfile\[char46] +.IP +When \fB\-\-pidfile\fR is not specified, this option has no effect\[char46] +.TP +\fB\-\-detach\fR +Runs this program as a background process\[char46] 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 \fB\-\-no\-chdir\fR is specified)\[char46] After the child completes its initialization, the parent exits\[char46] +.TP +\fB\-\-monitor\fR +Creates an additional process to monitor this program\[char46] If it dies due to a signal that indicates a programming error (\fBSIGABRT\fR, \fBSIGALRM\fR, \fBSIGBUS\fR, \fBSIGFPE\fR, \fBSIGILL\fR, \fBSIGPIPE\fR, \fBSIGSEGV\fR, \fBSIGXCPU\fR, or \fBSIGXFSZ\fR) then the monitor process starts a new copy of it\[char46] If the daemon dies or exits for another reason, the monitor process exits\[char46] +.IP +This option is normally used with \fB\-\-detach\fR, but it also functions without it\[char46] +.TP +\fB\-\-no\-chdir\fR +By default, when \fB\-\-detach\fR is specified, the daemon changes its current working directory to the root directory after it detaches\[char46] Otherwise, invoking the daemon from a carelessly chosen directory would prevent the administrator from unmounting the file system that holds that directory\[char46] +.IP +Specifying \fB\-\-no\-chdir\fR suppresses this behavior, preventing the daemon from changing its current working directory\[char46] 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\[char46] +.IP +This option has no effect when \fB\-\-detach\fR is not specified\[char46] +.TP +\fB\-\-no\-self\-confinement\fR +By default this daemon will try to self-confine itself to work with files under well-known directories determined at build time\[char46] 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\[char46] Note that in contrast to other access control implementations that are typically enforced from kernel-space (e\[char46]g\[char46] 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 additional layer of security\[char46] +.TP +\fB\-\-user=\fR\fIuser\fR\fB:\fR\fIgroup\fR +Causes this program to run as a different user specified in \fIuser\fR\fB:\fR\fIgroup\fR, thus dropping most of the root privileges\[char46] Short forms \fIuser\fR and \fB:\fR\fIgroup\fR are also allowed, with current user or group assumed, respectively\[char46] Only daemons started by the root user accepts this argument\[char46] +.IP +On Linux, daemons will be granted \fBCAP_IPC_LOCK\fR and \fBCAP_NET_BIND_SERVICES\fR before dropping root privileges\[char46] Daemons that interact with a datapath, such as \fBovs\-vswitchd\fR, will be granted three additional capabilities, namely \fBCAP_NET_ADMIN\fR, \fBCAP_NET_BROADCAST\fR and \fBCAP_NET_RAW\fR\[char46] The capability change will apply even if the new user is root\[char46] +.IP +On Windows, this option is not currently supported\[char46] For security reasons, specifying this option will cause the daemon process not to start\[char46] +.SS "Logging Options" +.TP +\fB\-v\fR[\fIspec\fR] +.TQ .5in +\fB\-\-verbose=\fR[\fIspec\fR] +Sets logging levels\[char46] Without any \fIspec\fR, sets the log level for every module and destination to \fBdbg\fR\[char46] Otherwise, \fIspec\fR is a list of words separated by spaces or commas or colons, up to one from each category below: +.RS +.IP \(bu +A valid module name, as displayed by the \fBvlog/list\fR command on \fBovs\-appctl\fR(8), limits the log level change to the specified module\[char46] +.IP \(bu +\fBsyslog\fR, \fBconsole\fR, or \fBfile\fR, to limit the log level change to only to the system log, to the console, or to a file, respectively\[char46] (If \fB\-\-detach\fR is specified, the daemon closes its standard file descriptors, so logging to the console will have no effect\[char46]) +.IP +On Windows platform, \fBsyslog\fR is accepted as a word and is only useful along with the \fB\-\-syslog\-target\fR option (the word has no effect otherwise)\[char46] +.IP \(bu +\fBoff\fR, \fBemer\fR, \fBerr\fR, \fBwarn\fR, \fBinfo\fR, or \fBdbg\fR, to control the log level\[char46] Messages of the given severity or higher will be logged, and messages of lower severity will be filtered out\[char46] \fBoff\fR filters out all messages\[char46] See \fBovs\-appctl\fR(8) for a definition of each log level\[char46] +.RE +.IP +Case is not significant within \fIspec\fR\[char46] +.IP +Regardless of the log levels set for \fBfile\fR, logging to a file will not take place unless \fB\-\-log\-file\fR is also specified (see below)\[char46] +.IP +For compatibility with older versions of OVS, \fBany\fR is accepted as a word but has no effect\[char46] +.TP +\fB\-v\fR +.TQ .5in +\fB\-\-verbose\fR +Sets the maximum logging verbosity level, equivalent to \fB\-\-verbose=dbg\fR\[char46] +.TP +\fB\-vPATTERN:\fR\fIdestination\fR\fB:\fR\fIpattern\fR +.TQ .5in +\fB\-\-verbose=PATTERN:\fR\fIdestination\fR\fB:\fR\fIpattern\fR +Sets the log pattern for \fIdestination\fR to \fIpattern\fR\[char46] Refer to \fBovs\-appctl\fR(8) for a description of the valid syntax for \fIpattern\fR\[char46] +.TP +\fB\-vFACILITY:\fR\fIfacility\fR +.TQ .5in +\fB\-\-verbose=FACILITY:\fR\fIfacility\fR +Sets the RFC5424 facility of the log message\[char46] \fIfacility\fR can be one of \fBkern\fR, \fBuser\fR, \fBmail\fR, \fBdaemon\fR, \fBauth\fR, \fBsyslog\fR, \fBlpr\fR, \fBnews\fR, \fBuucp\fR, \fBclock\fR, \fBftp\fR, \fBntp\fR, \fBaudit\fR, \fBalert\fR, \fBclock2\fR, \fBlocal0\fR, \fBlocal1\fR, \fBlocal2\fR, \fBlocal3\fR, \fBlocal4\fR, \fBlocal5\fR, \fBlocal6\fR or \fBlocal7\fR\[char46] If this option is not specified, \fBdaemon\fR is used as the default for the local system syslog and \fBlocal0\fR is used while sending a message to the target provided via the \fB\-\-syslog\-target\fR option\[char46] +.TP +\fB\-\-log\-file\fR[\fB=\fR\fIfile\fR] +Enables logging to a file\[char46] If \fIfile\fR is specified, then it is used as the exact name for the log file\[char46] The default log file name used if \fIfile\fR is omitted is \fB/usr/local/var/log/ovn/\fIprogram\fB\[char46]log\fR\[char46] +.TP +\fB\-\-syslog\-target=\fR\fIhost\fR\fB:\fR\fIport\fR +Send syslog messages to UDP \fIport\fR on \fIhost\fR, in addition to the system syslog\[char46] The \fIhost\fR must be a numerical IP address, not a hostname\[char46] +.TP +\fB\-\-syslog\-method=\fR\fImethod\fR +Specify \fImethod\fR as how syslog messages should be sent to syslog daemon\[char46] The following forms are supported: +.RS +.IP \(bu +\fBlibc\fR, to use the libc \fBsyslog()\fR function\[char46] Downside of using this options is that libc adds fixed prefix to every message before it is actually sent to the syslog daemon over \fB/dev/log\fR UNIX domain socket\[char46] +.IP \(bu +\fBunix:\fIfile\fB\fR, to use a UNIX domain socket directly\[char46] It is possible to specify arbitrary message format with this option\[char46] However, \fBrsyslogd 8\[char46]9\fR and older versions use hard coded parser function anyway that limits UNIX domain socket use\[char46] If you want to use arbitrary message format with older \fBrsyslogd\fR versions, then use UDP socket to localhost IP address instead\[char46] +.IP \(bu +\fBudp:\fIip\fB:\fIport\fB\fR, to use a UDP socket\[char46] With this method it is possible to use arbitrary message format also with older \fBrsyslogd\fR\[char46] When sending syslog messages over UDP socket extra precaution needs to be taken into account, for example, 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\[char46] +.IP \(bu +\fBnull\fR, to discard all messages logged to syslog\[char46] +.RE +.IP +The default is taken from the \fBOVS_SYSLOG_METHOD\fR environment variable; if it is unset, the default is \fBlibc\fR\[char46] +.SS "PKI Options" +.PP +.PP +PKI configuration is required to use SSL for the connection to the database (and the switch, if \fB\-\-ovs\fR is specified)\[char46] +.RS +.TP +\fB\-p\fR \fIprivkey\[char46]pem\fR +.TQ .5in +\fB\-\-private\-key=\fR\fIprivkey\[char46]pem\fR +Specifies a PEM file containing the private key used as identity for outgoing SSL connections\[char46] +.TP +\fB\-c\fR \fIcert\[char46]pem\fR +.TQ .5in +\fB\-\-certificate=\fR\fIcert\[char46]pem\fR +Specifies a PEM file containing a certificate that certifies the private key specified on \fB\-p\fR or \fB\-\-private\-key\fR to be trustworthy\[char46] The certificate must be signed by the certificate authority (CA) that the peer in SSL connections will use to verify it\[char46] +.TP +\fB\-C\fR \fIcacert\[char46]pem\fR +.TQ .5in +\fB\-\-ca\-cert=\fR\fIcacert\[char46]pem\fR +Specifies a PEM file containing the CA certificate for verifying certificates presented to this program by SSL peers\[char46] (This may be the same certificate that SSL peers use to verify the certificate specified on \fB\-c\fR or \fB\-\-certificate\fR, or it may be a different one, depending on the PKI design in use\[char46]) +.TP +\fB\-C none\fR +.TQ .5in +\fB\-\-ca\-cert=none\fR +Disables verification of certificates presented by SSL peers\[char46] This introduces a security risk, because it means that certificates cannot be verified to be those of known trusted hosts\[char46] +.RE +.SS "Other Options" +.TP +\fB\-\-db\fR \fIdatabase\fR +The OVSDB database remote to contact\[char46] If the \fBOVN_SB_DB\fR environment variable is set, its value is used as the default\[char46] Otherwise, the default is \fBunix:/db\[char46]sock\fR, but this default is unlikely to be useful outside of single-machine OVN test environments\[char46] +.RS +.TP +\fB\-h\fR +.TQ .5in +\fB\-\-help\fR +Prints a brief help message to the console\[char46] +.TP +\fB\-V\fR +.TQ .5in +\fB\-\-version\fR +Prints version information to the console\[char46] +.RE diff --git a/src/static/support/dist-docs-branch-23.06/ovn-trace.8.html b/src/static/support/dist-docs-branch-23.06/ovn-trace.8.html new file mode 100644 index 00000000..b7f84819 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-trace.8.html @@ -0,0 +1,572 @@ +
+ovn-trace(8)                      OVN Manual                      ovn-trace(8)
+
+NAME
+       ovn-trace - Open Virtual Network logical network tracing utility
+
+SYNOPSIS
+       ovn-trace [options] [datapath] microflow
+
+       ovn-trace [options] --detach
+
+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 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
+       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ā€
+       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 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
+       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
+       inport that the microflow matches.)
+
+       The  microflow  argument describes the packet whose forwarding is to be
+       simulated, in the syntax of an OVN logical expression, as described  in
+       ovn-sb(5),  to  express  constraints.  The parser understands prerequiā€
+       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 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
+
+
+       For  reasonable  L3 behavior, microflow should also include ip4.src and
+       ip4.dst (or ip6.src and ip6.dst) and ip.ttl. For example:
+
+           inport == "lp111" &&&& eth.src == f0:00:00:00:01:11 &&&& eth.dst == 00:00:00:00:ff:11
+           &&&& ip4.src == 192.168.11.1 &&&& ip4.dst == 192.168.22.2 &&&& ip.ttl == 64
+
+
+       Hereā€™s an ARP microflow example:
+
+           inport == "lp123"
+           &&&& eth.dst == ff:ff:ff:ff:ff:ff &&&& eth.src == f0:00:00:00:01:11
+           &&&& arp.op == 1 &&&& arp.sha == f0:00:00:00:01:11 &&&& arp.spa == 192.168.1.11
+           &&&& arp.tha == ff:ff:ff:ff:ff:ff &&&& arp.tpa == 192.168.2.22
+
+
+       ovn-trace will reject erroneous  microflow  expressions,  which  beyond
+       syntax  errors  fall into two categories. First, they can be ambiguous.
+       For example, tcp.src == 80 is ambiguous because it does not state  IPv4
+       or  IPv6  as the Ethernet type. ip4 &&&& tcp.src >gt;>gt; 1024 is also ambiguous
+       because it does not constrain bits of  tcp.src  to  particular  values.
+       Second, they can be contradictory, e.g. ip4 &&&& ip6.
+
+OUTPUT
+       ovn-trace  supports the three different forms of output, each described
+       in a separate section below. Regardless of the selected output  format,
+       ovn-trace  starts the output with a line that shows the microflow being
+       traced in OpenFlow syntax.
+
+   Detailed Output
+       The detailed form of output is also the default form. This form  groups
+       output  into sections headed up by the ingress or egress pipeline being
+       traversed. Each pipeline lists each table that was visited  (by  number
+       and  name), the ovn-northd source file and line number of the code that
+       added the flow, the match expression and priority of the  logical  flow
+       that was matched, and the actions that were executed.
+
+       The  execution  of  OVN  logical  actions  naturally  forms a ``control
+       stackā€™ā€™ that resembles that of a program  in  conventional  programming
+       languages  such  as  C or Java. Because the next action that calls into
+       another logical flow table for a lookup is a recursive  construct,  OVN
+       ``programsā€™ā€™  in  practice  tend to form deep control stacks that, disā€
+       played in the obvious way using additional indentation for each  level,
+       quickly  use up the horizontal space on all but the widest displays. To
+       make  detailed  output  more  readable,  without  loss  of  generality,
+       ovn-trace  omits indentation for ``tail recursion,ā€™ā€™ that is, when next
+       is the last action in a logical flow, it does not indent details of the
+       next table lookup more deeply. Output still uses indentation when it is
+       needed for clarity.
+
+       OVN ``programsā€™ā€™ traces also tend to encounter long strings of  logical
+       flows with match expression 1 (which matches every packet) and the sinā€
+       gle action next;. These are uninteresting and merely clutter output, so
+       ovn-trace omits them entirely even from detailed output.
+
+       The  following  excerpt  from detailed ovn-trace output shows a section
+       for a packet traversing the ingress pipeline of  logical  datapath  ls1
+       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
+       based on its Ethernet destination address and the flowā€™s actions output
+       the packet to the lrp11-attachement logical port.
+
+           ingress(dp="ls1", inport="lp111")
+           ---------------------------------
+           0. ls_in_port_sec_l2: inport == "lp111", priority 50
+           next(1);
+           19. ls_in_l2_lkup: eth.dst == 00:00:00:00:ff:11, priority 50
+           outport = "lrp11-attachment";
+           output;
+
+
+   Summary Output
+       Summary output includes the logical pipelines visited by a  packet  and
+       the  logical  actions  executed on it. Compared to the detailed output,
+       however, it removes details of tables and logical flows traversed by  a
+       packet.  It  uses a format closer to that of a programming language and
+       does not attempt to avoid indentation. The summary output equivalent to
+       the above detailed output fragment is:
+
+           ingress(dp="ls1", inport="lp111") {
+           outport = "lrp11-attachment";
+           output;
+           ...
+           };
+
+
+   Minimal 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.)
+
+       The  minimal output format reflects the externally seen behavior of the
+       logical networks more than it does the implementation. This makes  this
+       output format the most suitable for use in regression tests, because it
+       is least likely to change when logical flow tables are rearranged withā€
+       out semantic change.
+
+STATEFUL ACTIONS
+       Some  OVN  logical actions use or update state that is not available in
+       the southbound database. ovn-trace handles these actions  as  described
+       below:
+
+              ct_next
+                     By  default  ovn-trace  treats  flows  as ``trackedā€™ā€™ and
+                     ``established.ā€™ā€™ See the description of the  --ct  option
+                     for a way to override this behavior.
+
+              ct_dnat (without an argument)
+                     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
+                     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
+                     gateway router, ct_snat; is treated as a no-op. On a disā€
+                     tributed router, it is treated the same way as ct_dnat;.
+
+              ct_dnat(ip)
+              ct_snat(ip)
+                   Forks the pipeline. In one fork, sets ip4.dst (or  ip4.src)
+                   to  ip  and  ct.dnat  (or ct.snat) to 1 and advances to the
+                   next table as if next; were executed. In  the  other  fork,
+                   the pipeline continues without change after the ct_dnat (or
+                   ct_snat) action.
+
+              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
+                   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 acā€
+                   tion.
+
+              ct_commit
+              put_arp
+              put_nd
+                   These actions are treated as no-ops.
+
+DAEMON MODE
+       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.
+
+              trace [options] [datapath] microflow
+                     Traces microflow through datapath and  replies  with  the
+                     results of the trace. Accepts the options described under
+                     Trace Options below.
+
+              exit   Causes ovn-trace to gracefully terminate.
+
+OPTIONS
+   Trace Options
+       --detailed
+       --summary
+       --minimal
+            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
+            output.
+
+       --all
+            Selects all three forms of output.
+
+       --ovs[=remote]
+            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-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  orā€
+                   dinarily matches only one of these.
+
+            ā€¢      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
+                   that hypervisor.
+
+            ā€¢      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ā€
+                   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
+            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
+                   place. (This bit is set automatically even if not listed in
+                   flags.
+
+            ā€¢      new: Include to indicate a new flow.
+
+            ā€¢      est: Include to indicate an established flow.
+
+            ā€¢      rel: Include to indicate a related flow.
+
+            ā€¢      rpl: Include to indicate a reply flow.
+
+            ā€¢      inv: Include to indicate a connection entry in a bad state.
+
+            ā€¢      dnat: Include to indicate a packet whose destination IP adā€
+                   dress has been changed.
+
+            ā€¢      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
+                   firewall that has not yet been committed (with ct_commit).
+
+            ā€¢      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
+                   an established flow.
+
+            ā€¢      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 opā€
+            tions to specify the flags for multiple ct_next actions.
+
+            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.
+            --lb-dst is not available in daemon mode.
+
+       --select-id=id
+            Specify the id to be selected by the select action. id must be one
+            of the values listed in the select action. Otherwise, a random  id
+            is  selected  from the list, as if --select-id were not specified.
+            --select-id is not available in daemon mode.
+
+       --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
+            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,
+            if a program is going to parse ovn-trace output.
+
+   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
+              specified, or if it does not begin with /, then it is created in
+              .
+
+              If --pidfile is not specified, no pidfile is created.
+
+       --overwrite-pidfile
+              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.
+
+              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
+              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
+              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ā€ā€
+              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ā€
+              tions without it.
+
+       --no-chdir
+              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.
+
+              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-
+              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.
+
+       --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
+              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
+              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
+              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
+            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
+                   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,  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
+                   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
+                   definition of each log level.
+
+            Case is not significant within spec.
+
+            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
+            word but has no effect.
+
+       -v
+       --verbose
+            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-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,
+            local4, local5, local6 or local7. If this option is not specified,
+            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
+            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.
+
+       --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ā€
+            name.
+
+       --syslog-method=method
+            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
+                   /dev/log UNIX domain socket.
+
+            ā€¢      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 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  to  use SSL for the connection to the
+       database (and the switch, if --ovs is specified).
+
+              -p privkey.pem
+              --private-key=privkey.pem
+                   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ā€
+                   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
+                   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
+                   verify the certificate specified on -c or --certificate, or
+                   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
+                   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ā€
+              wise, the default is unix:/db.sock, but this default is unlikely
+              to be useful outside of single-machine OVN test environments.
+
+              -h
+              --help
+                   Prints a brief help message to the console.
+
+              -V
+              --version
+                   Prints version information to the console.
+
+OVN 23.06.3                        ovn-trace                      ovn-trace(8)
+
diff --git a/src/static/support/dist-docs-branch-23.06/ovn-trace.8.pdf b/src/static/support/dist-docs-branch-23.06/ovn-trace.8.pdf new file mode 100644 index 00000000..f95854ff Binary files /dev/null and b/src/static/support/dist-docs-branch-23.06/ovn-trace.8.pdf differ diff --git a/src/static/support/dist-docs-branch-23.06/ovn-trace.8.txt b/src/static/support/dist-docs-branch-23.06/ovn-trace.8.txt new file mode 100644 index 00000000..d18a27d4 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/ovn-trace.8.txt @@ -0,0 +1,570 @@ +ovn-trace(8) OVN Manual ovn-trace(8) + +NAME + ovn-trace - Open Virtual Network logical network tracing utility + +SYNOPSIS + ovn-trace [options] [datapath] microflow + + ovn-trace [options] --detach + +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 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 + 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ā€ + 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 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 + 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 + inport that the microflow matches.) + + The microflow argument describes the packet whose forwarding is to be + simulated, in the syntax of an OVN logical expression, as described in + ovn-sb(5), to express constraints. The parser understands prerequiā€ + 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 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 + + + For reasonable L3 behavior, microflow should also include ip4.src and + ip4.dst (or ip6.src and ip6.dst) and ip.ttl. For example: + + inport == "lp111" && eth.src == f0:00:00:00:01:11 && eth.dst == 00:00:00:00:ff:11 + && ip4.src == 192.168.11.1 && ip4.dst == 192.168.22.2 && ip.ttl == 64 + + + Hereā€™s an ARP microflow example: + + inport == "lp123" + && eth.dst == ff:ff:ff:ff:ff:ff && eth.src == f0:00:00:00:01:11 + && arp.op == 1 && arp.sha == f0:00:00:00:01:11 && arp.spa == 192.168.1.11 + && arp.tha == ff:ff:ff:ff:ff:ff && arp.tpa == 192.168.2.22 + + + ovn-trace will reject erroneous microflow expressions, which beyond + syntax errors fall into two categories. First, they can be ambiguous. + For example, tcp.src == 80 is ambiguous because it does not state IPv4 + or IPv6 as the Ethernet type. ip4 && tcp.src > 1024 is also ambiguous + because it does not constrain bits of tcp.src to particular values. + Second, they can be contradictory, e.g. ip4 && ip6. + +OUTPUT + ovn-trace supports the three different forms of output, each described + in a separate section below. Regardless of the selected output format, + ovn-trace starts the output with a line that shows the microflow being + traced in OpenFlow syntax. + + Detailed Output + The detailed form of output is also the default form. This form groups + output into sections headed up by the ingress or egress pipeline being + traversed. Each pipeline lists each table that was visited (by number + and name), the ovn-northd source file and line number of the code that + added the flow, the match expression and priority of the logical flow + that was matched, and the actions that were executed. + + The execution of OVN logical actions naturally forms a ``control + stackā€™ā€™ that resembles that of a program in conventional programming + languages such as C or Java. Because the next action that calls into + another logical flow table for a lookup is a recursive construct, OVN + ``programsā€™ā€™ in practice tend to form deep control stacks that, disā€ + played in the obvious way using additional indentation for each level, + quickly use up the horizontal space on all but the widest displays. To + make detailed output more readable, without loss of generality, + ovn-trace omits indentation for ``tail recursion,ā€™ā€™ that is, when next + is the last action in a logical flow, it does not indent details of the + next table lookup more deeply. Output still uses indentation when it is + needed for clarity. + + OVN ``programsā€™ā€™ traces also tend to encounter long strings of logical + flows with match expression 1 (which matches every packet) and the sinā€ + gle action next;. These are uninteresting and merely clutter output, so + ovn-trace omits them entirely even from detailed output. + + The following excerpt from detailed ovn-trace output shows a section + for a packet traversing the ingress pipeline of logical datapath ls1 + 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 + based on its Ethernet destination address and the flowā€™s actions output + the packet to the lrp11-attachement logical port. + + ingress(dp="ls1", inport="lp111") + --------------------------------- + 0. ls_in_port_sec_l2: inport == "lp111", priority 50 + next(1); + 19. ls_in_l2_lkup: eth.dst == 00:00:00:00:ff:11, priority 50 + outport = "lrp11-attachment"; + output; + + + Summary Output + Summary output includes the logical pipelines visited by a packet and + the logical actions executed on it. Compared to the detailed output, + however, it removes details of tables and logical flows traversed by a + packet. It uses a format closer to that of a programming language and + does not attempt to avoid indentation. The summary output equivalent to + the above detailed output fragment is: + + ingress(dp="ls1", inport="lp111") { + outport = "lrp11-attachment"; + output; + ... + }; + + + Minimal 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.) + + The minimal output format reflects the externally seen behavior of the + logical networks more than it does the implementation. This makes this + output format the most suitable for use in regression tests, because it + is least likely to change when logical flow tables are rearranged withā€ + out semantic change. + +STATEFUL ACTIONS + Some OVN logical actions use or update state that is not available in + the southbound database. ovn-trace handles these actions as described + below: + + ct_next + By default ovn-trace treats flows as ``trackedā€™ā€™ and + ``established.ā€™ā€™ See the description of the --ct option + for a way to override this behavior. + + ct_dnat (without an argument) + 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 + 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 + gateway router, ct_snat; is treated as a no-op. On a disā€ + tributed router, it is treated the same way as ct_dnat;. + + ct_dnat(ip) + ct_snat(ip) + Forks the pipeline. In one fork, sets ip4.dst (or ip4.src) + to ip and ct.dnat (or ct.snat) to 1 and advances to the + next table as if next; were executed. In the other fork, + the pipeline continues without change after the ct_dnat (or + ct_snat) action. + + 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 + 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 acā€ + tion. + + ct_commit + put_arp + put_nd + These actions are treated as no-ops. + +DAEMON MODE + 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. + + trace [options] [datapath] microflow + Traces microflow through datapath and replies with the + results of the trace. Accepts the options described under + Trace Options below. + + exit Causes ovn-trace to gracefully terminate. + +OPTIONS + Trace Options + --detailed + --summary + --minimal + 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 + output. + + --all + Selects all three forms of output. + + --ovs[=remote] + 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-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 orā€ + dinarily matches only one of these. + + ā€¢ 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 + that hypervisor. + + ā€¢ 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ā€ + 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 + 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 + place. (This bit is set automatically even if not listed in + flags. + + ā€¢ new: Include to indicate a new flow. + + ā€¢ est: Include to indicate an established flow. + + ā€¢ rel: Include to indicate a related flow. + + ā€¢ rpl: Include to indicate a reply flow. + + ā€¢ inv: Include to indicate a connection entry in a bad state. + + ā€¢ dnat: Include to indicate a packet whose destination IP adā€ + dress has been changed. + + ā€¢ 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 + firewall that has not yet been committed (with ct_commit). + + ā€¢ 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 + an established flow. + + ā€¢ 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 opā€ + tions to specify the flags for multiple ct_next actions. + + 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. + --lb-dst is not available in daemon mode. + + --select-id=id + Specify the id to be selected by the select action. id must be one + of the values listed in the select action. Otherwise, a random id + is selected from the list, as if --select-id were not specified. + --select-id is not available in daemon mode. + + --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 + 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, + if a program is going to parse ovn-trace output. + + 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 + specified, or if it does not begin with /, then it is created in + . + + If --pidfile is not specified, no pidfile is created. + + --overwrite-pidfile + 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. + + 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 + 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 + 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ā€ā€ + 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ā€ + tions without it. + + --no-chdir + 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. + + 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- + 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. + + --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 + 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 + 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 + 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 + 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 + 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, 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 + 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 + definition of each log level. + + Case is not significant within spec. + + 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 + word but has no effect. + + -v + --verbose + 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-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, + local4, local5, local6 or local7. If this option is not specified, + 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 + 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. + + --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ā€ + name. + + --syslog-method=method + 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 + /dev/log UNIX domain socket. + + ā€¢ 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 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 to use SSL for the connection to the + database (and the switch, if --ovs is specified). + + -p privkey.pem + --private-key=privkey.pem + 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ā€ + 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 + 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 + verify the certificate specified on -c or --certificate, or + 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 + 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ā€ + wise, the default is unix:/db.sock, but this default is unlikely + to be useful outside of single-machine OVN test environments. + + -h + --help + Prints a brief help message to the console. + + -V + --version + Prints version information to the console. + +OVN 23.06.3 ovn-trace ovn-trace(8) diff --git a/src/static/support/dist-docs-branch-23.06/style.css b/src/static/support/dist-docs-branch-23.06/style.css new file mode 100644 index 00000000..8a065186 --- /dev/null +++ b/src/static/support/dist-docs-branch-23.06/style.css @@ -0,0 +1,25 @@ +div { vertical-align:top; } +p { + vertical-align:baseline; +} +a { + text-decoration: none; + font-weight: 700; +} +a:hover { + color:#444; +} +a:visited { + color:#447099; +} +a:link { + color:#447099; +} + +body { + font-family: Arial,Helvetica,sans-serif; + font-size: 14px; + line-height: 1.5em; + color: #444; + background-color:#f5f5f5; +}