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

       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

       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 three classes of data with differ‐
       ent properties, as described in the sections below.

     Physical Network (PN) data

       PN 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 PN data is small (O(n) in the number of chassis)  and  it
       changes infrequently, so it can be replicated to every chassis.

       The Chassis table comprises the PN tables.

     Logical Network (LN) data

       LN  tables  contain the topology of logical switches and routers, ACLs,
       firewall rules, and everything needed to describe how packets  traverse
       a  logical  network, represented as logical datapath flows (see Logical
       Datapath Flows, below).

       LN 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  participates.   Past
       experience  shows  that in the presence of large logical networks, even
       finer-grained partitioning of data, e.g.  designing  logical  flows  so
       that  only the chassis hosting a logical port needs related flows, pays
       off scale-wise.  (This is not necessary initially but it is worth bear‐
       ing in mind in the design.)

       The  LN is a slave of the cloud management system running northbound of
       OVN.  That CMS determines the  entire  OVN  logical  configuration  and
       therefore  the  LN’s content at any given time is a deterministic func‐
       tion of the CMS’s configuration, although that happens  indirectly  via
       the OVN_Northbound database and ovn-northd.

       LN  data  is likely to change more quickly than PN data.  This is espe‐
       cially true in a  container  environment  where  VMs  are  created  and
       destroyed  (and  therefore  added to and deleted from logical switches)

       Logical_Flow and Multicast_Group contain LN data.

     Bindings data

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

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

   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‐

       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
       Chassis   Physical Network Hypervisor and Gateway Information
       Encap     Encapsulation Types
                 Logical Network Flows
                 Logical Port Multicast Groups
                 Physical-Logical Datapath Bindings
                 Physical-Logical Port Bindings

Chassis TABLE
       Each row in this table represents a hypervisor or gateway  (a  chassis)
       in   the   physical   network   (PN).    Each   chassis,  via  ovn-con
       troller/ovn-controller-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.

       name                          string (must be unique within table)
       Encapsulation Configuration:
         encaps                      set of 1 or more Encaps
       Gateway Configuration:
         vtep_logical_switches       set of strings

       name: string (must be unique within table)
              A  chassis  name,  taken  from  external_ids:system-id  in   the
              Open_vSwitch  database’s  Open_vSwitch table.  OVN does not pre‐
              scribe a particular format for chassis names.

     Encapsulation Configuration:
       OVN uses encapsulation to transmit logical  dataplane  packets  between

       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

       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.

       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.

       type                          string, one of stt, geneve, or vxlan
       options                       map of string-string pairs
       ip                            string

       type: string, one of stt, geneve, 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, e.g. IPsec parameters
              when IPsec support is  introduced.   No  options  are  currently

       ip: string
              The IPv4 address of the encapsulation tunnel endpoint.

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, 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 specified.  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  com‐
       pletes, 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.  In the common case, where they are  dif‐
       ferent,  the packet enters the egress pipeline.  This transition to the
       egress pipeline discards register data, e.g. reg0 ...  reg4 and connec‐
       tion  tracking state, to achieve uniform behavior regardless of whether
       the egress pipeline is on a  different  hypervisor  (because  registers
       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, 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

       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 is responsible for populating the Logical_Flow table, so the
       stages are an implementation detail and subject to change.   This  sec‐
       tion describes the current logical flow table.

       The ingress pipeline consists of the following stages:

              ·      Port  Security  (Table  0): Validates the source address,
                     drops packets with a VLAN tag, and, if configured,  veri‐
                     fies  that  the  logical port is allowed to send with the
                     source address.

              ·      L2 Destination Lookup (Table 1): Forwards  known  unicast
                     addresses to the appropriate logical port.  Unicast pack‐
                     ets to unknown hosts are forwarded to logical ports  con‐
                     figured with the special unknown mac address.  Broadcast,
                     and multicast are flooded to all  ports  in  the  logical

       The egress pipeline consists of the following stages:

              ·      ACL  (Table  0):  Applies  any  specified  access control

              ·      Port Security (Table 1): If configured, verifies that the
                     logical  port is allowed to receive packets with the des‐
                     tination address.

       logical_datapath              Datapath_Binding
       pipeline                      string, either ingress or egress
       table_id                      integer, in range 0 to 15
       priority                      integer, in range 0 to 65,535
       match                         string
       actions                       string
       external_ids : stage-name     optional string
       Common Columns:
         external_ids                map of string-string pairs

       logical_datapath: Datapath_Binding
              The logical datapath to which the logical flow belongs.

       pipeline: string, either ingress or egress
              The primary flows used for deciding on  a  packet’s  destination
              are  the  ingress  flows.  The egress flows implement ACLs.  See
              Logical Life Cycle of a Packet, above, for details.

       table_id: integer, in range 0 to 15
              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  ==
    , 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.


              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 conve‐
                     nience, 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 nominal 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  use‐
                     fully  compared  except  for  equality.   This is true of
                     OpenFlow port numbers, Ethernet types, and  IP  protocols
                     are  examples: all of these are just identifiers assigned
                     arbitrarily with no deeper meaning.  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‐

                     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‐

                     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
              example, 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

              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.


              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 != { con
              stant1, constant2, ... }’’ is equivalent to ``field != constant1
              &&&& field != constant2 &&&& ...’’.


              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

              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 */.
              Multiline comments are not supported.


              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.
              outport  may name a logical port, as inport, or a logical multi‐
              cast group defined in the Multicast_Group table.  For both  sym‐
              bols, only names within the flow’s logical datapath may be used.

              ·      reg0...reg4

              ·      inport outport

              ·      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_state, which has the following Boolean subfields:

                     ·      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

                     ct_state and its subfields are initialized by the ct_next
                     action, described below.

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

              ·      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  com‐
              ments),  or a set of actions that consists of just drop;, causes
              the matched packets to be dropped.  Otherwise, the column should
              contain a sequence of actions, each terminated by a semicolon.

              The following actions are defined:

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

                     Output  to the input port is implicitly dropped, that is,
                     output becomes a no-op if outport ==  inport.   Occasion‐
                     ally  it may be useful to override this behavior, e.g. to
                     send an ARP reply to an ARP request; to do so, use inport
                     =  "";  to  set the logical input port to an empty string
                     (which should not be used as  the  name  of  any  logical

                   Executes  another  logical  datapath table as a subroutine.
                   By default, the table after the current  one  is  executed.
                   Specify table to jump to a specific table in the same pipe‐

              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 sigifi‐
                   cant 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.

              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,
                   specify  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

                   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,

                   Prerequisite: ip

                   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 con‐
                   nection tracking state is scoped by the  logical  port,  so
                   overlapping  addresses  may  be  used.   To  allow  traffic
                   related to the matched flow, execute ct_commit.

                   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.

                   Commit the flow to the connection tracking entry associated
                   with it by a previous call to ct_next.

              The following actions will likely be useful later, but they have
              not been thought out carefully.

              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 initial‐
                     ized based on the IPv4 packet being  processed,  as  fol‐
                     lows.   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

                     Prerequisite: ip4

              icmp4 { action; ... };
                     Temporarily replaces the IPv4 packet being  processed  by
                     an  ICMPv4  packet and executes each nested action on the
                     ICMPv4 packet.  Actions following the  icmp4  action,  if
                     any, apply to the original, unmodified packet.

                     The  ICMPv4  packet  that this action operates on is ini‐
                     tialized based on the IPv4  packet  being  processed,  as
                     follows.   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)

                     ·      icmp4.type = 3 (destination unreachable)

                     ·      icmp4.code = 1 (host unreachable)

                     Details TBD.

                     Prerequisite: ip4

                     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.

                     Details TBD.

                     Prerequisite: tcp

       external_ids : stage-name: optional string
              Human-readable name for this flow’s stage in 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

Multicast_Group TABLE
       The rows in this table define multicast groups of logical ports.   Mul‐
       ticast  groups  allow  a  single  packet transmitted over a tunnel to a
       hypervisor to be delivered to multiple VMs on  that  hypervisor,  which
       uses bandwidth more efficiently.

       Each  row in this table defines a logical multicast group numbered tun
       nel_key within datapath, whose logical ports are listed  in  the  ports

       datapath                      Datapath_Binding
       tunnel_key                    integer, in range 32,768 to 65,535
       name                          string
       ports                         set  of  1  or  more  weak  reference  to

       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 1 or more 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).
Datapath_Binding TABLE
       Each row in this table identifies physical bindings of a logical  data‐
       path.  A logical datapath implements a logical pipeline among the ports
       in the Port_Binding table associated with it.  In practice,  the  pipe‐
       line  in a given logical datapath implements either a logical switch or
       a logical router.

       tunnel_key                    integer, in range 1 to  16,777,215  (must
                                     be unique within table)
       OVN_Northbound Relationship:
         external_ids : logical-switch
                                     optional string, containing an uuid
         external_ids : logical-router
                                     optional string, containing an uuid
       Common Columns:
         external_ids                map of string-string pairs

       tunnel_key:  integer,  in  range 1 to 16,777,215 (must be unique within
              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

     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.

     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
       Most rows in this table identify the physical  location  of  a  logical
       port.   (The  exceptions are logical patch ports, which do not have any
       physical location.)

       For every Logical_Port record in  OVN_Northbound  database,  ovn-northd
       creates  a  record  in  this table.  ovn-northd populates and maintains
       every column except the chassis column, which it leaves  empty  in  new

       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

       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.

       Core Features:
         datapath                    Datapath_Binding
         logical_port                string (must be unique within table)
         chassis                     optional weak reference to Chassis
         tunnel_key                  integer, in range 1 to 32,767
         mac                         set of strings
         type                        string
       Patch Options:
         options : peer              optional string
       Localnet Options:
         options : network_name      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
       Nested Containers:
         parent_port                 optional string
         tag                         optional integer, in range 1 to 4,095

     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, taken from name in the OVN_Northbound database’s
              Logical_Port  table.  OVN does not prescribe a particular format
              for the logical port ID.

       chassis: optional weak reference to Chassis
              The physical location of  the  logical  port.   To  successfully
              identify  a chassis, this column must be a Chassis record.  This
              is populated by ovn-controller/ovn-controller-vtep.

       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‐

       mac: set of strings
              The Ethernet address or addresses used as a  source  address  on
              the  logical  port,  each  in  the  form xx:xx:xx:xx:xx:xx.  The
              string unknown is also allowed to indicate that the logical port
              has an unknown set of (additional) source addresses.

              A  VM interface would ordinarily have a single Ethernet address.
              A gateway port might initially only have unknown, and  then  add
              MAC addresses to the set as it learns new source addresses.

       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 following 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
                     datapaths,  e.g. to connect a logical router to a logical
                     switch or to another logical router.

                     A connection to a locally accessible  network  from  each
                     ovn-controller  instance.  A logical switch can only have
                     a single localnet port attached and at most  one  regular
                     logical  port.  This is used to model direct connectivity
                     to an existing network.

              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.

     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.

     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:

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

       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

     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.

     Nested Containers:
       These columns support containers nested  within  a  VM.   Specifically,
       they are used when type is empty and logical_port identifies the inter‐
       face 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_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).

Open vSwitch 2.5.1              DB Schema 1.0.0                      ovn-sb(5)