ovn-sb(5)                     Open vSwitch Manual                    ovn-sb(5)



NAME
       ovn-sb - OVN_Southbound database schema

       This  database  holds  logical and physical configuration and state for
       the Open Virtual  Network  (OVN)  system  to  support  virtual  network
       abstraction.  For  an  introduction  to  OVN,  please see ovn-architec
       ture(7).

       The 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
       describe 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
       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

SB_Global TABLE
       Southbound  configuration  for  an  OVN  system.  This  table must have
       exactly 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
       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
       interfaces.

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

     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
       remaining 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
              information.

       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
       accessed 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
              updates 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  must  use  either  geneve  or stt. Gateways may use
              vxlan, geneve, 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
              increases  throughput in most common cases when running on Linux
              based hosts without NICs supporting encapsulation hardware  off‐
              load (around 60% for bulk traffic). The reason is that generally
              all NICs are capable  of  offloading  transmitted  and  received
              TCP/UDP  checksums  (viewed  as ordinary data packets and not as
              tunnels). The benefit comes on the receive side where the  vali‐
              dated  outer  checksum  can  be used to additionally validate an
              inner checksum (such as TCP), which in turn  allows  aggregation
              of  packets  to  be  more efficiently handled by the rest of the
              stack.

              Not all devices see such a benefit. The most  notable  exception
              is  hardware  VTEPs.  These  devices  are designed to not buffer
              entire packets in their  switching  engines  and  are  therefore
              unable to efficiently compute or validate full packet checksums.
              In addition certain versions of the Linux kernel are not able to
              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
       instead  of  physical ports and physical datapaths. Translation between
       logical and physical flows helps to ensure  isolation  between  logical
       datapaths.  (The  logical flow abstraction also allows the OVN central‐
       ized components to do less work, since they do not have  to  separately
       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 pipe‐
       line, which may either drop the packet or deliver it  to  the  destina‐
       tion.  Between  the  two pipelines, outputs to logical multicast groups
       are expanded into logical ports, so that the egress pipeline only  pro‐
       cesses  a  single  logical output port at a time. Between the two pipe‐
       lines is also where, when necessary, OVN encapsulates  a  packet  in  a
       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,
       except that it, of  course,  searches  for  egress  flows.  The  output
       action,  however,  now  directly  outputs the packet to the output port
       (which is now fixed, because outport is  read-only  within  the  egress
       pipeline).

       The  description  earlier  assumed  that  outport referred to a logical
       port. If it instead designates a  logical  multicast  group,  then  the
       description  above still applies, with the addition of fan-out from the
       logical multicast group to each logical port in  the  group.  For  each
       member  of  the  group, OVN executes the logical pipeline as described,
       with the logical output port replaced by the group member.

       Pipeline Stages

       ovn-northd populates the Logical_Flow  table  with  the  logical  flows
       described in detail in ovn-northd(8).

   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
              belongs. 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
              itself 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
                     defined as an alias for  vlan.tci[0..11].  Subfields  are
                     provided  for syntactic convenience, because it is always
                     possible to instead refer to a  subset  of  bits  from  a
                     field directly.

                     Only ordinal fields (see Level of Measurement, below) may
                     have subfields. Subfields are always ordinal.

              ·      Predicates.  A  predicate  is  shorthand  for  a  Boolean
                     expression.  Predicates  may  be  used  much  like  1-bit
                     fields. For example, ip4  might  expand  to  eth.type  ==
                     0x800. Predicates are provided for syntactic convenience,
                     because it is always  possible  to  instead  specify  the
                     underlying expression directly.

                     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:
                     either one can be implemented as a test for 0 or 1.

                     Only  predicates (see above) have a Boolean level of mea‐
                     surement.

                     This isn’t a standard level of measurement.

              Prerequisites. Any symbol  can  have  prerequisites,  which  are
              additional condition implied by the use of the symbol. For exam‐
              ple, For example,  icmp4.type  symbol  might  have  prerequisite
              icmp4,  which  would  cause  an expression icmp4.type == 0 to be
              interpreted as icmp4.type == 0 &&&& icmp4,  which  would  in  turn
              expand to icmp4.type == 0 &&&& eth.type == 0x800 &&&& ip4.proto == 1
              (assuming icmp4 is a predicate defined as suggested under  Types
              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
              efficient 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
              integers, 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
              required.

              Operator  precedence  is as shown below, from highest to lowest.
              There are two exceptions where  parentheses  are  required  even
              though  the  table  would  suggest  that they are not: &&&& and ||
              require parentheses when used together, and ! requires parenthe‐
              ses  when applied to a relational expression. Thus, in (eth.type
              == 0x800 || eth.type == 0x86dd) &&&& ip.proto == 6 or !(arp.op  ==
              1), the parentheses are mandatory.

              ·      ()

              ·      ==   !=   =   >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

              ·      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

              ·      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 pipe‐
                     line, 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.
                   Actions  in  the  both  ingress and egress pipeline can use
                   next to jump across the  other  pipeline.  Actions  in  the
                   ingress  pipeline should use next to jump into the specific
                   table of egress pipeline only if it  is  certain  that  the
                   packets  are local and not tunnelled and wants to skip cer‐
                   tain stages in the packet processing.

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

              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-
                   addressed 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_clear;
                   Clears connection tracking state.

              clone { action; ... };
                   Makes a copy of the packet  being  processed  and  executes
                   each  action  on  the  copy.  Actions  following  the clone
                   action, if any, apply to the original,  unmodified  packet.
                   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 the
                   logical port key is P, P, stores 1 in the 1-bit subfield R,
                   else 0.

                   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
                   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_nd(outport, ip6.dst);

              put_nd(P, A, E);
                   Parameters: logical  port  string  field  P,  128-bit  IPv6
                   address field A, 48-bit Ethernet address field E.

                   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
                   option 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
                   options  by  those specified as parameters, and stores 1 in
                   R.

                   When this action is applied to a non-DHCPv6  packet  or  an
                   invalid  DHCPv6  request  packet  ,  it  leaves  the packet
                   unchanged and stores 0 in R.

                   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
                   action. It affects packets that egress a hypervisor through
                   a physical interface. For nonzero queue_number, it  config‐
                   ures  packet  queuing  to match the settings configured for
                   the  Port_Binding  with   options:qdisc_queue_id   matching
                   queue_number.  When queue_number is zero, it resets queuing
                   to the default strategy.

                   Example: set_queue(10);

              ct_lb;
              ct_lb(ip[:port]...);
                   With one or more arguments, ct_lb commits the packet to the
                   connection  tracking  table and DNATs the packet’s destina‐
                   tion IP address (and port) to the IP address  or  addresses
                   (and  optional  ports) specified in the string. If multiple
                   comma-separated IP addresses are specified, each  is  given
                   equal weight for picking the DNAT address. Processing auto‐
                   matically 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.

                   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.

              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
                   resolve  the  query using the contents of the DNS table. If
                   it is successful, it changes the packet into  a  DNS  reply
                   and  stores  1  in R. If the action is applied to a non-DNS
                   packet, an invalid DNS  request  packet,  or  a  valid  DNS
                   request  for which the DNS table does not supply an answer,
                   it leaves the packet unchanged and stores 0 in R.

                   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
                   option/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
                          Advertisement 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
                          option 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,
                     defaulting 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
                   replaces  it  with IPv4 or IPv6 TCP RST packet and executes
                   the inner actions. Otherwise it replaces it with an  ICMPv4
                   or ICMPv6 packet and executes the inner actions.

                   The  inner  actions  should  not attempt to swap eth source
                   with eth destination and IP source with IP  destination  as
                   this action implicitly does that.

              trigger_event;
                   This  action  is  used  to allow ovs-vswitchd to report CMS
                   related events writing them in Controller_Event  table.  It
                   is  possible  to associate a meter to a each event in order
                   to not overload pinctrl thread under heavy load; each meter
                   is identified though a defined naming convention. Supported
                   events:

                   ·      empty_lb_backends.  This  event  is  raised   if   a
                          received  packet is destined for a load balancer VIP
                          that has no  configured  backend  destinations.  For
                          this  event,  the  event info includes the load bal‐
                          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
                   received 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
                   optional weight, which is an integer within the range  1  ~
                   65535.  If weight is not specified, it defaults to 100. The
                   selection method is based on the  5-tuple  hash  of  packet
                   header.

                   Processing  automatically moves on to the next table, as if
                   next; were specified. The select action must be put as  the
                   last  action  of  the  logical flow when there are multiple
                   actions (actions put after select will not take effect).

                   Example: reg8[16..31] = select(1=20, 2=30, 3=50);

              handle_dhcpv6_reply;
                   This action is used to parse DHCPv6 replies from IPv6 Dele‐
                   gation  Router  and  managed  IPv6  Prefix delegation state
                   machine

              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.

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

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
       location, 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
       options: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
         chassis                     optional 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
         type                        string
       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 : iface-id-ver      optional string
         options : qos_max_rate      optional string
         options : qos_burst         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 supported  encapsulation  configurations  to  transmit
              logical dataplane packets to this chassis. Each entry is a Encap
              record that describes the configuration.

       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.

       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.

       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
                     options:vtep-logical-switch must also be defined.

              chassisredirect
                     A logical port that  represents  a  particular  instance,
                     bound  to a specific chassis, of an otherwise distributed
                     parent port (e.g. of type patch). A chassisredirect  port
                     should  never be used as an inport. When an ingress pipe‐
                     line sets the outport, it may set the value to a  logical
                     port  of type chassisredirect. This will cause the packet
                     to be directed to a specific chassis  to  carry  out  the
                     egress pipeline. At the beginning of the egress pipeline,
                     the outport will be reset to the value of the distributed
                     port.

              virtual
                     Represents  a  logical port with an virtual ip. This vir
                     tual ip can be configured on a  logical  port  (which  is
                     refered as virtual parent).

     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
              addresses, 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
              incoming 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.

       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_max_rate: optional string
              If  set,  indicates  the  maximum  rate  for data sent from this
              interface, in bit/s. The traffic will  be  shaped  according  to
              this limit.

       options : qos_burst: optional string
              If set, indicates the maximum burst size for data sent from this
              interface, in bits.

       options : qdisc_queue_id: optional string, containing  an  integer,  in
       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 table 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
                  deliver it only to ports that have no static IP-to-MAC bind‐
                  ings, but this could also be surprising behavior.)

              4.  A host or VM on hypervisor 2 (which might  be  the  same  as
                  hypervisor  1)  attached  to  the logical switch owns the IP
                  address in question. It composes an ARP reply  and  unicasts
                  it to the logical router port’s Ethernet address.

              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
                  directly to the bound Ethernet address.

   Summary:
       logical_port                  string
       ip                            string
       mac                           string
       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.

       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
                     domain name or a comma separated list of domain names.

                     Example.      "name=domain_search_list",      "code=119",
                     "type=domains".

DHCPv6_Options TABLE
       Each row in this table stores the DHCPv6 Options  supported  by  native
       OVN  DHCPv6.  ovn-northd populates this table with the supported DHCPv6
       options. ovn-controller looks up this table to get the DHCPv6 codes  of
       the  DHCPv6 options defined in the put_dhcpv6_opts action. Please refer
       to RFC 3315 and RFC 3646 for the list of DHCPv6  options  that  can  be
       defined here.

   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
              appropriate 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
                     either be a DNS name (if built with unbound  library)  or
                     an IP address. A valid SSL configuration must be provided
                     when this form is used, this configuration can be  speci‐
                     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
                     either  be  a DNS name (if built with unbound library) or
                     an IP address (IPv4 or IPv6). If host is an IPv6 address,
                     wrap it in square brackets, e.g. tcp:[::1]:6640.

                     If port is not specified, it defaults to 6640.

              pssl:[port][:host]
                     Listens  for  SSL  connections on the specified TCP port.
                     Specify 0 for  port  to  have  the  kernel  automatically
                     choose  an available port. If host, which can either be a
                     DNS name  (if  built  with  unbound  library)  or  an  IP
                     address, is specified, then connections are restricted to
                     the resolved or specified local IP address  (either  IPv4
                     or  IPv6  address).  If  host is an IPv6 address, wrap in
                     square brackets, e.g. pssl:6640:[::1].  If  host  is  not
                     specified  then  it  listens  only on IPv4 (but not IPv6)
                     addresses. A valid SSL  configuration  must  be  provided
                     when  this form is used, this can be specified either via
                     command-line options or the SSL table.

                     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
                     resolved or specified local IP address  (either  IPv4  or
                     IPv6  address).  If  host  is an IPv6 address, wrap it in
                     square brackets, e.g. ptcp:6640:[::1].  If  host  is  not
                     specified then it listens only on IPv4 addresses.

                     If port is not specified, it defaults to 6640.

              When  multiple clients are configured, the target values must be
              unique. Duplicate target values yield unspecified results.

       read_only: boolean
              true to restrict these connections  to  read-only  transactions,
              false to allow them to modify the database.

       role: string
              String containing role name for this connection entry.

     Client Failure Detection and Handling:

       max_backoff: optional integer, at least 1,000
              Maximum  number  of  milliseconds  to  wait  between  connection
              attempts. Default is implementation-specific.

       inactivity_probe: optional integer
              Maximum number of milliseconds of idle time on connection to the
              client  before  sending  an  inactivity  probe  message. If Open
              vSwitch does not communicate with the client for  the  specified
              number  of  seconds,  it will send a probe. If a response is not
              received for the same additional amount of  time,  Open  vSwitch
              assumes  the  connection  has been broken and attempts to 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
              inbound 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
              immediately  drop the connection and reconnect, and from then on
              all SSL connections  must  be  authenticated  by  a  certificate
              signed  by the CA certificate thus obtained. This option exposes
              the SSL connection to a man-in-the-middle attack  obtaining  the
              initial  CA  certificate.  It may still be useful for bootstrap‐
              ping.

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

       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
              authorized 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
              determine  the  correct  Chassis,  find the chassisredirect type
              Port_Binding  that  references   this   HA_Chassis_Group.   This
              Port_Binding  is  derived  from  some particular logical router.
              Starting from that LR, find the set of all logical switches  and
              routers  connected  to it, directly or indirectly, across router
              ports that link one LRP to another or to a LSP. For each LSP  in
              these  logical switches, find the corresponding Port_Binding and
              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.
              Default: 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
       periodically 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
       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.

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



Open vSwitch 21.09.90          DB Schema 20.20.0                     ovn-sb(5)