'\" p
.\" -*- nroff -*-
.TH "ovn-sb" 5 " DB Schema 1.8.0" "Open vSwitch 2.6.2" "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
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
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
The OVN Southbound database contains classes of data with
different properties, as described in the sections below\[char46]
.ST "Physical Network (PN) data"
.PP
PN 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
The amount of PN data is small (O(n) in the number of chassis) and it
changes infrequently, so it can be replicated to every chassis\[char46]
.PP
The \fBChassis\fR table comprises the PN tables\[char46]
.ST "Logical Network (LN) data"
.PP
LN 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
LN 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]  Past
experience shows that in the presence of large logical networks, even
finer-grained partitioning of data, e\[char46]g\[char46] designing logical flows so that
only the chassis hosting a logical port needs related flows, pays off
scale-wise\[char46]  (This is not necessary initially but it is worth bearing in
mind in the design\[char46])
.PP
The LN is a slave of the cloud management system running northbound of OVN\[char46]
That CMS determines the entire OVN logical configuration and therefore the
LN\(cqs content 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
LN data is likely to change more quickly than PN data\[char46]  This is especially
true in a container environment where VMs are created and destroyed (and
therefore added to and deleted from logical switches) quickly\[char46]
.PP
\fBLogical_Flow\fR and \fBMulticast_Group\fR contain LN
data\[char46]
.ST "Logical-physical bindings"
.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
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
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
The \fBPort_Binding\fR and \fBDatapath_Binding\fR tables
contain binding data\[char46]
.ST "MAC bindings"
.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
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
\fBEncap\fR
Encapsulation Types
.TQ 1in
\fBAddress_Set\fR
Address Sets
.TQ 1in
\fBLogical_Flow\fR
Logical Network Flows
.TQ 1in
\fBMulticast_Group\fR
Logical Port Multicast Groups
.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
.\" 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.5;
box at 0.5725847715,0.1451625 wid 0.85483293 height 0.290325 "Address_Set"
box at 0.5725847715,0.1451625 wid 0.799277374444444 height 0.234769444444444
linethick = 0.5;
box at 4.61291586,0.951627285 wid 1.17744207 height 0.290325 "Datapath_Binding"
box at 4.61291586,0.951627285 wid 1.12188651444444 height 0.234769444444444
linethick = 0.5;
box at 0.5725847715,1.0161375 wid 0.717741465 height 0.290325 "SB_Global"
box at 0.5725847715,1.0161375 wid 0.662185909444444 height 0.234769444444444
linethick = 0.5;
box at 2.30645793,1.1613 wid 0.895188105 height 0.290325 "Logical_Flow"
box at 2.30645793,1.1613 wid 0.839632549444444 height 0.234769444444444
linethick = 0.5;
box at 0.5725847715,0.58065 wid 1.10486082 height 0.290325 "Multicast_Group"
box at 0.5725847715,0.58065 wid 1.04930526444444 height 0.234769444444444
linethick = 0.5;
box at 2.30645793,0.3145206855 wid 0.88711707 height 0.290325 "Port_Binding"
box at 2.30645793,0.3145206855 wid 0.831561514444444 height 0.234769444444444
linethick = 0.5;
box at 4.61291586,0.201613293 wid 0.58065 height 0.290325 "Chassis"
box at 4.61291586,0.201613293 wid 0.525094444444444 height 0.234769444444444
linethick = 1;
box at 6.2501166,0.201613293 wid 0.5000035215 height 0.290325 "Encap"
linethick = 0.5;
box at 2.30645793,1.5967875 wid 0.935485215 height 0.290325 "MAC_Binding"
box at 2.30645793,1.5967875 wid 0.879929659444444 height 0.234769444444444
linethick = 0.5;
box at 0.5725847715,1.451625 wid 1.14515793 height 0.290325 "DHCPv6_Options"
box at 0.5725847715,1.451625 wid 1.08960237444444 height 0.234769444444444
linethick = 0.5;
box at 0.5725847715,1.8871125 wid 1.008066465 height 0.290325 "DHCP_Options"
box at 0.5725847715,1.8871125 wid 0.952510909444444 height 0.234769444444444
linethick = 1;
spline -> from 2.75611329,1.12088676 to 2.75611329,1.12088676 to 3.116871135,1.087847775 to 3.62964315,1.040931255 to 4.02367224,1.004814825
"logical_datapath" at 3.39924123,1.165306485
linethick = 1;
spline -> from 1.125473895,0.630876225 to 1.125473895,0.630876225 to 1.88235117,0.700670355 to 3.24629802,0.82638108 to 4.02262707,0.89791716
"datapath" at 2.30645793,0.834684375
linethick = 0.5;
spline -> from 1.126519065,0.4960783275 to 1.126519065,0.4960783275 to 1.364237175,0.459247698 to 1.63905882,0.4166686335 to 1.862783265,0.382009635
"ports+" at 1.49192211,0.5201636895
linethick = 1;
spline -> from 2.75042292,0.322945917 to 2.75042292,0.322945917 to 3.070535265,0.3404641275 to 3.511713135,0.3885419475 to 3.87909039,0.5161339785 to 4.073433945,0.583611315 to 4.272248505,0.707522025 to 4.41259161,0.806000265
"datapath" at 3.39924123,0.576620289
linethick = 0.5;
spline -> from 2.75274552,0.229716753 to 2.75274552,0.229716753 to 2.808662115,0.221506362 to 2.865217425,0.214468884 to 2.91939207,0.2096785215 to 3.41050584,0.1662459015 to 3.98534934,0.176494374 to 4.320906975,0.188571894
"chassis?" at 3.39924123,0.270164832
linethick = 1;
spline -> from 4.90335699,0.201613293 to 4.90335699,0.201613293 to 5.213598285,0.201613293 to 5.7066282,0.201613293 to 5.99985645,0.201613293
"encaps+" at 5.60083377,0.2620996035
linethick = 1;
spline -> from 2.775681195,1.520315895 to 2.775681195,1.520315895 to 3.09045156,1.462483155 to 3.514732515,1.373295315 to 3.87909039,1.258094355 to 4.018620585,1.21390689 to 4.168312155,1.1531709 to 4.29530031,1.097370435
"datapath" at 3.39924123,1.544354805
.ps +3
.PE
.RE\}
.bp
.SH "SB_Global TABLE"
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
.RE
.SS "Details:
.ST "Status:"
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:"
.IP "\fBexternal_ids\fR: map of string-string pairs"
See \fBExternal IDs\fR at the beginning of this document\[char46]
.bp
.SH "Chassis TABLE"
Each row in this table represents a hypervisor or gateway (a chassis) in
the physical network (PN)\[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
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
\fBexternal_ids : ovn-bridge-mappings\fR
optional string
.TQ 3.00in
\fBexternal_ids : datapath-type\fR
optional string
.TQ 3.00in
\fBexternal_ids : iface-types\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"
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 "\fBexternal_ids : 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 "\fBexternal_ids : 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 "\fBexternal_ids : 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]
.ST "Common Columns:"
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:"
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:"
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 "Encap TABLE"
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 \fBstt\fR, \fBgeneve\fR, or \fBvxlan\fR
.TQ 3.00in
\fBoptions\fR
map of string-string pairs
.TQ 3.00in
\fBip\fR
string
.SS "Details:
.IP "\fBtype\fR: string, one of \fBstt\fR, \fBgeneve\fR, or \fBvxlan\fR"
The encapsulation to use to transmit packets to this chassis\[char46]
Hypervisors must use either \fBgeneve\fR or
\fBstt\fR\[char46]  Gateways may use \fBvxlan\fR,
\fBgeneve\fR, or \fBstt\fR\[char46]
.IP "\fBoptions\fR: map of string-string pairs"
Options for configuring the encapsulation\[char46] Currently, the only
option that has been defined is \fBcsum\fR\[char46]
.IP
\fBcsum\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]
.IP
In terms of performance, this 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 "\fBip\fR: string"
The IPv4 address of the encapsulation tunnel endpoint\[char46]
.bp
.SH "Address_Set TABLE"
See the documentation for the \fBAddress_Set\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 "Logical_Flow TABLE"
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
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
The default action when no flow matches is to drop packets\[char46]
.PP
\fBArchitectural Logical Life Cycle of a Packet\fR
.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
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
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
In more detail, to start, OVN searches the \fBLogical_Flow\fR
table for a row with correct \fBlogical_datapath\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
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
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
To execute the egress pipeline, OVN again searches the \fBLogical_Flow\fR table for a row with correct \fBlogical_datapath\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
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
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
\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
\fBDatapath_Binding\fR
.TQ 3.00in
\fBpipeline\fR
string, either \fBingress\fR or \fBegress\fR
.TQ 3.00in
\fBtable_id\fR
integer, in range 0 to 15
.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
\fBexternal_ids : stage-name\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: \fBDatapath_Binding\fR"
The logical datapath to which the logical flow belongs\[char46]
.IP "\fBpipeline\fR: string, either \fBingress\fR or \fBegress\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 15"
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
\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 nominal 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
\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-signficant\[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
\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
\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 the following Boolean subfields:
.RS
.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
\fBct_state\fR and its subfields are initialized by the
\fBct_next\fR action, described below\[char46]
.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]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
\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
\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
Executes another logical datapath table as a subroutine\[char46]  By default,
the table after the current one is executed\[char46]  Specify
\fItable\fR to jump to a specific table in the same pipeline\[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 sigificant 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\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
\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, so overlapping addresses may be used\[char46]
To allow traffic related to the matched flow, execute
\fBct_commit\fR\[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]
.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]  If
the packet needs to be sent to the next tables, then it should be
followed by a \fBnext;\fR action\[char46]  The next tables will not
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
\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
\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
\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 = 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
\fBct_lb;\fR
.TQ .5in
\fBct_lb(\fR\fIip\fR[\fB:\fR\fIport\fR]\[char46]\[char46]\[char46]\fB);\fR
With one or more 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 string\[char46]  If multiple comma-separated IP
addresses are specified, each is given equal weight for picking the
DNAT address\[char46]  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]
.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]
.RE
.IP
The following actions will likely be useful later, but they have not
been thought out carefully\[char46]
.RS
.TP
\fBicmp4 { \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 the \fIicmp4\fR action, if any,
apply to the original, unmodified packet\[char46]
.IP
The ICMPv4 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\[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
\fBicmp4\[char46]type = 3\fR (destination unreachable)
.IP \(bu
\fBicmp4\[char46]code = 1\fR (host unreachable)
.RE
.IP
Details TBD\[char46]
.IP
\fBPrerequisite:\fR \fBip4\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
.fi
.IP
Then, the action drops all TCP options and payload data, and
updates the TCP checksum\[char46]
.IP
Details TBD\[char46]
.IP
\fBPrerequisite:\fR \fBtcp\fR
.RE
.IP "\fBexternal_ids : stage-name\fR: optional string"
Human-readable name for this flow\(cqs stage in the pipeline\[char46]
.ST "Common Columns:"
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 "Multicast_Group TABLE"
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
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 1 or more 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 1 or more 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 "Datapath_Binding TABLE"
Each row in this table identifies physical bindings of a logical
datapath\[char46]  A logical datapath 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]
.SS "Summary:
.TQ 3.00in
\fBtunnel_key\fR
integer, in range 1 to 16,777,215 (must be unique within table)
.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 : 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:
.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]
.ST "OVN_Northbound Relationship:"
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 : name\fR: optional string"
\fBovn\-northd\fR copies this from the \fBLogical_Router\fR or \fBLogical_Switch\fR table in the \fBOVN_Northbound\fR database, when that column is nonempty\[char46]
.ST "Common Columns:"
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"
Most rows in this table identify the physical location of a logical port\[char46]
(The exceptions are logical patch ports, which do not have any physical
location\[char46])
.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 column,
which it leaves empty in new records\[char46]
.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]md\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
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
\fBchassis\fR
optional weak reference to \fBChassis\fR
.TQ 2.75in
\fBtunnel_key\fR
integer, in range 1 to 32,767
.TQ 2.75in
\fBmac\fR
set of strings
.TQ 2.75in
\fBtype\fR
string
.RE
.TQ .25in
\fIPatch Options:\fR
.RS .25in
.TQ 2.75in
\fBoptions : peer\fR
optional string
.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
\fBoptions : nat-addresses\fR
optional string
.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 : policing_rate\fR
optional string
.TQ 2.75in
\fBoptions : policing_burst\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
.SS "Details:
.ST "Core Features:"
.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, taken from \fBname\fR in the OVN_Northbound
database\(cqs \fBLogical_Switch_Port\fR
table\[char46]  OVN does not prescribe a particular format for the
logical port ID\[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
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 "\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"
The Ethernet address or addresses used as a source address on the
logical port, each in the form
\fIxx\fR:\fIxx\fR:\fIxx\fR:\fIxx\fR:\fIxx\fR:\fIxx\fR\[char46]
The string \fBunknown\fR is also allowed to indicate that the
logical port has an unknown set of (additional) source addresses\[char46]
.IP
A VM interface would ordinarily have a single Ethernet address\[char46]  A
gateway port might initially only have \fBunknown\fR, and then
add MAC addresses to the set as it learns new source addresses\[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 each
\fBovn\-controller\fR instance\[char46]  A logical switch can only
have a single \fBlocalnet\fR port attached\[char46]  This is used
to model direct connectivity to an existing network\[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]
.RE
.ST "Patch Options:"
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]
.ST "L3 Gateway Options:"
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 "\fBoptions : nat-addresses\fR: optional string"
MAC address of the \fBl3gateway\fR port followed by a list of
SNAT and DNAT IP addresses\[char46] This is used to send gratuitous ARPs for
SNAT and DNAT IP addresses via \fBlocalnet\fR and is valid for
only L3 gateway ports\[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]
.ST "Localnet Options:"
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
.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]
.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:"
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
.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:"
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:"
These options apply to logical ports with \fBtype\fR having
(empty string)
.IP "\fBoptions : policing_rate\fR: optional string"
If set, indicates the maximum rate for data sent from this interface,
in kbps\[char46] Data exceeding this rate is dropped\[char46]
.IP "\fBoptions : policing_burst\fR: optional string"
If set, indicates the maximum burst size for data sent from this
interface, in kb\[char46]
.ST "Nested Containers:"
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]
.bp
.SH "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)\[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
This table expresses a functional relationship: \fBMAC_Binding\fR(\fBlogical_port\fR, \fBip\fR) =
\fBmac\fR\[char46]
.PP
In outline, the lifetime of a logical router\(cqs MAC binding looks like
this:
.RS
.IP 1. .25in
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. .25in
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. .25in
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. .25in
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. .25in
The logical switch delivers the ARP reply to the logical router port\[char46]
.IP 6. .25in
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. .25in
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
\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 "\fBdatapath\fR: \fBDatapath_Binding\fR"
The logical datapath to which the logical port belongs\[char46]
.bp
.SH "DHCP_Options TABLE"
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 \fBstatic_routes\fR, \fBuint8\fR, \fBuint16\fR, \fBbool\fR, \fBipv4\fR, \fBstr\fR, or \fBuint32\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 \fBstatic_routes\fR, \fBuint8\fR, \fBuint16\fR, \fBbool\fR, \fBipv4\fR, \fBstr\fR, or \fBuint32\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]
.RE
.bp
.SH "DHCPv6_Options TABLE"
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 \fBmac\fR, \fBstr\fR, or \fBipv6\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 \fBmac\fR, \fBstr\fR, or \fBipv6\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