1ovn-sb(5)                     Open vSwitch Manual                    ovn-sb(5)
2
3
4

NAME

6       ovn-sb - OVN_Southbound database schema
7
8       This  database  holds  logical and physical configuration and state for
9       the Open Virtual Network (OVN) system to support  virtual  network  ab‐
10       straction. For an introduction to OVN, please see ovn-architecture(7).
11
12       The OVN Southbound database sits at the center of the OVN architecture.
13       It is the one component that speaks both southbound directly to all the
14       hypervisors  and  gateways, via ovn-controller/ovn-controller-vtep, and
15       northbound to the Cloud Management System, via ovn-northd:
16
17   Database Structure
18       The OVN Southbound database contains classes  of  data  with  different
19       properties, as described in the sections below.
20
21     Physical network
22
23       Physical  network tables contain information about the chassis nodes in
24       the system. This contains all the information  necessary  to  wire  the
25       overlay,  such  as  IP  addresses, supported tunnel types, and security
26       keys.
27
28       The amount of physical network data is small (O(n)  in  the  number  of
29       chassis)  and it changes infrequently, so it can be replicated to every
30       chassis.
31
32       The Chassis and Encap tables are the physical network tables.
33
34     Logical Network
35
36       Logical network tables contain the topology  of  logical  switches  and
37       routers,  ACLs,  firewall  rules, and everything needed to describe how
38       packets traverse a logical network,  represented  as  logical  datapath
39       flows (see Logical Datapath Flows, below).
40
41       Logical network data may be large (O(n) in the number of logical ports,
42       ACL rules, etc.). Thus, to improve scaling, each chassis should receive
43       only  data  related  to logical networks in which that chassis partici‐
44       pates.
45
46       The logical network data is ultimately controlled by the cloud  manage‐
47       ment  system  (CMS)  running northbound of OVN. That CMS determines the
48       entire OVN logical configuration and therefore the logical network data
49       at  any  given time is a deterministic function of the CMS’s configura‐
50       tion, although that happens indirectly via the OVN_Northbound  database
51       and ovn-northd.
52
53       Logical  network  data  is  likely to change more quickly than physical
54       network data. This is especially true in a container environment  where
55       containers  are  created  and  destroyed  (and  therefore  added to and
56       deleted from logical switches) quickly.
57
58       The   Logical_Flow,   Multicast_Group,   Address_Group,   DHCP_Options,
59       DHCPv6_Options, and DNS tables contain logical network data.
60
61     Logical-physical bindings
62
63       These  tables  link logical and physical components. They show the cur‐
64       rent placement of logical components (such as VMs and VIFs) onto  chas‐
65       sis, and map logical entities to the values that represent them in tun‐
66       nel encapsulations.
67
68       These tables change frequently, at least every time a VM powers  up  or
69       down  or  migrates,  and especially quickly in a container environment.
70       The amount of data per VM (or VIF) is small.
71
72       Each chassis is authoritative about the VMs and VIFs that it  hosts  at
73       any  given time and can efficiently flood that state to a central loca‐
74       tion, so the consistency needs are minimal.
75
76       The Port_Binding and Datapath_Binding tables contain binding data.
77
78     MAC bindings
79
80       The MAC_Binding table tracks the bindings from IP addresses to Ethernet
81       addresses  that  are  dynamically  discovered  using ARP (for IPv4) and
82       neighbor discovery (for IPv6). Usually, IP-to-MAC bindings for  virtual
83       machines  are  statically  populated  into  the  Port_Binding table, so
84       MAC_Binding is primarily used to discover  bindings  on  physical  net‐
85       works.
86
87   Common Columns
88       Some  tables  contain  a special column named external_ids. This column
89       has the same form and purpose each place that it  appears,  so  we  de‐
90       scribe it here to save space later.
91
92              external_ids: map of string-string pairs
93                     Key-value  pairs for use by the software that manages the
94                     OVN  Southbound  database   rather   than   by   ovn-con‐
95                     troller/ovn-controller-vtep.  In  particular,  ovn-northd
96                     can use key-value pairs in this column to relate entities
97                     in the southbound database to higher-level entities (such
98                     as entities in the OVN Northbound  database).  Individual
99                     key-value  pairs in this column may be documented in some
100                     cases to aid in understanding  and  troubleshooting,  but
101                     the  reader should not mistake such documentation as com‐
102                     prehensive.
103

TABLE SUMMARY

105       The following list summarizes the purpose of each of the tables in  the
106       OVN_Southbound  database.   Each table is described in more detail on a
107       later page.
108
109       Table     Purpose
110       SB_Global Southbound configuration
111       Chassis   Physical Network Hypervisor and Gateway Information
112       Chassis_Private
113                 Chassis Private
114       Encap     Encapsulation Types
115       Address_Set
116                 Address Sets
117       Port_Group
118                 Port Groups
119       Logical_Flow
120                 Logical Network Flows
121       Logical_DP_Group
122                 Logical Datapath Groups
123       Multicast_Group
124                 Logical Port Multicast Groups
125       Mirror    Mirror Entry
126       Meter     Meter entry
127       Meter_Band
128                 Band for meter entries
129       Datapath_Binding
130                 Physical-Logical Datapath Bindings
131       Port_Binding
132                 Physical-Logical Port Bindings
133       MAC_Binding
134                 IP to MAC bindings
135       DHCP_Options
136                 DHCP Options supported by native OVN DHCP
137       DHCPv6_Options
138                 DHCPv6 Options supported by native OVN DHCPv6
139       Connection
140                 OVSDB client connections.
141       SSL       SSL configuration.
142       DNS       Native DNS resolution
143       RBAC_Role RBAC_Role configuration.
144       RBAC_Permission
145                 RBAC_Permission configuration.
146       Gateway_Chassis
147                 Gateway_Chassis configuration.
148       HA_Chassis
149                 HA_Chassis configuration.
150       HA_Chassis_Group
151                 HA_Chassis_Group configuration.
152       Controller_Event
153                 Controller Event table
154       IP_Multicast
155                 IP_Multicast configuration.
156       IGMP_Group
157                 IGMP_Group configuration.
158       Service_Monitor
159                 Service_Monitor configuration.
160       Load_Balancer
161                 Load_Balancer configuration.
162       BFD       BFD configuration.
163       FDB       Port to MAC bindings
164       Static_MAC_Binding
165                 IP to MAC bindings
166       Chassis_Template_Var
167                 Chassis_Template_Var configuration.
168

SB_Global TABLE

170       Southbound configuration for an OVN system. This table  must  have  ex‐
171       actly one row.
172
173   Summary:
174       Status:
175         nb_cfg                      integer
176       Common Columns:
177         external_ids                map of string-string pairs
178         options                     map of string-string pairs
179       Common options:
180         options                     map of string-string pairs
181         Options for configuring BFD:
182            options : bfd-min-rx     optional string
183            options : bfd-decay-min-rx
184                                     optional string
185            options : bfd-min-tx     optional string
186            options : bfd-mult       optional string
187            options : debug_drop_domain_id
188                                     optional string
189            options : debug_drop_collector_set
190                                     optional string
191         Options for configuring Load Balancers:
192            options : lb_hairpin_use_ct_mark
193                                     optional string
194         Options for configuring ovn-sbctl:
195            options : sbctl_probe_interval
196                                     optional string
197       Connection Options:
198         connections                 set of Connections
199         ssl                         optional SSL
200       Security Configurations:
201         ipsec                       boolean
202
203   Details:
204     Status:
205
206       This  column allow a client to track the overall configuration state of
207       the system.
208
209       nb_cfg: integer
210              Sequence number for the configuration. When a CMS  or  ovn-nbctl
211              updates the northbound database, it increments the nb_cfg column
212              in the NB_Global table in the northbound database. In turn, when
213              ovn-northd  updates  the  southbound  database to bring it up to
214              date with these changes, it updates  this  column  to  the  same
215              value.
216
217     Common Columns:
218
219       external_ids: map of string-string pairs
220              See External IDs at the beginning of this document.
221
222       options: map of string-string pairs
223
224     Common options:
225
226       options: map of string-string pairs
227              This  column  provides general key/value settings. The supported
228              options are described individually below.
229
230     Options for configuring BFD:
231
232       These options apply when ovn-controller configures BFD on  tunnels  in‐
233       terfaces.
234
235       options : bfd-min-rx: optional string
236              BFD  option  min-rx  value to use when configuring BFD on tunnel
237              interfaces.
238
239       options : bfd-decay-min-rx: optional string
240              BFD option decay-min-rx value to use  when  configuring  BFD  on
241              tunnel interfaces.
242
243       options : bfd-min-tx: optional string
244              BFD  option  min-tx  value to use when configuring BFD on tunnel
245              interfaces.
246
247       options : bfd-mult: optional string
248              BFD option mult value to use when configuring BFD on tunnel  in‐
249              terfaces.
250
251       options : debug_drop_domain_id: optional string
252              If set to a 8-bit number and if debug_drop_collector_set is also
253              configured, ovn-controller will add a  sample  action  to  every
254              flow  that  does  not  come  from a logical flow that contains a
255              ’drop’ action. The 8  most  significant  bits  of  the  observa‐
256              tion_domain_id  field  will  be  those  specified  in  the   de‐
257              bug_drop_domain_id. The 24 least significant bits of the  obser‐
258              vation_domain_id field will be zero.
259
260              The  observation_point_id will be set to the OpenFlow table num‐
261              ber.
262
263       options : debug_drop_collector_set: optional string
264              If set to a 32-bit number ovn-controller will add a  sample  ac‐
265              tion  to  every flow that does not come from a logical flow that
266              contains a ’drop’ action. The sample action will have the speci‐
267              fied  collector_set_id.  The  value must match that of the local
268              OVS configuration as described in ovs-actions(7).
269
270     Options for configuring Load Balancers:
271
272       These options apply when ovn-controller configures  load  balancer  re‐
273       lated flows.
274
275       options : lb_hairpin_use_ct_mark: optional string
276              By  default this option is turned on (even if not present in the
277              database) unless its value is  explicitly  set  to  false.  This
278              value  is  automatically  set to false by ovn-northd when action
279              ct_lb_mark cannot be used for new load balancer sessions and ac‐
280              tion  ct_lb will be used instead. ovn-controller then knows that
281              it should check ct_label.natted to detect load balanced traffic.
282
283     Options for configuring ovn-sbctl:
284
285       These options apply when ovn-sbctl connects to OVN Southbound database.
286
287       options : sbctl_probe_interval: optional string
288              The inactivity probe interval  of  the  connection  to  the  OVN
289              Southbound  database from ovn-sbctl utility, in milliseconds. If
290              the value is zero, it disables the connection keepalive feature.
291
292              If the value is nonzero, then it will be forced to a value of at
293              least 1000 ms.
294
295              If  the  value  is  less  than zero, then the default inactivity
296              probe interval for ovn-sbctl would be left intact (120000 ms).
297
298     Connection Options:
299
300       connections: set of Connections
301              Database clients to  which  the  Open  vSwitch  database  server
302              should  connect or on which it should listen, along with options
303              for how these connections should be configured. See the  Connec‐
304              tion table for more information.
305
306       ssl: optional SSL
307              Global SSL configuration.
308
309     Security Configurations:
310
311       ipsec: boolean
312              Tunnel  encryption  configuration.  If  this column is set to be
313              true, all OVN tunnels will be encrypted with IPsec.
314

Chassis TABLE

316       Each row in this table represents a hypervisor or gateway  (a  chassis)
317       in  the  physical  network.  Each  chassis, via ovn-controller/ovn-con‐
318       troller-vtep, adds and updates its own row, and keeps a copy of the re‐
319       maining rows to determine how to reach other hypervisors.
320
321       When  a  chassis  shuts  down gracefully, it should remove its own row.
322       (This is not critical because  resources  hosted  on  the  chassis  are
323       equally  unreachable  regardless  of  whether the row is present.) If a
324       chassis shuts down permanently without removing its row, some  kind  of
325       manual  or  automatic  cleanup  is  eventually  needed; we can devise a
326       process for that as necessary.
327
328   Summary:
329       name                          string (must be unique within table)
330       hostname                      string
331       nb_cfg                        integer
332       other_config : ovn-bridge-mappings
333                                     optional string
334       other_config : datapath-type  optional string
335       other_config : iface-types    optional string
336       other_config : ovn-cms-options
337                                     optional string
338       other_config : is-interconn   optional string
339       other_config : is-remote      optional string
340       transport_zones               set of strings
341       other_config : ovn-chassis-mac-mappings
342                                     optional string
343       other_config : port-up-notif  optional string
344       Common Columns:
345         external_ids                map of string-string pairs
346       Encapsulation Configuration:
347         encaps                      set of 1 or more Encaps
348       Gateway Configuration:
349         vtep_logical_switches       set of strings
350
351   Details:
352       name: string (must be unique within table)
353              OVN does not prescribe a particular format  for  chassis  names.
354              ovn-controller  populates this column using external_ids:system-
355              id in the Open_vSwitch database’s Open_vSwitch  table.  ovn-con‐
356              troller-vtep  populates  this  column  with  name  in  the hard‐
357              ware_vtep database’s Physical_Switch table.
358
359       hostname: string
360              The hostname of the chassis, if applicable. ovn-controller  will
361              populate this column with the hostname of the host it is running
362              on. ovn-controller-vtep will leave this column empty.
363
364       nb_cfg: integer
365              Deprecated. This column is replaced by the nb_cfg column of  the
366              Chassis_Private table.
367
368       other_config : ovn-bridge-mappings: optional string
369              ovn-controller  populates  this  key with the set of bridge map‐
370              pings it has been configured to use. Other  applications  should
371              treat  this key as read-only. See ovn-controller(8) for more in‐
372              formation.
373
374       other_config : datapath-type: optional string
375              ovn-controller populates this key with the datapath type config‐
376              ured  in the datapath_type column of the Open_vSwitch database’s
377              Bridge table. Other applications should treat this key as  read-
378              only. See ovn-controller(8) for more information.
379
380       other_config : iface-types: optional string
381              ovn-controller  populates this key with the interface types con‐
382              figured in the iface_types column of the Open_vSwitch database’s
383              Open_vSwitch  table. Other applications should treat this key as
384              read-only. See ovn-controller(8) for more information.
385
386       other_config : ovn-cms-options: optional string
387              ovn-controller populates this key with the set of  options  con‐
388              figured   in  the  external_ids:ovn-cms-options  column  of  the
389              Open_vSwitch  database’s  Open_vSwitch   table.   See   ovn-con‐
390              troller(8) for more information.
391
392       other_config : is-interconn: optional string
393              ovn-controller populates this key with the setting configured in
394              the external_ids:ovn-is-interconn  column  of  the  Open_vSwitch
395              database’s  Open_vSwitch  table.  If set to true, the chassis is
396              used as an interconnection gateway.  See  ovn-controller(8)  for
397              more information.
398
399       other_config : is-remote: optional string
400              ovn-ic  set  this key to true for remote interconnection gateway
401              chassises learned from the interconnection southbound  database.
402              See ovn-ic(8) for more information.
403
404       transport_zones: set of strings
405              ovn-controller  populates this key with the transport zones con‐
406              figured in the external_ids:ovn-transport-zones  column  of  the
407              Open_vSwitch   database’s   Open_vSwitch   table.  See  ovn-con‐
408              troller(8) for more information.
409
410       other_config : ovn-chassis-mac-mappings: optional string
411              ovn-controller populates this key with the set of  options  con‐
412              figured  in  the external_ids:ovn-chassis-mac-mappings column of
413              the Open_vSwitch database’s  Open_vSwitch  table.  See  ovn-con‐
414              troller(8) for more information.
415
416       other_config : port-up-notif: optional string
417              ovn-controller  populates  this  key  with true when it supports
418              Port_Binding.up.
419
420     Common Columns:
421
422       The overall purpose of these columns is described under Common  Columns
423       at the beginning of this document.
424
425       external_ids: map of string-string pairs
426
427     Encapsulation Configuration:
428
429       OVN  uses  encapsulation  to transmit logical dataplane packets between
430       chassis.
431
432       encaps: set of 1 or more Encaps
433              Points to supported  encapsulation  configurations  to  transmit
434              logical dataplane packets to this chassis. Each entry is a Encap
435              record that describes the configuration.
436
437     Gateway Configuration:
438
439       A gateway is a chassis that forwards traffic  between  the  OVN-managed
440       part of a logical network and a physical VLAN, extending a tunnel-based
441       logical network into a physical network. Gateways are  typically  dedi‐
442       cated  nodes  that  do  not host VMs and will be controlled by ovn-con‐
443       troller-vtep.
444
445       vtep_logical_switches: set of strings
446              Stores all VTEP logical switch names connected by  this  gateway
447              chassis.  The  Port_Binding table entry with options:vtep-physi‐
448              cal-switch equal Chassis name,  and  options:vtep-logical-switch
449              value  in Chassis vtep_logical_switches, will be associated with
450              this Chassis.
451

Chassis_Private TABLE

453       Each row in this table maintains per chassis private data that are  ac‐
454       cessed  only  by the owning chassis (write only) and ovn-northd, not by
455       any other chassis. These data are stored in this separate table instead
456       of  the  Chassis table for performance considerations: the rows in this
457       table can be conditionally monitored by chassises so that each  chassis
458       only  get  update  notifications  for its own row, to avoid unnecessary
459       chassis private data update flooding in a large scale deployment.
460
461   Summary:
462       name                          string (must be unique within table)
463       chassis                       optional weak reference to Chassis
464       nb_cfg                        integer
465       nb_cfg_timestamp              integer
466       Common Columns:
467         external_ids                map of string-string pairs
468
469   Details:
470       name: string (must be unique within table)
471              The name of the chassis that owns these chassis-private data.
472
473       chassis: optional weak reference to Chassis
474              The reference to Chassis table for the chassis that  owns  these
475              chassis-private data.
476
477       nb_cfg: integer
478              Sequence  number  for the configuration. When ovn-controller up‐
479              dates the configuration of a chassis from the  contents  of  the
480              southbound  database,  it copies nb_cfg from the SB_Global table
481              into this column.
482
483       nb_cfg_timestamp: integer
484              The timestamp when ovn-controller finishes processing the change
485              corresponding to nb_cfg.
486
487     Common Columns:
488
489       The  overall purpose of these columns is described under Common Columns
490       at the beginning of this document.
491
492       external_ids: map of string-string pairs
493

Encap TABLE

495       The encaps column in the Chassis table refers to rows in this table  to
496       identify  how  OVN may transmit logical dataplane packets to this chas‐
497       sis. Each chassis,  via  ovn-controller(8)  or  ovn-controller-vtep(8),
498       adds and updates its own rows and keeps a copy of the remaining rows to
499       determine how to reach other chassis.
500
501   Summary:
502       type                          string, one of geneve, stt, or vxlan
503       options                       map of string-string pairs
504       options : csum                optional string, either true or false
505       options : dst_port            optional string, containing an integer
506       ip                            string
507       chassis_name                  string
508
509   Details:
510       type: string, one of geneve, stt, or vxlan
511              The encapsulation to use to transmit packets  to  this  chassis.
512              Hypervisors and gateways must use one of: geneve, vxlan, or stt.
513
514       options: map of string-string pairs
515              Options  for  configuring  the  encapsulation, which may be type
516              specific.
517
518       options : csum: optional string, either true or false
519              csum indicates whether this chassis  can  transmit  and  receive
520              packets  that  include checksums with reasonable performance. It
521              hints to senders transmitting data to  this  chassis  that  they
522              should  use  checksums  to  protect OVN metadata. ovn-controller
523              populates this key with the value defined  in  external_ids:ovn-
524              encap-csum  column  of  the Open_vSwitch database’s Open_vSwitch
525              table. Other applications should treat this  key  as  read-only.
526              See ovn-controller(8) for more information.
527
528              In terms of performance, checksumming actually significantly in‐
529              creases throughput in most common cases when  running  on  Linux
530              based  hosts without NICs supporting encapsulation hardware off‐
531              load (around 60% for bulk traffic). The reason is that generally
532              all  NICs  are  capable  of  offloading transmitted and received
533              TCP/UDP checksums (viewed as ordinary data packets  and  not  as
534              tunnels).  The benefit comes on the receive side where the vali‐
535              dated outer checksum can be used to additionally validate an in‐
536              ner  checksum (such as TCP), which in turn allows aggregation of
537              packets to be more efficiently handled by the rest of the stack.
538
539              Not all devices see such a benefit. The most  notable  exception
540              is  hardware VTEPs. These devices are designed to not buffer en‐
541              tire packets in their switching engines and are therefore unable
542              to efficiently compute or validate full packet checksums. In ad‐
543              dition certain versions of the Linux  kernel  are  not  able  to
544              fully  take advantage of encapsulation NIC offloads in the pres‐
545              ence of checksums. (This is actually a pretty narrow corner case
546              though:  earlier  versions  of Linux don’t support encapsulation
547              offloads at all and later versions  support  both  offloads  and
548              checksums well.)
549
550              csum defaults to false for hardware VTEPs and true for all other
551              cases.
552
553              This option applies to geneve and vxlan encapsulations.
554
555       options : dst_port: optional string, containing an integer
556              If set, overrides the UDP (for geneve and  vxlan)  or  TCP  (for
557              stt) destination port.
558
559       ip: string
560              The IPv4 address of the encapsulation tunnel endpoint.
561
562       chassis_name: string
563              The name of the chassis that created this encap.
564

Address_Set TABLE

566       This  table  contains address sets synced from the Address_Set table in
567       the  OVN_Northbound  database  and  address  sets  generated  from  the
568       Port_Group table in the OVN_Northbound database.
569
570       See the documentation for the Address_Set table and Port_Group table in
571       the OVN_Northbound database for details.
572
573   Summary:
574       name                          string (must be unique within table)
575       addresses                     set of strings
576
577   Details:
578       name: string (must be unique within table)
579
580       addresses: set of strings
581

Port_Group TABLE

583       This  table  contains  names  for  the  logical  switch  ports  in  the
584       OVN_Northbound  database that belongs to the same group that is defined
585       in Port_Group in the OVN_Northbound database.
586
587   Summary:
588       name                          string (must be unique within table)
589       ports                         set of strings
590
591   Details:
592       name: string (must be unique within table)
593
594       ports: set of strings
595

Logical_Flow TABLE

597       Each row in this table represents one logical  flow.  ovn-northd  popu‐
598       lates  this  table  with  logical  flows  that  implement the L2 and L3
599       topologies specified in the OVN_Northbound database.  Each  hypervisor,
600       via  ovn-controller,  translates  the logical flows into OpenFlow flows
601       specific to its hypervisor and installs them into Open vSwitch.
602
603       Logical flows are expressed in an OVN-specific format, described  here.
604       A  logical datapath flow is much like an OpenFlow flow, except that the
605       flows are written in terms of logical ports and logical  datapaths  in‐
606       stead  of  physical  ports  and physical datapaths. Translation between
607       logical and physical flows helps to ensure  isolation  between  logical
608       datapaths.  (The  logical flow abstraction also allows the OVN central‐
609       ized components to do less work, since they do not have  to  separately
610       compute and push out physical flows to each chassis.)
611
612       The default action when no flow matches is to drop packets.
613
614       Architectural Logical Life Cycle of a Packet
615
616       This  following  description  focuses  on  the  life  cycle of a packet
617       through a logical datapath, ignoring physical details of the  implemen‐
618       tation.  Please  refer to Architectural Physical Life Cycle of a Packet
619       in ovn-architecture(7) for the physical information.
620
621       The description here is written as if OVN itself executes these  steps,
622       but  in  fact  OVN (that is, ovn-controller) programs Open vSwitch, via
623       OpenFlow and OVSDB, to execute them on its behalf.
624
625       At a high level, OVN passes each packet through the logical  datapath’s
626       logical  ingress  pipeline,  which may output the packet to one or more
627       logical port or logical multicast groups. For each such logical  output
628       port, OVN passes the packet through the datapath’s logical egress pipe‐
629       line, which may either drop the packet or deliver it  to  the  destina‐
630       tion.  Between  the  two pipelines, outputs to logical multicast groups
631       are expanded into logical ports, so that the egress pipeline only  pro‐
632       cesses  a  single  logical output port at a time. Between the two pipe‐
633       lines is also where, when necessary, OVN encapsulates  a  packet  in  a
634       tunnel (or tunnels) to transmit to remote hypervisors.
635
636       In more detail, to start, OVN searches the Logical_Flow table for a row
637       with correct logical_datapath or  a  logical_dp_group,  a  pipeline  of
638       ingress,  a  table_id of 0, and a match that is true for the packet. If
639       none is found, OVN drops the packet. If OVN finds  more  than  one,  it
640       chooses  the match with the highest priority. Then OVN executes each of
641       the actions specified in the row’s actions column, in the order  speci‐
642       fied.  Some actions, such as those to modify packet headers, require no
643       further details. The next and output actions are special.
644
645       The next action causes the above process to  be  repeated  recursively,
646       except that OVN searches for table_id of 1 instead of 0. Similarly, any
647       next action in a row found in that table would cause a  further  search
648       for  a  table_id  of 2, and so on. When recursive processing completes,
649       flow control returns to the action following next.
650
651       The output action also introduces recursion. Its effect depends on  the
652       current  value of the outport field. Suppose outport designates a logi‐
653       cal port. First, OVN compares inport to outport; if they are equal,  it
654       treats the output as a no-op by default. In the common case, where they
655       are different, the packet enters the egress pipeline.  This  transition
656       to  the  egress pipeline discards register data, e.g. reg0 ... reg9 and
657       connection tracking state, to achieve uniform  behavior  regardless  of
658       whether  the egress pipeline is on a different hypervisor (because reg‐
659       isters aren’t preserve across tunnel encapsulation).
660
661       To execute the egress pipeline, OVN again searches the Logical_Flow ta‐
662       ble  for  a  row with correct logical_datapath or a logical_dp_group, a
663       table_id of 0, a match that is true for the packet, but now looking for
664       a pipeline of egress. If no matching row is found, the output becomes a
665       no-op. Otherwise, OVN executes the actions for the matching flow (which
666       is chosen from multiple, if necessary, as already described).
667
668       In  the egress pipeline, the next action acts as already described, ex‐
669       cept that it, of course, searches for egress flows. The output  action,
670       however,  now  directly outputs the packet to the output port (which is
671       now fixed, because outport is read-only within the egress pipeline).
672
673       The description earlier assumed that  outport  referred  to  a  logical
674       port.  If it instead designates a logical multicast group, then the de‐
675       scription above still applies, with the addition of  fan-out  from  the
676       logical  multicast  group  to  each logical port in the group. For each
677       member of the group, OVN executes the logical  pipeline  as  described,
678       with the logical output port replaced by the group member.
679
680       Pipeline Stages
681
682       ovn-northd  populates the Logical_Flow table with the logical flows de‐
683       scribed in detail in ovn-northd(8).
684
685   Summary:
686       logical_datapath              optional Datapath_Binding
687       logical_dp_group              optional Logical_DP_Group
688       pipeline                      string, either egress or ingress
689       table_id                      integer, in range 0 to 32
690       priority                      integer, in range 0 to 65,535
691       match                         string
692       actions                       string
693       tags                          map of string-string pairs
694       controller_meter              optional string
695       external_ids : stage-name     optional string
696       external_ids : stage-hint     optional string, containing an uuid
697       external_ids : source         optional string
698       Common Columns:
699         external_ids                map of string-string pairs
700
701   Details:
702       logical_datapath: optional Datapath_Binding
703              The logical datapath to which the logical flow belongs.
704
705       logical_dp_group: optional Logical_DP_Group
706              The group of logical datapaths to which  the  logical  flow  be‐
707              longs.  This  means  that  the  same logical flow belongs to all
708              datapaths in a group.
709
710       pipeline: string, either egress or ingress
711              The primary flows used for deciding on  a  packet’s  destination
712              are the ingress flows. The egress flows implement ACLs. See Log‐
713              ical Life Cycle of a Packet, above, for details.
714
715       table_id: integer, in range 0 to 32
716              The stage in the logical pipeline, analogous to an OpenFlow  ta‐
717              ble number.
718
719       priority: integer, in range 0 to 65,535
720              The flow’s priority. Flows with numerically higher priority take
721              precedence over those with lower. If two logical datapath  flows
722              with the same priority both match, then the one actually applied
723              to the packet is undefined.
724
725       match: string
726              A matching expression.  OVN  provides  a  superset  of  OpenFlow
727              matching capabilities, using a syntax similar to Boolean expres‐
728              sions in a programming language.
729
730              The most important components of match  expression  are  compar‐
731              isons   between   symbols   and   constants,   e.g.  ip4.dst  ==
732              192.168.0.1, ip.proto == 6, arp.op == 1, eth.type == 0x800.  The
733              logical  AND  operator && and logical OR operator || can combine
734              comparisons into a larger expression.
735
736              Matching expressions also support parentheses for grouping,  the
737              logical  NOT  prefix operator !, and literals 0 and 1 to express
738              ``false’’ or ``true,’’ respectively. The latter is useful by it‐
739              self as a catch-all expression that matches every packet.
740
741              Match  expressions  also  support a kind of function syntax. The
742              following functions are supported:
743
744              is_chassis_resident(lport)
745                     Evaluates to true on a  chassis  on  which  logical  port
746                     lport  (a quoted string) resides, and to false elsewhere.
747                     This function was introduced in OVN 2.7.
748
749              Symbols
750
751              Type. Symbols have integer or string type. Integer symbols  have
752              a width in bits.
753
754              Kinds. There are three kinds of symbols:
755
756Fields.  A  field  symbol  represents  a packet header or
757                     metadata field. For example, a field named vlan.tci might
758                     represent the VLAN TCI field in a packet.
759
760                     A  field  symbol can have integer or string type. Integer
761                     fields can be nominal or ordinal (see Level  of  Measure‐
762                     ment, below).
763
764Subfields.  A subfield represents a subset of bits from a
765                     larger field. For example, a field vlan.vid might be  de‐
766                     fined as an alias for vlan.tci[0..11]. Subfields are pro‐
767                     vided for syntactic convenience,  because  it  is  always
768                     possible  to  instead  refer  to  a subset of bits from a
769                     field directly.
770
771                     Only ordinal fields (see Level of Measurement, below) may
772                     have subfields. Subfields are always ordinal.
773
774Predicates.  A  predicate  is shorthand for a Boolean ex‐
775                     pression. Predicates may be used much like 1-bit  fields.
776                     For example, ip4 might expand to eth.type == 0x800. Pred‐
777                     icates are provided for syntactic convenience, because it
778                     is  always possible to instead specify the underlying ex‐
779                     pression directly.
780
781                     A predicate whose expansion refers to any  nominal  field
782                     or  predicate  (see Level of Measurement, below) is nomi‐
783                     nal; other predicates have Boolean level of measurement.
784
785              Level              of              Measurement.              See
786              http://en.wikipedia.org/wiki/Level_of_measurement  for  the sta‐
787              tistical concept on which this classification  is  based.  There
788              are three levels:
789
790Ordinal.  In statistics, ordinal values can be ordered on
791                     a scale. OVN considers a field (or subfield) to be  ordi‐
792                     nal  if  its  bits  can be examined individually. This is
793                     true for  the  OpenFlow  fields  that  OpenFlow  or  Open
794                     vSwitch makes ``maskable.’’
795
796                     Any  use of a ordinal field may specify a single bit or a
797                     range of bits, e.g. vlan.tci[13..15] refers  to  the  PCP
798                     field  within the VLAN TCI, and eth.dst[40] refers to the
799                     multicast bit in the Ethernet destination address.
800
801                     OVN supports all the usual arithmetic relations (==,  !=,
802                     <,  <=, >, and >=) on ordinal fields and their subfields,
803                     because OVN can implement  these  in  OpenFlow  and  Open
804                     vSwitch as collections of bitwise tests.
805
806Nominal. In statistics, nominal values cannot be usefully
807                     compared except for equality. This is  true  of  OpenFlow
808                     port  numbers, Ethernet types, and IP protocols are exam‐
809                     ples: all of these are just  identifiers  assigned  arbi‐
810                     trarily  with  no  deeper  meaning.  In OpenFlow and Open
811                     vSwitch, bits in these fields generally aren’t  individu‐
812                     ally addressable.
813
814                     OVN  only supports arithmetic tests for equality on nomi‐
815                     nal fields, because OpenFlow and Open vSwitch provide  no
816                     way for a flow to efficiently implement other comparisons
817                     on them. (A test for inequality can be sort of built  out
818                     of  two flows with different priorities, but OVN matching
819                     expressions always generate flows with  a  single  prior‐
820                     ity.)
821
822                     String fields are always nominal.
823
824Boolean.  A nominal field that has only two values, 0 and
825                     1, is somewhat exceptional, since it is easy  to  support
826                     both  equality  and inequality tests on such a field: ei‐
827                     ther one can be implemented as a test for 0 or 1.
828
829                     Only predicates (see above) have a Boolean level of  mea‐
830                     surement.
831
832                     This isn’t a standard level of measurement.
833
834              Prerequisites.  Any symbol can have prerequisites, which are ad‐
835              ditional condition implied by the use of the symbol.  For  exam‐
836              ple,  For  example,  icmp4.type  symbol  might have prerequisite
837              icmp4, which would cause an expression icmp4.type == 0 to be in‐
838              terpreted  as  icmp4.type == 0 && icmp4, which would in turn ex‐
839              pand to icmp4.type == 0 && eth.type == 0x800 && ip4.proto  ==  1
840              (assuming  icmp4 is a predicate defined as suggested under Types
841              above).
842
843              Relational operators
844
845              All of the standard relational operators ==, !=, <, <=,  >,  and
846              >=  are  supported.  Nominal  fields support only == and !=, and
847              only in a positive sense when outer ! are  taken  into  account,
848              e.g. given string field inport, inport == "eth0" and !(inport !=
849              "eth0") are acceptable, but not inport != "eth0".
850
851              The implementation of == (or != when it is negated), is more ef‐
852              ficient than that of the other relational operators.
853
854              Constants
855
856              Integer  constants may be expressed in decimal, hexadecimal pre‐
857              fixed by 0x, or as dotted-quad IPv4 addresses, IPv6 addresses in
858              their  standard  forms, or Ethernet addresses as colon-separated
859              hex digits. A constant in any of these forms may be followed  by
860              a  slash  and  a second constant (the mask) in the same form, to
861              form a masked constant. IPv4 and IPv6 masks may be given as  in‐
862              tegers, to express CIDR prefixes.
863
864              String  constants have the same syntax as quoted strings in JSON
865              (thus, they are Unicode strings).
866
867              Some operators support sets of constants  written  inside  curly
868              braces  { ... }. Commas between elements of a set, and after the
869              last elements, are optional. With ==, ``field  ==  {  constant1,
870              constant2,  ...  }’’ is syntactic sugar for ``field == constant1
871              || field == constant2 || .... Similarly, ``field != { constant1,
872              constant2,  ...  }’’  is  equivalent  to ``field != constant1 &&
873              field != constant2 && ...’’.
874
875              You may refer to a set of IPv4, IPv6, or MAC addresses stored in
876              the Address_Set table by its name. An Address_Set with a name of
877              set1 can be referred to as $set1.
878
879              You may refer to a group of logical switch ports stored  in  the
880              Port_Group  table  by  its  name.  An  Port_Group with a name of
881              port_group1 can be referred to as @port_group1.
882
883              Additionally, you may refer to the set of addresses belonging to
884              a  group  of logical switch ports stored in the Port_Group table
885              by its name followed by a suffix ’_ip4’/’_ip6’. The IPv4 address
886              set  of  a Port_Group with a name of port_group1 can be referred
887              to as $port_group1_ip4, and the IPv6 address  set  of  the  same
888              Port_Group can be referred to as $port_group1_ip6
889
890              Miscellaneous
891
892              Comparisons  may  name  the  symbol  or the constant first, e.g.
893              tcp.src == 80 and 80 == tcp.src are both acceptable.
894
895              Tests for a range may be expressed using a syntax like  1024  <=
896              tcp.src  <=  49151,  which  is  equivalent to 1024 <= tcp.src &&
897              tcp.src <= 49151.
898
899              For a one-bit field or predicate,  a  mention  of  its  name  is
900              equivalent  to  symobl  == 1, e.g. vlan.present is equivalent to
901              vlan.present == 1. The same is true for one-bit subfields,  e.g.
902              vlan.tci[12].  There  is no technical limitation to implementing
903              the same for ordinal fields of all widths, but  the  implementa‐
904              tion is expensive enough that the syntax parser requires writing
905              an explicit  comparison  against  zero  to  make  mistakes  less
906              likely,  e.g.  in  tcp.src  != 0 the comparison against 0 is re‐
907              quired.
908
909              Operator precedence is as shown below, from highest  to  lowest.
910              There  are  two  exceptions  where parentheses are required even
911              though the table would suggest that they are not: && and ||  re‐
912              quire parentheses when used together, and ! requires parentheses
913              when applied to a relational expression. Thus, in  (eth.type  ==
914              0x800 || eth.type == 0x86dd) && ip.proto == 6 or !(arp.op == 1),
915              the parentheses are mandatory.
916
917()
918
919==   !=   <   <=   >   >=
920
921!
922
923&&   ||
924
925              Comments may be introduced by //, which extends to the next new-
926              line. Comments within a line may be bracketed by /* and */. Mul‐
927              tiline comments are not supported.
928
929              Symbols
930
931              Most of the symbols below have integer  type.  Only  inport  and
932              outport have string type. inport names a logical port. Thus, its
933              value is a logical_port name from the Port_Binding  table.  out‐
934              port  may name a logical port, as inport, or a logical multicast
935              group defined in the Multicast_Group table.  For  both  symbols,
936              only names within the flow’s logical datapath may be used.
937
938              The  regX  symbols  are  32-bit integers. The xxregX symbols are
939              128-bit integers, which overlay four of  the  32-bit  registers:
940              xxreg0 overlays reg0 through reg3, with reg0 supplying the most-
941              significant bits  of  xxreg0  and  reg3  the  least-significant.
942              xxreg1 similarly overlays reg4 through reg7.
943
944reg0...reg9
945
946xxreg0 xxreg1
947
948inport outport
949
950flags.loopback
951
952pkt.mark
953
954eth.src eth.dst eth.type
955
956vlan.tci vlan.vid vlan.pcp vlan.present
957
958ip.proto ip.dscp ip.ecn ip.ttl ip.frag
959
960ip4.src ip4.dst
961
962ip6.src ip6.dst ip6.label
963
964arp.op arp.spa arp.tpa arp.sha arp.tha
965
966rarp.op rarp.spa rarp.tpa rarp.sha rarp.tha
967
968tcp.src tcp.dst tcp.flags
969
970udp.src udp.dst
971
972sctp.src sctp.dst
973
974icmp4.type icmp4.code
975
976icmp6.type icmp6.code
977
978nd.target nd.sll nd.tll
979
980ct_mark ct_label
981
982ct_state,   which  has  several  Boolean  subfields.  The
983                     ct_next action initializes the following subfields:
984
985ct.trk: Always set to true by ct_next to  indicate
986                            that  connection  tracking  has  taken  place. All
987                            other ct subfields have ct.trk as a prerequisite.
988
989ct.new: True for a new flow
990
991ct.est: True for an established flow
992
993ct.rel: True for a related flow
994
995ct.rpl: True for a reply flow
996
997ct.inv: True for a connection entry in a bad state
998
999                     The ct_dnat, ct_snat, and ct_lb  actions  initialize  the
1000                     following subfields:
1001
1002ct.dnat:  True  for  a packet whose destination IP
1003                            address has been changed.
1004
1005ct.snat: True for a packet whose source IP address
1006                            has been changed.
1007
1008              The following predicates are supported:
1009
1010eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff
1011
1012eth.mcast expands to eth.dst[40]
1013
1014vlan.present expands to vlan.tci[12]
1015
1016ip4 expands to eth.type == 0x800
1017
1018ip4.src_mcast expands to ip4.src[28..31] == 0xe
1019
1020ip4.mcast expands to ip4.dst[28..31] == 0xe
1021
1022ip6 expands to eth.type == 0x86dd
1023
1024ip expands to ip4 || ip6
1025
1026icmp4 expands to ip4 && ip.proto == 1
1027
1028icmp6 expands to ip6 && ip.proto == 58
1029
1030icmp expands to icmp4 || icmp6
1031
1032ip.is_frag expands to ip.frag[0]
1033
1034ip.later_frag expands to ip.frag[1]
1035
1036ip.first_frag expands to ip.is_frag && !ip.later_frag
1037
1038arp expands to eth.type == 0x806
1039
1040rarp expands to eth.type == 0x8035
1041
1042nd expands to icmp6.type == {135, 136} && icmp6.code == 0
1043                     && ip.ttl == 255
1044
1045nd_ns expands to icmp6.type == 135 && icmp6.code == 0  &&
1046                     ip.ttl == 255
1047
1048nd_na  expands to icmp6.type == 136 && icmp6.code == 0 &&
1049                     ip.ttl == 255
1050
1051nd_rs expands to icmp6.type == 133 && icmp6.code == 0  &&
1052                     ip.ttl == 255
1053
1054nd_ra  expands to icmp6.type == 134 && icmp6.code == 0 &&
1055                     ip.ttl == 255
1056
1057tcp expands to ip.proto == 6
1058
1059udp expands to ip.proto == 17
1060
1061sctp expands to ip.proto == 132
1062
1063       actions: string
1064              Logical datapath actions, to be executed when the  logical  flow
1065              represented by this row is the highest-priority match.
1066
1067              Actions share lexical syntax with the match column. An empty set
1068              of actions (or one that contains just white space or  comments),
1069              or  a  set  of  actions  that consists of just drop;, causes the
1070              matched packets to be dropped. Otherwise, the column should con‐
1071              tain a sequence of actions, each terminated by a semicolon.
1072
1073              The following actions are defined:
1074
1075              output;
1076                     In  the ingress pipeline, this action executes the egress
1077                     pipeline as a subroutine.  If  outport  names  a  logical
1078                     port,  the egress pipeline executes once; if it is a mul‐
1079                     ticast group, the egress pipeline runs once for each log‐
1080                     ical port in the group.
1081
1082                     In  the  egress pipeline, this action performs the actual
1083                     output to the outport logical port. (In the egress  pipe‐
1084                     line, outport never names a multicast group.)
1085
1086                     By  default,  output  to  the  input  port  is implicitly
1087                     dropped, that is, output becomes a no-op  if  outport  ==
1088                     inport.  Occasionally  it  may be useful to override this
1089                     behavior, e.g. to send an ARP reply to an ARP request; to
1090                     do  so,  use  flags.loopback  =  1 to allow the packet to
1091                     "hair-pin" back to the input port.
1092
1093              next;
1094              next(table);
1095              next(pipeline=pipeline, table=table);
1096                   Executes the given logical datapath table in pipeline as  a
1097                   subroutine.  The  default  table  is just after the current
1098                   one. If pipeline is specified, it may be ingress or egress;
1099                   the  default  pipeline  is the one currently executing. Ac‐
1100                   tions in the both ingress and egress pipeline can use  next
1101                   to  jump  across the other pipeline. Actions in the ingress
1102                   pipeline should use next to jump into the specific table of
1103                   egress  pipeline only if it is certain that the packets are
1104                   local and not tunnelled and wants to skip certain stages in
1105                   the packet processing.
1106
1107              field = constant;
1108                   Sets  data  or  metadata field field to constant value con‐
1109                   stant, e.g. outport = "vif0"; to  set  the  logical  output
1110                   port.  To  set  only a subset of bits in a field, specify a
1111                   subfield for field or a masked constant, e.g. one  may  use
1112                   vlan.pcp[2] = 1; or vlan.pcp = 4/4; to set the most signif‐
1113                   icant bit of the VLAN PCP.
1114
1115                   Assigning to a field  with  prerequisites  implicitly  adds
1116                   those  prerequisites  to  match;  thus, for example, a flow
1117                   that sets tcp.dst applies only to TCP flows, regardless  of
1118                   whether its match mentions any TCP field.
1119
1120                   Not  all  fields are modifiable (e.g. eth.type and ip.proto
1121                   are read-only), and not all modifiable fields may  be  par‐
1122                   tially modified (e.g. ip.ttl must assigned as a whole). The
1123                   outport field is modifiable in the ingress pipeline but not
1124                   in the egress pipeline.
1125
1126              ovn_field = constant;
1127                   Sets OVN field ovn_field to constant value constant.
1128
1129                   OVN supports setting the values of certain fields which are
1130                   not yet supported in OpenFlow to set or modify them.
1131
1132                   Below are the supported OVN fields:
1133
1134icmp4.frag_mtu icmp6.frag_mtu
1135
1136                          This  field  sets  the  low-order  16  bits  of  the
1137                          ICMP{4,6}  header field that is labelled "unused" in
1138                          the ICMP specification as defined in  the  RFC  1191
1139                          with the value specified in constant.
1140
1141                          Eg. icmp4.frag_mtu = 1500;
1142
1143              field1 = field2;
1144                   Sets  data or metadata field field1 to the value of data or
1145                   metadata field field2, e.g. reg0 = ip4.src; copies  ip4.src
1146                   into reg0. To modify only a subset of a field’s bits, spec‐
1147                   ify a subfield for field1 or field2 or both, e.g.  vlan.pcp
1148                   =  reg0[0..2];  copies  the  least-significant bits of reg0
1149                   into the VLAN PCP.
1150
1151                   field1 and field2 must be the same type, either both string
1152                   or  both  integer  fields. If they are both integer fields,
1153                   they must have the same width.
1154
1155                   If field1 or field2 has prerequisites, they are  added  im‐
1156                   plicitly  to  match.  It is possible to write an assignment
1157                   with  contradictory  prerequisites,  such  as   ip4.src   =
1158                   ip6.src[0..31];, but the contradiction means that a logical
1159                   flow with such an assignment will never be matched.
1160
1161              field1 <-> field2;
1162                   Similar to field1 = field2; except that the two values  are
1163                   exchanged  instead  of  copied. Both field1 and field2 must
1164                   modifiable.
1165
1166              push(field);
1167                   Push the value of field to the stack top.
1168
1169              pop(field);
1170                   Pop the stack top and store the value to field, which  must
1171                   be modifiable.
1172
1173              ip.ttl--;
1174                   Decrements the IPv4 or IPv6 TTL. If this would make the TTL
1175                   zero or negative, then processing of the packet  halts;  no
1176                   further  actions  are  processed.  (To properly handle such
1177                   cases, a higher-priority flow should match on ip.ttl == {0,
1178                   1};.)
1179
1180                   Prerequisite: ip
1181
1182              ct_next;
1183                   Apply   connection   tracking  to  the  flow,  initializing
1184                   ct_state for matching in later tables. Automatically  moves
1185                   on to the next table, as if followed by next.
1186
1187                   As  a  side  effect,  IP  fragments will be reassembled for
1188                   matching. If a fragmented packet is output, then it will be
1189                   sent  with  any overlapping fragments squashed. The connec‐
1190                   tion tracking state is scoped by the logical port when  the
1191                   action  is used in a flow for a logical switch, so overlap‐
1192                   ping addresses may be used. To allow traffic related to the
1193                   matched flow, execute ct_commit . Connection tracking state
1194                   is scoped by the logical topology when the action  is  used
1195                   in a flow for a router.
1196
1197                   It  is  possible  to  have actions follow ct_next, but they
1198                   will not have access to any of its side-effects and is  not
1199                   generally useful.
1200
1201              ct_commit { };
1202              ct_commit { ct_mark=value[/mask]; };
1203              ct_commit { ct_label=value[/mask]; };
1204              ct_commit { ct_mark=value[/mask]; ct_label=value[/mask]; };
1205                   Commit the flow to the connection tracking entry associated
1206                   with   it   by   a   previous   call   to   ct_next.   When
1207                   ct_mark=value[/mask]  and/or ct_label=value[/mask] are sup‐
1208                   plied, ct_mark and/or ct_label will be set  to  the  values
1209                   indicated by value[/mask] on the connection tracking entry.
1210                   ct_mark is a 32-bit field. ct_label is a 128-bit field. The
1211                   value[/mask] should be specified in hex string if more than
1212                   64bits are to be used. Registers and other named fields can
1213                   be  used  for  value.  ct_mark  and ct_label may be sub-ad‐
1214                   dressed in order to have specific bits set.
1215
1216                   Note that if you want processing to continue  in  the  next
1217                   table,  you  must  execute the next action after ct_commit.
1218                   You may also leave out next which  will  commit  connection
1219                   tracking  state,  and  then  drop the packet. This could be
1220                   useful for setting ct_mark on a connection  tracking  entry
1221                   before dropping a packet, for example.
1222
1223              ct_dnat;
1224              ct_dnat(IP);
1225                   ct_dnat  sends  the packet through the DNAT zone in connec‐
1226                   tion tracking table to unDNAT any packet that was DNATed in
1227                   the  opposite  direction.  The packet is then automatically
1228                   sent to to the next tables as if followed by next;  action.
1229                   The  next  tables will see the changes in the packet caused
1230                   by the connection tracker.
1231
1232                   ct_dnat(IP) sends the  packet  through  the  DNAT  zone  to
1233                   change  the destination IP address of the packet to the one
1234                   provided inside the parentheses and commits the connection.
1235                   The packet is then automatically sent to the next tables as
1236                   if followed by next; action. The next tables will  see  the
1237                   changes in the packet caused by the connection tracker.
1238
1239              ct_snat;
1240              ct_snat(IP);
1241                   ct_snat  sends  the  packet through the SNAT zone to unSNAT
1242                   any packet that was SNATed in the opposite  direction.  The
1243                   packet  is automatically sent to the next tables as if fol‐
1244                   lowed by the next; action. The next  tables  will  see  the
1245                   changes in the packet caused by the connection tracker.
1246
1247                   ct_snat(IP)  sends  the  packet  through  the  SNAT zone to
1248                   change the source IP address of the packet to the one  pro‐
1249                   vided  inside  the  parenthesis and commits the connection.
1250                   The packet is then automatically sent to the next tables as
1251                   if  followed  by next; action. The next tables will see the
1252                   changes in the packet caused by the connection tracker.
1253
1254              ct_dnat_in_czone;
1255              ct_dnat_in_czone(IP);
1256                   ct_dnat_in_czone sends the packet through  the  common  NAT
1257                   zone  (used  for both DNAT and SNAT) in connection tracking
1258                   table to unDNAT any packet that was DNATed in the  opposite
1259                   direction.  The packet is then automatically sent to to the
1260                   next tables as if followed by next; action. The next tables
1261                   will see the changes in the packet caused by the connection
1262                   tracker.
1263
1264                   ct_dnat_in_czone(IP) sends the packet  through  the  common
1265                   NAT zone to change the destination IP address of the packet
1266                   to the one provided inside the parentheses and commits  the
1267                   connection.  The  packet  is then automatically sent to the
1268                   next tables as if followed by next; action. The next tables
1269                   will see the changes in the packet caused by the connection
1270                   tracker.
1271
1272              ct_snat_in_czone;
1273              ct_snat_in_czone(IP);
1274                   ct_snat_in_czone sends the packet through  the  common  NAT
1275                   zone  to  unSNAT any packet that was SNATed in the opposite
1276                   direction. The packet is automatically sent to the next ta‐
1277                   bles  as  if  followed by the next; action. The next tables
1278                   will see the changes in the packet caused by the connection
1279                   tracker.
1280
1281                   ct_snat_in_czone(IP)  sends  the packet\ through the common
1282                   NAT zone to change the source IP address of the  packet  to
1283                   the  one  provided  inside  the parenthesis and commits the
1284                   connection. The packet is then automatically  sent  to  the
1285                   next tables as if followed by next; action. The next tables
1286                   will see the changes in the packet caused by the connection
1287                   tracker.
1288
1289              ct_clear;
1290                   Clears connection tracking state.
1291
1292              ct_commit_nat;
1293                   Applies NAT and commits the connection to the CT. Automati‐
1294                   cally moves on to the next table, as if followed  by  next.
1295                   This  is  very  useful  for connections that are in related
1296                   state for already existing connections and allows  the  NAT
1297                   to be applied to them as well.
1298
1299              clone { action; ... };
1300                   Makes  a  copy  of  the packet being processed and executes
1301                   each action on the copy. Actions following  the  clone  ac‐
1302                   tion,  if  any,  apply  to the original, unmodified packet.
1303                   This can be used as a  way  to  ``save  and  restore’’  the
1304                   packet  around  a  set  of  actions  that may modify it and
1305                   should not persist.
1306
1307              arp { action; ... };
1308                   Temporarily replaces the IPv4 packet being processed by  an
1309                   ARP  packet  and  executes  each  nested  action on the ARP
1310                   packet. Actions following the arp action, if any, apply  to
1311                   the original, unmodified packet.
1312
1313                   The  ARP packet that this action operates on is initialized
1314                   based on the IPv4 packet being processed, as follows. These
1315                   are  default  values  that the nested actions will probably
1316                   want to change:
1317
1318eth.src unchanged
1319
1320eth.dst unchanged
1321
1322eth.type = 0x0806
1323
1324arp.op = 1 (ARP request)
1325
1326arp.sha copied from eth.src
1327
1328arp.spa copied from ip4.src
1329
1330arp.tha = 00:00:00:00:00:00
1331
1332arp.tpa copied from ip4.dst
1333
1334                   The ARP packet has the same VLAN header, if any, as the  IP
1335                   packet it replaces.
1336
1337                   Prerequisite: ip4
1338
1339              get_arp(P, A);
1340                   Parameters:  logical port string field P, 32-bit IP address
1341                   field A.
1342
1343                   Looks up A in P’s mac binding table. If an entry is  found,
1344                   stores  its  Ethernet  address in eth.dst, otherwise stores
1345                   00:00:00:00:00:00 in eth.dst.
1346
1347                   Example: get_arp(outport, ip4.dst);
1348
1349              put_arp(P, A, E);
1350                   Parameters: logical port string field P, 32-bit IP  address
1351                   field A, 48-bit Ethernet address field E.
1352
1353                   Adds  or updates the entry for IP address A in logical port
1354                   P’s mac binding table, setting its Ethernet address to E.
1355
1356                   Example: put_arp(inport, arp.spa, arp.sha);
1357
1358              R = lookup_arp(P, A, M);
1359                   Parameters: logical port string field P, 32-bit IP  address
1360                   field A, 48-bit MAC address field M.
1361
1362                   Result: stored to a 1-bit subfield R.
1363
1364                   Looks  up  A and M in P’s mac binding table. If an entry is
1365                   found, stores 1 in the 1-bit subfield R, else 0.
1366
1367                   Example: reg0[0] = lookup_arp(inport, arp.spa, arp.sha);
1368
1369              R = lookup_arp_ip(P, A);
1370                   Parameters: logical port string field P, 32-bit IP  address
1371                   field A.
1372
1373                   Result: stored to a 1-bit subfield R.
1374
1375                   Looks  up A in P’s mac binding table. If an entry is found,
1376                   stores 1 in the 1-bit subfield R, else 0.
1377
1378                   Example: reg0[0] = lookup_arp_ip(inport, arp.spa);
1379
1380              P = get_fdb(A);
1381                   Parameters:48-bit MAC address field A.
1382
1383                   Looks up A in fdb table. If an entry is found,  stores  the
1384                   logical port key to the out parameter P.
1385
1386                   Example: outport = get_fdb(eth.src);
1387
1388              put_fdb(P, A);
1389                   Parameters: logical port string field P, 48-bit MAC address
1390                   field A.
1391
1392                   Adds or updates the entry for Ethernet address A in fdb ta‐
1393                   ble, setting its logical port key to P.
1394
1395                   Example: put_fdb(inport, arp.spa);
1396
1397              R = lookup_fdb(P, A);
1398                   Parameters: 48-bit MAC address field M, logical port string
1399                   field P.
1400
1401                   Result: stored to a 1-bit subfield R.
1402
1403                   Looks up A in fdb table. If an entry is found and the logi‐
1404                   cal  port  key  is  P, P, stores 1 in the 1-bit subfield R,
1405                   else 0. If flags.localnet is set then 1 is stored if an en‐
1406                   try  is  found and the logical port key is P or if an entry
1407                   is found and the entry port type is VIF.
1408
1409                   Example: reg0[0] = lookup_fdb(inport, eth.src);
1410
1411              nd_ns { action; ... };
1412                   Temporarily replaces the IPv6 packet being processed by  an
1413                   IPv6  Neighbor Solicitation packet and executes each nested
1414                   action on the IPv6 NS packet. Actions following  the  nd_ns
1415                   action, if any, apply to the original, unmodified packet.
1416
1417                   The IPv6 NS packet that this action operates on is initial‐
1418                   ized based on the IPv6 packet being processed, as  follows.
1419                   These are default values that the nested actions will prob‐
1420                   ably want to change:
1421
1422eth.src unchanged
1423
1424eth.dst set to IPv6 multicast MAC address
1425
1426eth.type = 0x86dd
1427
1428ip6.src copied from ip6.src
1429
1430ip6.dst set to IPv6 Solicited-Node multicast address
1431
1432icmp6.type = 135 (Neighbor Solicitation)
1433
1434nd.target copied from ip6.dst
1435
1436                   The IPv6 NS packet has the same VLAN header, if any, as the
1437                   IP packet it replaces.
1438
1439                   Prerequisite: ip6
1440
1441              nd_na { action; ... };
1442                   Temporarily  replaces the IPv6 neighbor solicitation packet
1443                   being processed by  an  IPv6  neighbor  advertisement  (NA)
1444                   packet  and  executes  each nested action on the NA packet.
1445                   Actions following the nd_na action, if any,  apply  to  the
1446                   original, unmodified packet.
1447
1448                   The  NA  packet that this action operates on is initialized
1449                   based on the IPv6 packet being processed, as follows. These
1450                   are  default  values  that the nested actions will probably
1451                   want to change:
1452
1453eth.dst exchanged with eth.src
1454
1455eth.type = 0x86dd
1456
1457ip6.dst copied from ip6.src
1458
1459ip6.src copied from nd.target
1460
1461icmp6.type = 136 (Neighbor Advertisement)
1462
1463nd.target unchanged
1464
1465nd.sll = 00:00:00:00:00:00
1466
1467nd.tll copied from eth.dst
1468
1469                   The ND packet has the same VLAN header, if any, as the IPv6
1470                   packet it replaces.
1471
1472                   Prerequisite: nd_ns
1473
1474              nd_na_router { action; ... };
1475                   Temporarily  replaces the IPv6 neighbor solicitation packet
1476                   being processed by  an  IPv6  neighbor  advertisement  (NA)
1477                   packet,  sets  ND_NSO_ROUTER  in the RSO flags and executes
1478                   each nested action on the NA packet. Actions following  the
1479                   nd_na_router action, if any, apply to the original, unmodi‐
1480                   fied packet.
1481
1482                   The NA packet that this action operates on  is  initialized
1483                   based on the IPv6 packet being processed, as follows. These
1484                   are default values that the nested  actions  will  probably
1485                   want to change:
1486
1487eth.dst exchanged with eth.src
1488
1489eth.type = 0x86dd
1490
1491ip6.dst copied from ip6.src
1492
1493ip6.src copied from nd.target
1494
1495icmp6.type = 136 (Neighbor Advertisement)
1496
1497nd.target unchanged
1498
1499nd.sll = 00:00:00:00:00:00
1500
1501nd.tll copied from eth.dst
1502
1503                   The ND packet has the same VLAN header, if any, as the IPv6
1504                   packet it replaces.
1505
1506                   Prerequisite: nd_ns
1507
1508              get_nd(P, A);
1509                   Parameters: logical port string field P, 128-bit  IPv6  ad‐
1510                   dress field A.
1511
1512                   Looks  up A in P’s mac binding table. If an entry is found,
1513                   stores its Ethernet address in  eth.dst,  otherwise  stores
1514                   00:00:00:00:00:00 in eth.dst.
1515
1516                   Example: get_nd(outport, ip6.dst);
1517
1518              put_nd(P, A, E);
1519                   Parameters:  logical  port string field P, 128-bit IPv6 ad‐
1520                   dress field A, 48-bit Ethernet address field E.
1521
1522                   Adds or updates the entry for IPv6  address  A  in  logical
1523                   port P’s mac binding table, setting its Ethernet address to
1524                   E.
1525
1526                   Example: put_nd(inport, nd.target, nd.tll);
1527
1528              R = lookup_nd(P, A, M);
1529                   Parameters: logical port string field P, 128-bit IP address
1530                   field A, 48-bit MAC address field M.
1531
1532                   Result: stored to a 1-bit subfield R.
1533
1534                   Looks  up  A and M in P’s mac binding table. If an entry is
1535                   found, stores 1 in the 1-bit subfield R, else 0.
1536
1537                   Example: reg0[0] = lookup_nd(inport, ip6.src, eth.src);
1538
1539              R = lookup_nd_ip(P, A);
1540                   Parameters: logical port string field P, 128-bit IP address
1541                   field A.
1542
1543                   Result: stored to a 1-bit subfield R.
1544
1545                   Looks  up A in P’s mac binding table. If an entry is found,
1546                   stores 1 in the 1-bit subfield R, else 0.
1547
1548                   Example: reg0[0] = lookup_nd_ip(inport, ip6.src);
1549
1550              R = put_dhcp_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1551                   Parameters: one or more DHCP option/value pairs, which must
1552                   include an offerip option (with code 0).
1553
1554                   Result: stored to a 1-bit subfield R.
1555
1556                   Valid only in the ingress pipeline.
1557
1558                   When  this  action  is  applied  to  a  DHCP request packet
1559                   (DHCPDISCOVER or DHCPREQUEST), it changes the packet into a
1560                   DHCP  reply  (DHCPOFFER or DHCPACK, respectively), replaces
1561                   the options by those specified as parameters, and stores  1
1562                   in R.
1563
1564                   When  this action is applied to a non-DHCP packet or a DHCP
1565                   packet that is not DHCPDISCOVER or DHCPREQUEST,  it  leaves
1566                   the packet unchanged and stores 0 in R.
1567
1568                   The  contents of the DHCP_Option table control the DHCP op‐
1569                   tion names and values that this action supports.
1570
1571                   Example: reg0[0] = put_dhcp_opts(offerip = 10.0.0.2, router
1572                   = 10.0.0.1, netmask = 255.255.255.0, dns_server = {8.8.8.8,
1573                   7.7.7.7});
1574
1575              R = put_dhcpv6_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1576                   Parameters: one or more DHCPv6 option/value pairs.
1577
1578                   Result: stored to a 1-bit subfield R.
1579
1580                   Valid only in the ingress pipeline.
1581
1582                   When this action is applied to a DHCPv6 request packet,  it
1583                   changes  the  packet  into a DHCPv6 reply, replaces the op‐
1584                   tions by those specified as parameters, and stores 1 in R.
1585
1586                   When this action is applied to a non-DHCPv6  packet  or  an
1587                   invalid  DHCPv6  request  packet , it leaves the packet un‐
1588                   changed and stores 0 in R.
1589
1590                   The contents of the DHCPv6_Options table control the DHCPv6
1591                   option names and values that this action supports.
1592
1593                   Example:   reg0[3]  =  put_dhcpv6_opts(ia_addr  =  aef0::4,
1594                   server_id               =                00:00:00:00:10:02,
1595                   dns_server={ae70::1,ae70::2});
1596
1597              set_queue(queue_number);
1598                   Parameters:  Queue  number  queue_number, in the range 0 to
1599                   61440.
1600
1601                   This is a logical equivalent of the OpenFlow set_queue  ac‐
1602                   tion. It affects packets that egress a hypervisor through a
1603                   physical interface. For nonzero queue_number, it configures
1604                   packet  queuing  to  match  the settings configured for the
1605                   Port_Binding    with    options:qdisc_queue_id     matching
1606                   queue_number.  When queue_number is zero, it resets queuing
1607                   to the default strategy.
1608
1609                   Example: set_queue(10);
1610
1611              ct_lb;
1612              ct_lb(backends=ip[:port][,...][;
1613              hash_fields=field1,field2,...][; ct_flag]);
1614                   With  arguments, ct_lb commits the packet to the connection
1615                   tracking table and DNATs the packet’s  destination  IP  ad‐
1616                   dress  (and  port)  to the IP address or addresses (and op‐
1617                   tional ports) specified in the backends. If multiple comma-
1618                   separated  IP  addresses are specified, each is given equal
1619                   weight for picking the DNAT address. By default, dp_hash is
1620                   used  as  the  OpenFlow  group  selection  method,  but  if
1621                   hash_fields is specified, hash is  used  as  the  selection
1622                   method,  and the fields listed are used as the hash fields.
1623                   The  ct_flag  field  represents  one  of  supported   flag:
1624                   skip_snat or force_snat, this flag will be stored in ct_la‐
1625                   bel register.
1626
1627                   Without arguments, ct_lb sends the packet to the connection
1628                   tracking table to NAT the packets. If the packet is part of
1629                   an established connection that was previously committed  to
1630                   the  connection  tracker  via ct_lb(...), it will automati‐
1631                   cally get DNATed to the same IP address as the first packet
1632                   in that connection.
1633
1634                   Processing  automatically moves on to the next table, as if
1635                   next; were specified, and later tables act on the packet as
1636                   modified  by  the  connection  tracker. Connection tracking
1637                   state is scoped by the logical port when the action is used
1638                   in  a  flow  for a logical switch, so overlapping addresses
1639                   may be used. Connection tracking state  is  scoped  by  the
1640                   logical  topology  when  the action is used in a flow for a
1641                   router.
1642
1643              ct_lb_mark;
1644              ct_lb_mark(backends=ip[:port][,...][;
1645              hash_fields=field1,field2,...][; ct_flag]);
1646                   Same  as  ct_lb,  except that it internally uses ct_mark to
1647                   store the NAT flag, while ct_lb uses ct_label for the  same
1648                   purpose.
1649
1650              R = dns_lookup();
1651                   Parameters: No parameters.
1652
1653                   Result: stored to a 1-bit subfield R.
1654
1655                   Valid only in the ingress pipeline.
1656
1657                   When  this  action is applied to a valid DNS request (a UDP
1658                   packet typically directed to port 53), it attempts  to  re‐
1659                   solve  the query using the contents of the DNS table. If it
1660                   is successful, it changes the packet into a DNS  reply  and
1661                   stores  1  in  R.  If  the  action  is applied to a non-DNS
1662                   packet, an invalid DNS request packet, or a valid  DNS  re‐
1663                   quest for which the DNS table does not supply an answer, it
1664                   leaves the packet unchanged and stores 0 in R.
1665
1666                   Regardless of success, the action does not make any of  the
1667                   changes to the flow that are necessary to direct the packet
1668                   back to the requester. The logical pipeline  can  implement
1669                   this behavior with matches and actions in later tables.
1670
1671                   Example: reg0[3] = dns_lookup();
1672
1673                   Prerequisite: udp
1674
1675              R = put_nd_ra_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1676                   Parameters:  The following IPv6 ND Router Advertisement op‐
1677                   tion/value pairs as defined in RFC 4861.
1678
1679addr_mode
1680
1681                          Mandatory parameter which specifies the address mode
1682                          flag  to  be  set  in the RA flag options field. The
1683                          value of this option is a string and  the  following
1684                          values  can  be defined - "slaac", "dhcpv6_stateful"
1685                          and "dhcpv6_stateless".
1686
1687slla
1688
1689                          Mandatory parameter which specifies  the  link-layer
1690                          address  of  the interface from which the Router Ad‐
1691                          vertisement is sent.
1692
1693mtu
1694
1695                          Optional parameter which specifies the MTU.
1696
1697prefix
1698
1699                          Optional parameter which should be specified if  the
1700                          addr_mode  is  "slaac"  or  "dhcpv6_stateless".  The
1701                          value should be an IPv6 prefix which  will  be  used
1702                          for  stateless  IPv6 address configuration. This op‐
1703                          tion can be defined multiple times.
1704
1705                   Result: stored to a 1-bit subfield R.
1706
1707                   Valid only in the ingress pipeline.
1708
1709                   When this action is applied to an IPv6 Router  solicitation
1710                   request  packet,  it changes the packet into an IPv6 Router
1711                   Advertisement reply and adds the options specified  in  the
1712                   parameters, and stores 1 in R.
1713
1714                   When  this action is applied to a non-IPv6 Router solicita‐
1715                   tion packet or an invalid IPv6 request packet ,  it  leaves
1716                   the packet unchanged and stores 0 in R.
1717
1718                   Example: reg0[3] = put_nd_ra_opts(addr_mode = "slaac", slla
1719                   = 00:00:00:00:10:02, prefix = aef0::/64, mtu = 1450);
1720
1721              set_meter(rate);
1722              set_meter(rate, burst);
1723                   Parameters: rate limit int field rate in kbps,  burst  rate
1724                   limits int field burst in kbps.
1725
1726                   This action sets the rate limit for a flow.
1727
1728                   Example: set_meter(100, 1000);
1729
1730              R = check_pkt_larger(L)
1731                   Parameters: packet length L to check for in bytes.
1732
1733                   Result: stored to a 1-bit subfield R.
1734
1735                   This    is   a   logical   equivalent   of   the   OpenFlow
1736                   check_pkt_larger action. If the packet is larger  than  the
1737                   length specified in L, it stores 1 in the subfield R.
1738
1739                   Example: reg0[6] = check_pkt_larger(1000);
1740
1741              log(key=value, ...);
1742                     Causes  ovn-controller  to  log the packet on the chassis
1743                     that processes it. Packet logging currently uses the same
1744                     logging mechanism as other Open vSwitch and OVN messages,
1745                     which means that whether and where  log  messages  appear
1746                     depends  on  the  local logging configuration that can be
1747                     configured with ovs-appctl, etc.
1748
1749                     The log action takes zero or more of the  following  key-
1750                     value pair arguments that control what is logged:
1751
1752                     name=string
1753                            An  optional  name for the ACL. The string is cur‐
1754                            rently limited to 64 bytes.
1755
1756                     severity=level
1757                            Indicates the severity of the event. The level  is
1758                            one  of  following  (from  more  to less serious):
1759                            alert, warning,  notice,  info,  or  debug.  If  a
1760                            severity is not provided, the default is info.
1761
1762                     verdict=value
1763                            The  verdict  for  packets  matching the flow. The
1764                            value must be one of allow, deny, or reject.
1765
1766                     meter=string
1767                            An optional rate-limiting meter to be  applied  to
1768                            the logs. The string should reference a name entry
1769                            from the Meter table. The only meter  action  that
1770                            is appropriate is drop.
1771
1772              fwd_group(liveness=bool, childports=port, ...);
1773                     Parameters:  optional liveness, either true or false, de‐
1774                     faulting to false; childports, a comma-delimited list  of
1775                     strings denoting logical ports to load balance across.
1776
1777                     Load balance traffic to one or more child ports in a log‐
1778                     ical switch. ovn-controller translates the fwd_group into
1779                     an OpenFlow group with one bucket for each child port. If
1780                     liveness=true is specified, it also integrates the bucket
1781                     selection  with BFD status on the tunnel interface corre‐
1782                     sponding to child port.
1783
1784                     Example: fwd_group(liveness=true, childports="p1", "p2");
1785
1786              icmp4 { action; ... };
1787              icmp4_error { action; ... };
1788                   Temporarily replaces the IPv4 packet being processed by  an
1789                   ICMPv4 packet and executes each nested action on the ICMPv4
1790                   packet. Actions following these actions, if any,  apply  to
1791                   the original, unmodified packet.
1792
1793                   The  ICMPv4  packet  that these actions operates on is ini‐
1794                   tialized based on the IPv4 packet being processed, as  fol‐
1795                   lows. These are default values that the nested actions will
1796                   probably want to  change.  Ethernet  and  IPv4  fields  not
1797                   listed here are not changed:
1798
1799ip.proto = 1 (ICMPv4)
1800
1801ip.frag = 0 (not a fragment)
1802
1803ip.ttl = 255
1804
1805icmp4.type = 3 (destination unreachable)
1806
1807icmp4.code = 1 (host unreachable)
1808
1809                   icmp4_error  action  is  expected to be used to generate an
1810                   ICMPv4 packet in  response  to  an  error  in  original  IP
1811                   packet.  When  this  action generates the ICMPv4 packet, it
1812                   also copies the original IP datagram following  the  ICMPv4
1813                   header as per RFC 1122: 3.2.2.
1814
1815                   Prerequisite: ip4
1816
1817              icmp6 { action; ... };
1818              icmp6_error { action; ... };
1819                   Temporarily  replaces the IPv6 packet being processed by an
1820                   ICMPv6 packet and executes each nested action on the ICMPv6
1821                   packet.  Actions  following the icmp6 action, if any, apply
1822                   to the original, unmodified packet.
1823
1824                   The ICMPv6 packet that this action operates on is  initial‐
1825                   ized  based on the IPv6 packet being processed, as follows.
1826                   These are default values that the nested actions will prob‐
1827                   ably  want  to  change. Ethernet and IPv6 fields not listed
1828                   here are not changed:
1829
1830ip.proto = 58 (ICMPv6)
1831
1832ip.ttl = 255
1833
1834icmp6.type = 1 (destination unreachable)
1835
1836icmp6.code = 1 (administratively prohibited)
1837
1838                   icmp6_error action is expected to be used  to  generate  an
1839                   ICMPv6  packet  in  response  to  an error in original IPv6
1840                   packet.
1841
1842                   Prerequisite: ip6
1843
1844              tcp_reset;
1845                   This action transforms the current TCP packet according  to
1846                   the following pseudocode:
1847
1848                   if (tcp.ack) {
1849                           tcp.seq = tcp.ack;
1850                   } else {
1851                           tcp.ack = tcp.seq + length(tcp.payload);
1852                           tcp.seq = 0;
1853                   }
1854                   tcp.flags = RST;
1855
1856                   Then,  the  action  drops all TCP options and payload data,
1857                   and updates the TCP checksum. IP ttl is set to 255.
1858
1859                   Prerequisite: tcp
1860
1861              reject { action; ... };
1862                   If the original packet is IPv4 or IPv6 TCP packet,  it  re‐
1863                   places it with IPv4 or IPv6 TCP RST packet and executes the
1864                   inner actions. Otherwise it replaces it with an  ICMPv4  or
1865                   ICMPv6 packet and executes the inner actions.
1866
1867                   The  inner  actions  should  not attempt to swap eth source
1868                   with eth destination and IP source with IP  destination  as
1869                   this action implicitly does that.
1870
1871              trigger_event;
1872                   This action is used to allow ovs-vswitchd to report CMS re‐
1873                   lated events writing them in Controller_Event table. It  is
1874                   possible  to  associate a meter to a each event in order to
1875                   not overload pinctrl thread under heavy load; each meter is
1876                   identified  though  a  defined naming convention. Supported
1877                   events:
1878
1879empty_lb_backends. This event is  raised  if  a  re‐
1880                          ceived  packet  is  destined for a load balancer VIP
1881                          that has no  configured  backend  destinations.  For
1882                          this  event,  the  event info includes the load bal‐
1883                          ancer VIP, the load balancer UUID, and the transport
1884                          protocol. Associated meter: event-elb
1885
1886              igmp;
1887                   This  action  sends the packet to ovn-controller for multi‐
1888                   cast snooping.
1889
1890                   Prerequisite: igmp
1891
1892              bind_vport(V, P);
1893                   Parameters: logical port string field V  of  type  virtual,
1894                   logical port string field P.
1895
1896                   Binds  the virtual logical port V and sets the chassis col‐
1897                   umn and virtual_parent  of  the  table  Port_Binding.  vir‐
1898                   tual_parent is set to P.
1899
1900              handle_svc_check(P);
1901                   Parameters: logical port string field P.
1902
1903                   Handles  the service monitor reply received from the VIF of
1904                   the logical port P. ovn-controller periodically  sends  out
1905                   the  service monitor packets for the services configured in
1906                   the Service_Monitor table and this action updates the  sta‐
1907                   tus of those services.
1908
1909                   Example: handle_svc_check(inport);
1910
1911              handle_dhcpv6_reply;
1912                   Handle DHCPv6 prefix delegation advertisements/replies from
1913                   a IPv6 delegation server. ovn-controller will add an  entry
1914                   ipv6_ra_pd_list  in  the  options table for each prefix re‐
1915                   ceived from the delegation server
1916
1917              R = select(N1[=W1], N2[=W2], ...);
1918                   Parameters: Integer N1, N2..., with optional weight W1, W2,
1919                   ...
1920
1921                   Result: stored to a logical field or subfield R.
1922
1923                   Select  from  a list of integers N1, N2..., each within the
1924                   range 0 ~ 65535, and store the selected one in the field R.
1925                   There  must  be 2 or more integers listed, each with an op‐
1926                   tional weight, which is an integer within  the  range  1  ~
1927                   65535.  If weight is not specified, it defaults to 100. The
1928                   selection method is based on the  5-tuple  hash  of  packet
1929                   header.
1930
1931                   Processing  automatically moves on to the next table, as if
1932                   next; were specified. The select action must be put as  the
1933                   last action of the logical flow when there are multiple ac‐
1934                   tions (actions put after select will not take effect).
1935
1936                   Example: reg8[16..31] = select(1=20, 2=30, 3=50);
1937
1938              handle_dhcpv6_reply;
1939                   This action is used to parse DHCPv6 replies from IPv6 Dele‐
1940                   gation  Router and managed IPv6 Prefix delegation state ma‐
1941                   chine
1942
1943              R = chk_lb_hairpin();
1944                   This action checks if the packet  under  consideration  was
1945                   destined to a load balancer VIP and it is hairpinned, i.e.,
1946                   after load balancing the destination IP matches the  source
1947                   IP.  If  it is so, then the 1-bit destination register R is
1948                   set to 1.
1949
1950              R = chk_lb_hairpin_reply();
1951                   This action checks if the  packet  under  consideration  is
1952                   from  one  of the backend IP of a load balancer VIP and the
1953                   destination IP is the load balancer VIP. If it is so,  then
1954                   the 1-bit destination register R is set to 1.
1955
1956              R = ct_snat_to_vip;
1957                   This  action  sends  the  packet  through  the SNAT zone to
1958                   change the source IP address of the packet to the load bal‐
1959                   ancer  VIP if the original destination IP was load balancer
1960                   VIP and commits the connection. This  action  applies  suc‐
1961                   cessfully only for the hairpinned traffic i.e if the action
1962                   chk_lb_hairpin returned success. This action  doesn’t  take
1963                   any arguments and it determines the SNAT IP internally. The
1964                   packet is not automatically sent to  the  next  table.  The
1965                   caller  has  to  execute  the next; action explicitly after
1966                   this action to advance the packet to the next stage.
1967
1968              R = check_in_port_sec();
1969                   This action checks if the packet under consideration passes
1970                   the  inport  port  security checks. If the packet fails the
1971                   port security checks, then 1 is stored in  the  destination
1972                   register  R.  Else 0 is stored. The port security values to
1973                   check are retrieved from the the inport logical port.
1974
1975                   This action should be used in the  ingress  logical  switch
1976                   pipeline.
1977
1978                   Example: reg8[0..7] = check_in_port_sec();
1979
1980              R = check_out_port_sec();
1981                   This action checks if the packet under consideration passes
1982                   the outport port security checks. If the packet  fails  the
1983                   port  security  checks, then 1 is stored in the destination
1984                   register R. Else 0 is stored. The port security  values  to
1985                   check are retrieved from the the outport logical port.
1986
1987                   This  action  should  be  used in the egress logical switch
1988                   pipeline.
1989
1990                   Example: reg8[0..7] = check_out_port_sec();
1991
1992              commit_ecmp_nh(ipv6);
1993                   Parameters: IPv4/IPv6 traffic.
1994
1995                   This action translates to an openflow "learn"  action  that
1996                   inserts two new flows in tables 76 and 77.
1997
1998                   •      Match  on  the the 5-tuple and the expected next-hop
1999                          mac address in  table  76:  nw_src=ip0,  nw_dst=ip1,
2000                          ip_proto,tp_src=l4_port0,
2001                          tp_dst=l4_port1,dl_src=ethaddr and set reg9[5].
2002
2003                   •      Match  on  the  5-tuple  in  table  77:  nw_src=ip1,
2004                          nw_dst=ip0,        ip_proto,        tp_src=l4_port1,
2005                          tp_dst=l4_port0 and set reg9[5] to 1
2006
2007                   This action is applied if the packet arrives via ECMP route
2008                   or if it is routed via an ECMP route
2009
2010              R = check_ecmp_nh_mac();
2011                   This  action  checks  if  the  packet  under  consideration
2012                   matches any flow in table 76. If it is so, then  the  1-bit
2013                   destination register R is set to 1.
2014
2015              R = check_ecmp_nh();
2016                   This  action  checks  if  the  packet  under  consideration
2017                   matches the any flow in table 77. If it  is  so,  then  the
2018                   1-bit destination register R is set to 1.
2019
2020                   commit_lb_aff(vip,  backend,  proto,  timeout); Parameters:
2021                   load-balancer virtual ip:port  vip,  load-balancer  backend
2022                   ip:port  backend,  load-balancer  protocol  proto, affinity
2023                   timeout timeout.
2024
2025                   This action translates to an openflow "learn"  action  that
2026                   inserts a new flow in table 78.
2027
2028                   •      Match  on the 4-tuple in table 78: nw_src=ip client,
2029                          nw_dst=vip ip, ip_proto,  tp_dst=vip  port  and  set
2030                          reg9[6]  to  1, reg4 and reg8 to backend ip and port
2031                          respectively. For IPv6 register xxreg1  is  used  to
2032                          store the backend ip.
2033
2034                   This  action  is  applied for new connections received by a
2035                   specific load-balacer with affinity timeout configured.
2036
2037              R = chk_lb_aff();
2038                   This  action  checks  if  the  packet  under  consideration
2039                   matches  any  flow in table 78. If it is so, then the 1-bit
2040                   destination register R is set to 1.
2041
2042              sample(probability=packets, ...)
2043                   This action causes the matched traffic to be sampled  using
2044                   IPFIX  protocol.  More information about how per-flow IPFIX
2045                   sampling works in OVS can be found  in  ovs-actions(7)  and
2046                   ovs-vswitchd.conf.db(5).
2047
2048                   In  order  to reliably identify each sampled packet when it
2049                   is received by the IPFIX collector, this  action  sets  the
2050                   content  of  the ObservationDomainID and ObservationPointID
2051                   IPFIX fields (see argument description below).
2052
2053                   The following key-value arguments are supported:
2054
2055                   probability=packets
2056                          The number of sampled packets out of 65535. It  must
2057                          be greater or equal to 1.
2058
2059                   collector_set=id
2060                          The unsigned 32-bit integer identifier of the sample
2061                          collector to send sampled packets to. It must  match
2062                          the  value  configured  in  the  Flow_Sample_Collec‐
2063                          tor_Set Table in OVS. Defaults to 0.
2064
2065                   obs_domain=id
2066                          An unsigned 8-bit integer that identifies  the  sam‐
2067                          pling  application.  It will be placed in the 8 most
2068                          significant bits of the ObservationDomainID field of
2069                          IPFIX  samples. The 24 less significant bits will be
2070                          automatically filled in with the datapath  key.  De‐
2071                          faults to 0.
2072
2073                   obs_point=id
2074                          An  unsigned  32-bit integer to be used as Obsserva‐
2075                          tionPointID or the string @cookie to  indicate  that
2076                          the  first  32 bits of the Logical_Flow’s UUID shall
2077                          be used instead.
2078
2079              mac_cache_use;
2080                   This action resubmits to corresponding table which  updates
2081                   the use statistics of MAC cache.
2082
2083       tags: map of string-string pairs
2084              Key-value pairs that provide additional information to help ovn-
2085              controller processing the logical flow. Below are the tags  used
2086              by ovn-controller.
2087
2088              in_out_port
2089                     In the logical flow’s "match" column, if a logical port P
2090                     is compared with "inport" and the logical flow  is  on  a
2091                     logical switch ingress pipeline, or if P is compared with
2092                     "outport" and the logical flow is  on  a  logical  switch
2093                     egress  pipeline,  and  the  expression  is combined with
2094                     other expressions (if any) using the  operator  &&,  then
2095                     the  port  P should be added as the value in this tag. If
2096                     there are multiple logical ports meeting  this  criteria,
2097                     one of them can be added. ovn-controller uses this infor‐
2098                     mation to skip parsing flows that are not needed  on  the
2099                     chassis.  Failing  to add the tag will affect efficiency,
2100                     while adding wrong value will affect correctness.
2101
2102       controller_meter: optional string
2103              The name of the meter in table Meter to be used for all  packets
2104              that the logical flow might send to ovn-controller.
2105
2106       external_ids : stage-name: optional string
2107              Human-readable name for this flow’s stage in the pipeline.
2108
2109       external_ids : stage-hint: optional string, containing an uuid
2110              UUID of a OVN_Northbound record that caused this logical flow to
2111              be created. Currently used only for attribute of  logical  flows
2112              to northbound ACL records.
2113
2114       external_ids : source: optional string
2115              Source  file and line number of the code that added this flow to
2116              the pipeline.
2117
2118     Common Columns:
2119
2120       The overall purpose of these columns is described under Common  Columns
2121       at the beginning of this document.
2122
2123       external_ids: map of string-string pairs
2124

Logical_DP_Group TABLE

2126       Each  row  in this table represents a group of logical datapaths refer‐
2127       enced by the logical_dp_group column in the Logical_Flow table.
2128
2129   Summary:
2130       datapaths                     set of weak reference  to  Datapath_Bind‐
2131                                     ings
2132
2133   Details:
2134       datapaths: set of weak reference to Datapath_Bindings
2135              List of Datapath_Binding entries.
2136

Multicast_Group TABLE

2138       The rows in this table define multicast groups of logical ports. Multi‐
2139       cast groups allow a single packet transmitted over a tunnel to a hyper‐
2140       visor  to  be  delivered to multiple VMs on that hypervisor, which uses
2141       bandwidth more efficiently.
2142
2143       Each row in this table defines a logical multicast group numbered  tun‐
2144       nel_key  within  datapath,  whose logical ports are listed in the ports
2145       column.
2146
2147   Summary:
2148       datapath                      Datapath_Binding
2149       tunnel_key                    integer, in range 32,768 to 65,535
2150       name                          string
2151       ports                         set of weak reference to Port_Bindings
2152
2153   Details:
2154       datapath: Datapath_Binding
2155              The logical datapath in which the multicast group resides.
2156
2157       tunnel_key: integer, in range 32,768 to 65,535
2158              The value used to designate this logical egress port  in  tunnel
2159              encapsulations.  An index forces the key to be unique within the
2160              datapath. The unusual range ensures that multicast group IDs  do
2161              not overlap with logical port IDs.
2162
2163       name: string
2164              The  logical multicast group’s name. An index forces the name to
2165              be unique within the datapath.  Logical  flows  in  the  ingress
2166              pipeline  may output to the group just as for individual logical
2167              ports, by assigning the group’s name to outport and executing an
2168              output action.
2169
2170              Multicast  group  names  and  logical  port names share a single
2171              namespace and thus should not overlap (but the  database  schema
2172              cannot enforce this). To try to avoid conflicts, ovn-northd uses
2173              names that begin with _MC_.
2174
2175       ports: set of weak reference to Port_Bindings
2176              The logical ports included in the multicast group. All of  these
2177              ports must be in the datapath logical datapath (but the database
2178              schema cannot enforce this).
2179

Mirror TABLE

2181       Each row in this table represents a mirror that can be  used  for  port
2182       mirroring.  These  mirrors are referenced by the mirror_rules column in
2183       the Port_Binding table.
2184
2185   Summary:
2186       name                          string (must be unique within table)
2187       filter                        string,  one  of  both,  from-lport,   or
2188                                     to-lport
2189       sink                          string
2190       type                          string, one of erspan, gre, or local
2191       index                         integer
2192       external_ids                  map of string-string pairs
2193
2194   Details:
2195       name: string (must be unique within table)
2196              Represents the name of the mirror.
2197
2198       filter: string, one of both, from-lport, or to-lport
2199              The  value  of  this  field represents selection criteria of the
2200              mirror. to-lport mirrors the packets coming into  logical  port.
2201              from-lport  mirrors  the packets going out of logical port. both
2202              mirrors for both directions.
2203
2204       sink: string
2205              The value of this field represents the destination/sink  of  the
2206              mirror.  If  the  type is gre or erspan, the value indicates the
2207              tunnel remote IP (either IPv4 or IPv6). For  a  type  of  local,
2208              this  field  defines  a  local  interface on the OVS integration
2209              bridge to be used as the mirror destination. The interface  must
2210              possess external-ids:mirror-id that matches this string.
2211
2212       type: string, one of erspan, gre, or local
2213              The  value of this field specifies the mirror type - gre, erspan
2214              or local.
2215
2216       index: integer
2217              The value of this field represents the tunnel ID. If the config‐
2218              ured tunnel type is gre, this field represents the GRE key value
2219              and if the configured tunnel type is erspan  it  represents  the
2220              erspan_idx value. It is ignored if the type is local.
2221
2222       external_ids: map of string-string pairs
2223              See External IDs at the beginning of this document.
2224

Meter TABLE

2226       Each  row  in this table represents a meter that can be used for QoS or
2227       rate-limiting.
2228
2229   Summary:
2230       name                          string (must be unique within table)
2231       unit                          string, either kbps or pktps
2232       bands                         set of 1 or more Meter_Bands
2233
2234   Details:
2235       name: string (must be unique within table)
2236              A name for this meter.
2237
2238              Names that begin with "__" (two underscores)  are  reserved  for
2239              OVN internal use and should not be added manually.
2240
2241       unit: string, either kbps or pktps
2242              The  unit for rate and burst_rate parameters in the bands entry.
2243              kbps specifies kilobits per second, and pktps specifies  packets
2244              per second.
2245
2246       bands: set of 1 or more Meter_Bands
2247              The bands associated with this meter. Each band specifies a rate
2248              above which the band is to take the action action.  If  multiple
2249              bands’  rates  are exceeded, then the band with the highest rate
2250              among the exceeded bands is selected.
2251

Meter_Band TABLE

2253       Each row in this table represents a meter band which specifies the rate
2254       above  which  the  configured action should be applied. These bands are
2255       referenced by the bands column in the Meter table.
2256
2257   Summary:
2258       action                        string, must be drop
2259       rate                          integer, in range 1 to 4,294,967,295
2260       burst_size                    integer, in range 0 to 4,294,967,295
2261
2262   Details:
2263       action: string, must be drop
2264              The action to execute when this band matches. The only supported
2265              action is drop.
2266
2267       rate: integer, in range 1 to 4,294,967,295
2268              The rate limit for this band, in kilobits per second or bits per
2269              second, depending on whether the parent Meter entry’s unit  col‐
2270              umn specified kbps or pktps.
2271
2272       burst_size: integer, in range 0 to 4,294,967,295
2273              The  maximum  burst allowed for the band in kilobits or packets,
2274              depending on whether kbps or pktps was selected  in  the  parent
2275              Meter  entry’s  unit  column. If the size is zero, the switch is
2276              free to select some reasonable value depending on its configura‐
2277              tion.
2278

Datapath_Binding TABLE

2280       Each  row in this table represents a logical datapath, which implements
2281       a logical pipeline among the ports in the Port_Binding table associated
2282       with  it.  In practice, the pipeline in a given logical datapath imple‐
2283       ments either a logical switch or a logical router.
2284
2285       The main purpose of a row in this table is provide a  physical  binding
2286       for a logical datapath. A logical datapath does not have a physical lo‐
2287       cation, so its physical  binding  information  is  limited:  just  tun‐
2288       nel_key. The rest of the data in this table does not affect packet for‐
2289       warding.
2290
2291   Summary:
2292       tunnel_key                    integer, in range 1 to  16,777,215  (must
2293                                     be unique within table)
2294       load_balancers                set of uuids
2295       OVN_Northbound Relationship:
2296         external_ids : logical-switch
2297                                     optional string, containing an uuid
2298         external_ids : logical-router
2299                                     optional string, containing an uuid
2300         external_ids : interconn-ts
2301                                     optional string
2302         Naming:
2303            external_ids : name      optional string
2304            external_ids : name2     optional string
2305       Common Columns:
2306         external_ids                map of string-string pairs
2307
2308   Details:
2309       tunnel_key:  integer,  in  range 1 to 16,777,215 (must be unique within
2310       table)
2311              The tunnel key value to which the logical datapath is bound. The
2312              Tunnel  Encapsulation  section  in ovn-architecture(7) describes
2313              how tunnel keys are constructed for  each  supported  encapsula‐
2314              tion.
2315
2316       load_balancers: set of uuids
2317              Not  used  anymore;  kept  for  backwards  compatibility  of the
2318              schema.
2319
2320     OVN_Northbound Relationship:
2321
2322       Each row in Datapath_Binding is associated with some logical  datapath.
2323       ovn-northd  uses these keys to track the association of a logical data‐
2324       path with concepts in the OVN_Northbound database.
2325
2326       external_ids : logical-switch: optional string, containing an uuid
2327              For  a  logical  datapath  that  represents  a  logical  switch,
2328              ovn-northd stores in this key the UUID of the corresponding Log‐
2329              ical_Switch row in the OVN_Northbound database.
2330
2331       external_ids : logical-router: optional string, containing an uuid
2332              For  a  logical  datapath  that  represents  a  logical  router,
2333              ovn-northd stores in this key the UUID of the corresponding Log‐
2334              ical_Router row in the OVN_Northbound database.
2335
2336       external_ids : interconn-ts: optional string
2337              For a logical datapath that represents  a  logical  switch  that
2338              represents  a  transit  switch  for  interconnection, ovn-northd
2339              stores in this key the value of the same interconn-ts key of the
2340              external_ids  column  of the corresponding Logical_Switch row in
2341              the OVN_Northbound database.
2342
2343     Naming:
2344
2345       ovn-northd copies these from the  name  fields  in  the  OVN_Northbound
2346       database,  either from name and external_ids:neutron:router_name in the
2347       Logical_Router table or from name and external_ids:neutron:network_name
2348       in the Logical_Switch table.
2349
2350       external_ids : name: optional string
2351              A name for the logical datapath.
2352
2353       external_ids : name2: optional string
2354              Another name for the logical datapath.
2355
2356     Common Columns:
2357
2358       The  overall purpose of these columns is described under Common Columns
2359       at the beginning of this document.
2360
2361       external_ids: map of string-string pairs
2362

Port_Binding TABLE

2364       Each row in this table binds a logical port to a realization. For  most
2365       logical  ports, this means binding to some physical location, for exam‐
2366       ple by binding a logical port to a VIF that belongs to a VM running  on
2367       a  particular  hypervisor.  Other  logical ports, such as logical patch
2368       ports, can be realized without a specific physical location, but  their
2369       bindings are still expressed through rows in this table.
2370
2371       For   every  Logical_Switch_Port  record  in  OVN_Northbound  database,
2372       ovn-northd creates a record in this  table.  ovn-northd  populates  and
2373       maintains  every  column except the chassis and virtual_parent columns,
2374       which it leaves empty in new records.
2375
2376       ovn-controller/ovn-controller-vtep populates the chassis column for the
2377       records  that identify the logical ports that are located on its hyper‐
2378       visor/gateway, which ovn-controller/ovn-controller-vtep in  turn  finds
2379       out  by  monitoring the local hypervisor’s Open_vSwitch database, which
2380       identifies logical ports via  the  conventions  described  in  Integra‐
2381       tionGuide.rst.  (The  exceptions are for Port_Binding records with type
2382       of l3gateway, whose locations are identified by ovn-northd via the  op‐
2383       tions:l3gateway-chassis  column  in this table. ovn-controller is still
2384       responsible to populate the chassis column.)
2385
2386       ovn-controller also populates  the  virtual_parent  column  of  records
2387       whose type is virtual.
2388
2389       When  a  chassis  shuts down gracefully, it should clean up the chassis
2390       column that it previously had populated. (This is not critical  because
2391       resources  hosted  on the chassis are equally unreachable regardless of
2392       whether their rows are present.) To handle the case where a VM is  shut
2393       down abruptly on one chassis, then brought up again on a different one,
2394       ovn-controller/ovn-controller-vtep must overwrite  the  chassis  column
2395       with new information.
2396
2397   Summary:
2398       Core Features:
2399         datapath                    Datapath_Binding
2400         logical_port                string (must be unique within table)
2401         encap                       optional weak reference to Encap
2402         additional_encap            set of weak reference to Encaps
2403         chassis                     optional weak reference to Chassis
2404         additional_chassis          set of weak reference to Chassis
2405         gateway_chassis             set of Gateway_Chassises
2406         ha_chassis_group            optional HA_Chassis_Group
2407         up                          optional boolean
2408         tunnel_key                  integer, in range 1 to 32,767
2409         mac                         set of strings
2410         port_security               set of strings
2411         type                        string
2412         requested_chassis           optional weak reference to Chassis
2413         requested_additional_chassis
2414                                     set of weak reference to Chassis
2415       mirror_rules                  set of weak reference to Mirrors
2416       Patch Options:
2417         options : peer              optional string
2418         nat_addresses               set of strings
2419       L3 Gateway Options:
2420         options : peer              optional string
2421         options : l3gateway-chassis
2422                                     optional string
2423         nat_addresses               set of strings
2424       Localnet Options:
2425         options : network_name      optional string
2426         tag                         optional integer, in range 1 to 4,095
2427       L2 Gateway Options:
2428         options : network_name      optional string
2429         options : l2gateway-chassis
2430                                     optional string
2431         tag                         optional integer, in range 1 to 4,095
2432       VTEP Options:
2433         options : vtep-physical-switch
2434                                     optional string
2435         options : vtep-logical-switch
2436                                     optional string
2437       VMI (or VIF) Options:
2438         options : requested-chassis
2439                                     optional string
2440         options : activation-strategy
2441                                     optional string
2442         options : additional-chassis-activated
2443                                     optional string
2444         options : iface-id-ver      optional string
2445         options : qos_min_rate      optional string
2446         options : qos_max_rate      optional string
2447         options : qos_burst         optional string
2448         options : qos_physical_network
2449                                     optional string
2450         options : qdisc_queue_id    optional  string,  containing an integer,
2451                                     in range 1 to 61,440
2452       Distributed Gateway Port Options:
2453         options : chassis-redirect-port
2454                                     optional string
2455       Chassis Redirect Options:
2456         options : distributed-port  optional string
2457         options : redirect-type     optional string
2458         options : always-redirect   optional string
2459       Nested Containers:
2460         parent_port                 optional string
2461         tag                         optional integer, in range 1 to 4,095
2462       Virtual ports:
2463         virtual_parent              optional string
2464       Naming:
2465         external_ids : name         optional string
2466       Common Columns:
2467         external_ids                map of string-string pairs
2468
2469   Details:
2470     Core Features:
2471
2472       datapath: Datapath_Binding
2473              The logical datapath to which the logical port belongs.
2474
2475       logical_port: string (must be unique within table)
2476              A logical port. For a logical switch port, this  is  taken  from
2477              name in the OVN_Northbound database’s Logical_Switch_Port table.
2478              For a logical router port,  this  is  taken  from  name  in  the
2479              OVN_Northbound database’s Logical_Router_port table. (This means
2480              that logical switch ports and router port names must  not  share
2481              names in an OVN deployment.) OVN does not prescribe a particular
2482              format for the logical port ID.
2483
2484       encap: optional weak reference to Encap
2485              Points to preferred encapsulation configuration to transmit log‐
2486              ical  dataplane  packets to this chassis. The entry is reference
2487              to a Encap record.
2488
2489       additional_encap: set of weak reference to Encaps
2490              Points to preferred encapsulation configuration to transmit log‐
2491              ical  dataplane packets to this additional chassis. The entry is
2492              reference to a Encap record. See also additional_chassis.
2493
2494       chassis: optional weak reference to Chassis
2495              The meaning of this column depends on the value of the type col‐
2496              umn. This is the meaning for each type
2497
2498              (empty string)
2499                     The  physical  location  of the logical port. To success‐
2500                     fully identify a chassis, this column must be  a  Chassis
2501                     record. This is populated by ovn-controller.
2502
2503              vtep   The  physical  location  of the hardware_vtep gateway. To
2504                     successfully identify a chassis, this column  must  be  a
2505                     Chassis record. This is populated by ovn-controller-vtep.
2506
2507              localnet
2508                     Always  empty. A localnet port is realized on every chas‐
2509                     sis that has connectivity to the  corresponding  physical
2510                     network.
2511
2512              localport
2513                     Always  empty. A localport port is present on every chas‐
2514                     sis.
2515
2516              l3gateway
2517                     The physical location of the L3 gateway. To  successfully
2518                     identify a chassis, this column must be a Chassis record.
2519                     This is populated by ovn-controller based on the value of
2520                     the options:l3gateway-chassis column in this table.
2521
2522              l2gateway
2523                     The physical location of this L2 gateway. To successfully
2524                     identify a chassis, this column must be a Chassis record.
2525                     This is populated by ovn-controller based on the value of
2526                     the options:l2gateway-chassis column in this table.
2527
2528       additional_chassis: set of weak reference to Chassis
2529              The meaning of this column is the same as for the  chassis.  The
2530              column  is  used to track an additional physical location of the
2531              logical port. Used with regular (empty type) port bindings.
2532
2533       gateway_chassis: set of Gateway_Chassises
2534              A list of Gateway_Chassis.
2535
2536              This should only be populated for ports with type set  to  chas‐
2537              sisredirect.  This  column  defines  the list of chassis used as
2538              gateways where traffic will be redirected through.
2539
2540       ha_chassis_group: optional HA_Chassis_Group
2541              This should only be populated for ports with type set  to  chas‐
2542              sisredirect.  This  column  defines  the HA chassis group with a
2543              list of HA chassis used as gateways where traffic will be  redi‐
2544              rected through.
2545
2546       up: optional boolean
2547              This  is  set  to  true  whenever all OVS flows required by this
2548              Port_Binding have been installed. This is populated by  ovn-con‐
2549              troller.
2550
2551       tunnel_key: integer, in range 1 to 32,767
2552              A  number  that represents the logical port in the key (e.g. STT
2553              key or Geneve TLV) field carried within tunnel protocol packets.
2554
2555              The tunnel ID must be unique within the scope of a logical data‐
2556              path.
2557
2558       mac: set of strings
2559              This column is a misnomer as it may contain MAC addresses and IP
2560              addresses. It is copied from the addresses column in  the  Logi‐
2561              cal_Switch_Port table in the Northbound database. It follows the
2562              same format as that column.
2563
2564       port_security: set of strings
2565              This column controls the addresses from which the host  attached
2566              to  the  logical  port (``the host’’) is allowed to send packets
2567              and to which it is allowed to receive packets. If this column is
2568              empty, all addresses are permitted.
2569
2570              It  is  copied  from  the  port_security  column  in  the  Logi‐
2571              cal_Switch_Port table in the Northbound database. It follows the
2572              same format as that column.
2573
2574       type: string
2575              A type for this logical port. Logical ports can be used to model
2576              other types of connectivity into an OVN logical switch. The fol‐
2577              lowing types are defined:
2578
2579              (empty string)
2580                     VM (or VIF) interface.
2581
2582              patch  One  of  a pair of logical ports that act as if connected
2583                     by a patch cable. Useful for connecting two logical data‐
2584                     paths,  e.g.  to  connect  a  logical router to a logical
2585                     switch or to another logical router.
2586
2587              l3gateway
2588                     One of a pair of logical ports that act as  if  connected
2589                     by a patch cable across multiple chassis. Useful for con‐
2590                     necting a logical switch with a Gateway router (which  is
2591                     only resident on a particular chassis).
2592
2593              localnet
2594                     A   connection  to  a  locally  accessible  network  from
2595                     ovn-controller instances that have a corresponding bridge
2596                     mapping.  A  logical  switch  can  have multiple localnet
2597                     ports attached. This type is used to model direct connec‐
2598                     tivity  to  existing networks. In this case, each chassis
2599                     should have a mapping for one of  the  physical  networks
2600                     only.  Note:  nothing  said  above implies that a chassis
2601                     cannot be plugged to multiple physical networks  as  long
2602                     as they belong to different switches.
2603
2604              localport
2605                     A  connection  to  a local VIF. Traffic that arrives on a
2606                     localport is never forwarded over  a  tunnel  to  another
2607                     chassis.  These  ports  are  present on every chassis and
2608                     have the same address in all of them.  This  is  used  to
2609                     model  connectivity  to  local services that run on every
2610                     hypervisor.
2611
2612              l2gateway
2613                     An L2 connection to a physical network. The chassis  this
2614                     Port_Binding  is  bound to will serve as an L2 gateway to
2615                     the network named by options:network_name.
2616
2617              vtep   A port to a logical switch on a VTEP gateway chassis.  In
2618                     order  to  get  this port correctly recognized by the OVN
2619                     controller,  the  options:vtep-physical-switch  and   op‐
2620                     tions:vtep-logical-switch must also be defined.
2621
2622              chassisredirect
2623                     A  logical  port  that  represents a particular instance,
2624                     bound to a specific chassis, of an otherwise  distributed
2625                     parent  port (e.g. of type patch). A chassisredirect port
2626                     should never be used as an inport. When an ingress  pipe‐
2627                     line  sets the outport, it may set the value to a logical
2628                     port of type chassisredirect. This will cause the  packet
2629                     to  be  directed  to  a specific chassis to carry out the
2630                     egress pipeline. At the beginning of the egress pipeline,
2631                     the outport will be reset to the value of the distributed
2632                     port.
2633
2634              virtual
2635                     Represents a logical port with an virtual ip.  This  vir‐
2636                     tual ip can be configured on a logical port (which is re‐
2637                     ferred as virtual parent).
2638
2639       requested_chassis: optional weak reference to Chassis
2640              This column exists so that the  ovn-controller  can  effectively
2641              monitor  all Port_Binding records destined for it, and is a sup‐
2642              plement to the options:requested-chassis option. The  option  is
2643              still  required so that the ovn-controller can check the CMS in‐
2644              tent when the chassis pointed to does not currently exist, which
2645              for  example  occurs  when the ovn-controller is stopped without
2646              passing the -restart argument. This column  must  be  a  Chassis
2647              record.  This  is  populated  by ovn-northd when the options:re‐
2648              quested-chassis is defined and contains a  string  matching  the
2649              name  or hostname of an existing chassis. See also requested_ad‐
2650              ditional_chassis.
2651
2652       requested_additional_chassis: set of weak reference to Chassis
2653              This column exists so that the  ovn-controller  can  effectively
2654              monitor  all Port_Binding records destined for it, and is a sup‐
2655              plement to the options:requested-chassis  option  when  multiple
2656              chassis  are  listed.  This  column  must  be  a list of Chassis
2657              records. This is populated by ovn-northd  when  the  options:re‐
2658              quested-chassis  is  defined as a list of chassis names or host‐
2659              names. See also requested_chassis.
2660
2661       mirror_rules: set of weak reference to Mirrors
2662              Mirror rules that apply to the port binding. Please see the Mir‐
2663              ror table.
2664
2665     Patch Options:
2666
2667       These options apply to logical ports with type of patch.
2668
2669       options : peer: optional string
2670              The  logical_port  in the Port_Binding record for the other side
2671              of the patch. The named logical_port  must  specify  this  logi‐
2672              cal_port  in its own peer option. That is, the two patch logical
2673              ports must have reversed logical_port and peer values.
2674
2675       nat_addresses: set of strings
2676              MAC address followed by a list of SNAT and DNAT external IP  ad‐
2677              dresses,  followed  by is_chassis_resident("lport"), where lport
2678              is the name of a logical port on the same chassis where the cor‐
2679              responding  NAT  rules  are applied. This is used to send gratu‐
2680              itous ARPs for SNAT and DNAT external IP addresses via localnet,
2681              from the chassis where lport resides. Example: 80:fa:5b:06:72:b7
2682              158.36.44.22  158.36.44.24   is_chassis_resident("foo1").   This
2683              would  result  in generation of gratuitous ARPs for IP addresses
2684              158.36.44.22  and   158.36.44.24   with   a   MAC   address   of
2685              80:fa:5b:06:72:b7 from the chassis where the logical port "foo1"
2686              resides.
2687
2688     L3 Gateway Options:
2689
2690       These options apply to logical ports with type of l3gateway.
2691
2692       options : peer: optional string
2693              The logical_port in the Port_Binding record for the  other  side
2694              of  the  ’l3gateway’  port.  The named logical_port must specify
2695              this logical_port in its own  peer  option.  That  is,  the  two
2696              ’l3gateway’  logical  ports  must have reversed logical_port and
2697              peer values.
2698
2699       options : l3gateway-chassis: optional string
2700              The chassis in which the port resides.
2701
2702       nat_addresses: set of strings
2703              MAC address of the l3gateway port followed by a list of SNAT and
2704              DNAT external IP addresses. This is used to send gratuitous ARPs
2705              for SNAT and DNAT external IP addresses via  localnet.  Example:
2706              80:fa:5b:06:72:b7  158.36.44.22  158.36.44.24. This would result
2707              in generation of gratuitous ARPs for IP  addresses  158.36.44.22
2708              and  158.36.44.24  with a MAC address of 80:fa:5b:06:72:b7. This
2709              is used in OVS version 2.8 and later versions.
2710
2711     Localnet Options:
2712
2713       These options apply to logical ports with type of localnet.
2714
2715       options : network_name: optional string
2716              Required.   ovn-controller   uses   the   configuration    entry
2717              ovn-bridge-mappings to determine how to connect to this network.
2718              ovn-bridge-mappings is a list of network names mapped to a local
2719              OVS  bridge  that provides access to that network. An example of
2720              configuring ovn-bridge-mappings would be: .IP
2721              $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
2722
2723              When a logical switch has a localnet port attached, every  chas‐
2724              sis  that  may  have a local vif attached to that logical switch
2725              must have a bridge mapping configured to  reach  that  localnet.
2726              Traffic  that arrives on a localnet port is never forwarded over
2727              a tunnel to another chassis.  If  there  are  multiple  localnet
2728              ports  in a logical switch, each chassis should only have a sin‐
2729              gle bridge mapping for one of the physical  networks.  Note:  In
2730              case  of  multiple  localnet ports, to provide interconnectivity
2731              between all VIFs located on  different  chassis  with  different
2732              fabric  connectivity,  the  fabric should implement some form of
2733              routing between the segments.
2734
2735       tag: optional integer, in range 1 to 4,095
2736              If set, indicates that the port represents  a  connection  to  a
2737              specific  VLAN  on  a locally accessible network. The VLAN ID is
2738              used to match incoming traffic and is  also  added  to  outgoing
2739              traffic.
2740
2741     L2 Gateway Options:
2742
2743       These options apply to logical ports with type of l2gateway.
2744
2745       options : network_name: optional string
2746              Required.    ovn-controller   uses   the   configuration   entry
2747              ovn-bridge-mappings to determine how to connect to this network.
2748              ovn-bridge-mappings is a list of network names mapped to a local
2749              OVS bridge that provides access to that network. An  example  of
2750              configuring ovn-bridge-mappings would be: .IP
2751              $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
2752
2753              When a logical switch has a l2gateway port attached, the chassis
2754              that the l2gateway port is bound to must have a  bridge  mapping
2755              configured to reach the network identified by network_name.
2756
2757       options : l2gateway-chassis: optional string
2758              Required. The chassis in which the port resides.
2759
2760       tag: optional integer, in range 1 to 4,095
2761              If  set,  indicates  that the gateway is connected to a specific
2762              VLAN on the physical network. The VLAN ID is used to  match  in‐
2763              coming traffic and is also added to outgoing traffic.
2764
2765     VTEP Options:
2766
2767       These options apply to logical ports with type of vtep.
2768
2769       options : vtep-physical-switch: optional string
2770              Required. The name of the VTEP gateway.
2771
2772       options : vtep-logical-switch: optional string
2773              Required.  A  logical switch name connected by the VTEP gateway.
2774              Must be set when type is vtep.
2775
2776     VMI (or VIF) Options:
2777
2778       These options apply to logical ports with type having (empty string)
2779
2780       options : requested-chassis: optional string
2781              If set, identifies a specific chassis (by name or hostname) that
2782              is  allowed  to  bind  this port. Using this option will prevent
2783              thrashing between two chassis trying to bind the same port  dur‐
2784              ing  a live migration. It can also prevent similar thrashing due
2785              to a mis-configuration, if a port  is  accidentally  created  on
2786              more than one chassis.
2787
2788              If set to a comma separated list, the first entry identifies the
2789              main chassis and the rest are one  or  more  additional  chassis
2790              that are allowed to bind the same port.
2791
2792              When  multiple  chassis  are  set  for the port, and the logical
2793              switch is connected to an external network  through  a  localnet
2794              port,  tunneling  is enforced for the port to guarantee delivery
2795              of packets directed to the port to all its locations.  This  has
2796              MTU  implications  because  the  network used for tunneling must
2797              have MTU larger than localnet for stable connectivity.
2798
2799       options : activation-strategy: optional string
2800              If used with multiple chassis set in  requested-chassis,  speci‐
2801              fies  an  activation strategy for all additional chassis. By de‐
2802              fault, no activation strategy is used, meaning  additional  port
2803              locations are immediately available for use. When set to "rarp",
2804              the port is blocked for ingress and egress communication until a
2805              RARP  packet is sent from a new location. The "rarp" strategy is
2806              useful in live migration scenarios for virtual machines.
2807
2808       options : additional-chassis-activated: optional string
2809              When activation-strategy is set, this option indicates that  the
2810              port was activated using the strategy specified.
2811
2812       options : iface-id-ver: optional string
2813              If  set,  this port will be bound by ovn-controller only if this
2814              same key and value is configured in the external_ids  column  in
2815              the Open_vSwitch database’s Interface table.
2816
2817       options : qos_min_rate: optional string
2818              If set, indicates the minimum guaranteed rate available for data
2819              sent from this interface, in bit/s.
2820
2821       options : qos_max_rate: optional string
2822              If set, indicates the maximum rate for data sent from  this  in‐
2823              terface,  in bit/s. The traffic will be shaped according to this
2824              limit.
2825
2826       options : qos_burst: optional string
2827              If set, indicates the maximum burst size for data sent from this
2828              interface, in bits.
2829
2830       options : qos_physical_network: optional string
2831              If  set,  indicates  the  name  of the egress network name where
2832              traffic shaping will be applied.
2833
2834       options : qdisc_queue_id: optional string, containing  an  integer,  in
2835       range 1 to 61,440
2836              Indicates  the queue number on the physical device. This is same
2837              as the queue_id used in OpenFlow in struct ofp_action_enqueue.
2838
2839     Distributed Gateway Port Options:
2840
2841       These options apply to the distributed parent ports  of  logical  ports
2842       with type of chasssisredirect.
2843
2844       options : chassis-redirect-port: optional string
2845              The  name of the chassis redirect port derived from this port if
2846              this port is a distributed parent of a chassis redirect port.
2847
2848     Chassis Redirect Options:
2849
2850       These options apply to logical ports with type of chassisredirect.
2851
2852       options : distributed-port: optional string
2853              The name of the distributed port for which this  chassisredirect
2854              port represents a particular instance.
2855
2856       options : redirect-type: optional string
2857              The  value  is  copied from the column options in the OVN_North‐
2858              bound database’s Logical_Router_Port table for  the  distributed
2859              parent of this port.
2860
2861       options : always-redirect: optional string
2862              A  boolean  option that is set to true if the distributed parent
2863              of this chassis redirect port does not need distributed process‐
2864              ing.
2865
2866     Nested Containers:
2867
2868       These columns support containers nested within a VM. Specifically, they
2869       are used when type is empty and logical_port identifies  the  interface
2870       of  a  container  spawned inside a VM. They are empty for containers or
2871       VMs that run directly on a hypervisor.
2872
2873       parent_port: optional string
2874              This is taken from parent_name in the OVN_Northbound  database’s
2875              Logical_Switch_Port table.
2876
2877       tag: optional integer, in range 1 to 4,095
2878              Identifies  the  VLAN tag in the network traffic associated with
2879              that container’s network interface.
2880
2881              This column is used for a different purpose when type is  local‐
2882              net  (see  Localnet Options, above) or l2gateway (see L2 Gateway
2883              Options, above).
2884
2885     Virtual ports:
2886
2887       virtual_parent: optional string
2888              This column is set by ovn-controller with one of the value  from
2889              the  options:virtual-parents  in  the  OVN_Northbound database’s
2890              Logical_Switch_Port table when the OVN action bind_vport is exe‐
2891              cuted.  ovn-controller also sets the chassis column when it exe‐
2892              cutes this action with its chassis id.
2893
2894              ovn-controller sets this column only if the type is "virtual".
2895
2896     Naming:
2897
2898       external_ids : name: optional string
2899              For a logical switch port, ovn-northd copies  this  from  exter‐
2900              nal_ids:neutron:port_name  in  the  Logical_Switch_Port table in
2901              the OVN_Northbound database, if it is a nonempty string.
2902
2903              For a logical switch port, ovn-northd  does  not  currently  set
2904              this key.
2905
2906     Common Columns:
2907
2908       external_ids: map of string-string pairs
2909              See External IDs at the beginning of this document.
2910
2911              The  ovn-northd  program  populates this column with all entries
2912              into the external_ids column of the Logical_Switch_Port and Log‐
2913              ical_Router_Port tables of the OVN_Northbound database.
2914

MAC_Binding TABLE

2916       Each  row  in  this  table specifies a binding from an IP address to an
2917       Ethernet address that has been discovered through  ARP  (for  IPv4)  or
2918       neighbor discovery (for IPv6). This table is primarily used to discover
2919       bindings on physical networks, because IP-to-MAC bindings  for  virtual
2920       machines are usually populated statically into the Port_Binding table.
2921
2922       This  table  expresses  a  functional  relationship:  MAC_Binding(logi‐
2923       cal_port, ip) = mac.
2924
2925       In outline, the lifetime of a logical router’s MAC binding  looks  like
2926       this:
2927
2928              1.  On  hypervisor  1, a logical router determines that a packet
2929                  should be forwarded to IP address A on  one  of  its  router
2930                  ports.  It  uses  its logical flow table to determine that A
2931                  lacks a static IP-to-MAC binding and the get_arp  action  to
2932                  determine that it lacks a dynamic IP-to-MAC binding.
2933
2934              2.  Using  an  OVN logical arp action, the logical router gener‐
2935                  ates and sends a broadcast ARP request to the  router  port.
2936                  It drops the IP packet.
2937
2938              3.  The  logical switch attached to the router port delivers the
2939                  ARP request to all of its ports. (It might make sense to de‐
2940                  liver  it  only to ports that have no static IP-to-MAC bind‐
2941                  ings, but this could also be surprising behavior.)
2942
2943              4.  A host or VM on hypervisor 2 (which might be the same as hy‐
2944                  pervisor  1)  attached to the logical switch owns the IP ad‐
2945                  dress in question. It composes an ARP reply and unicasts  it
2946                  to the logical router port’s Ethernet address.
2947
2948              5.  The  logical  switch  delivers  the ARP reply to the logical
2949                  router port.
2950
2951              6.  The logical router flow table executes a put_arp action.  To
2952                  record  the  IP-to-MAC binding, ovn-controller adds a row to
2953                  the MAC_Binding table.
2954
2955              7.  On  hypervisor  1,  ovn-controller  receives   the   updated
2956                  MAC_Binding table from the OVN southbound database. The next
2957                  packet destined to A through the logical router is sent  di‐
2958                  rectly to the bound Ethernet address.
2959
2960   Summary:
2961       logical_port                  string
2962       ip                            string
2963       mac                           string
2964       timestamp                     integer
2965       datapath                      Datapath_Binding
2966
2967   Details:
2968       logical_port: string
2969              The logical port on which the binding was discovered.
2970
2971       ip: string
2972              The bound IP address.
2973
2974       mac: string
2975              The Ethernet address to which the IP is bound.
2976
2977       timestamp: integer
2978              The timestamp in msec when the MAC binding was added or updated.
2979              Records that existed before this column will have 0.
2980
2981       datapath: Datapath_Binding
2982              The logical datapath to which the logical port belongs.
2983

DHCP_Options TABLE

2985       Each row in this table stores the DHCP Options supported by native  OVN
2986       DHCP.  ovn-northd populates this table with the supported DHCP options.
2987       ovn-controller looks up this table to get the DHCP codes  of  the  DHCP
2988       options  defined in the "put_dhcp_opts" action. Please refer to the RFC
2989       2132 "https://tools.ietf.org/html/rfc2132" for  the  possible  list  of
2990       DHCP options that can be defined here.
2991
2992   Summary:
2993       name                          string
2994       code                          integer, in range 0 to 254
2995       type                          string,  one  of  bool, domains, host_id,
2996                                     ipv4, static_routes, str, uint16, uint32,
2997                                     or uint8
2998
2999   Details:
3000       name: string
3001              Name of the DHCP option.
3002
3003              Example. name="router"
3004
3005       code: integer, in range 0 to 254
3006              DHCP option code for the DHCP option as defined in the RFC 2132.
3007
3008              Example. code=3
3009
3010       type:  string, one of bool, domains, host_id, ipv4, static_routes, str,
3011       uint16, uint32, or uint8
3012              Data type of the DHCP option code.
3013
3014              value: bool
3015                     This indicates that the value of the  DHCP  option  is  a
3016                     bool.
3017
3018                     Example.       "name=ip_forward_enable",       "code=19",
3019                     "type=bool".
3020
3021                     put_dhcp_opts(..., ip_forward_enable = 1,...)
3022
3023              value: uint8
3024                     This indicates that the value of the DHCP  option  is  an
3025                     unsigned int8 (8 bits)
3026
3027                     Example. "name=default_ttl", "code=23", "type=uint8".
3028
3029                     put_dhcp_opts(..., default_ttl = 50,...)
3030
3031              value: uint16
3032                     This  indicates  that  the value of the DHCP option is an
3033                     unsigned int16 (16 bits).
3034
3035                     Example. "name=mtu", "code=26", "type=uint16".
3036
3037                     put_dhcp_opts(..., mtu = 1450,...)
3038
3039              value: uint32
3040                     This indicates that the value of the DHCP  option  is  an
3041                     unsigned int32 (32 bits).
3042
3043                     Example. "name=lease_time", "code=51", "type=uint32".
3044
3045                     put_dhcp_opts(..., lease_time = 86400,...)
3046
3047              value: ipv4
3048                     This  indicates  that  the value of the DHCP option is an
3049                     IPv4 address or addresses.
3050
3051                     Example. "name=router", "code=3", "type=ipv4".
3052
3053                     put_dhcp_opts(..., router = 10.0.0.1,...)
3054
3055                     Example. "name=dns_server", "code=6", "type=ipv4".
3056
3057                     put_dhcp_opts(..., dns_server = {8.8.8.8 7.7.7.7},...)
3058
3059              value: static_routes
3060                     This indicates that the value of the DHCP option contains
3061                     a pair of IPv4 route and next hop addresses.
3062
3063                     Example.    "name=classless_static_route",    "code=121",
3064                     "type=static_routes".
3065
3066                     put_dhcp_opts(...,        classless_static_route        =
3067                     {30.0.0.0/24,10.0.0.4,0.0.0.0/0,10.0.0.1}...)
3068
3069              value: str
3070                     This  indicates  that  the  value of the DHCP option is a
3071                     string.
3072
3073                     Example. "name=host_name", "code=12", "type=str".
3074
3075              value: host_id
3076                     This indicates that the value of the  DHCP  option  is  a
3077                     host_id. It can either be a host_name or an IP address.
3078
3079                     Example. "name=tftp_server", "code=66", "type=host_id".
3080
3081              value: domains
3082                     This indicates that the value of the DHCP option is a do‐
3083                     main name or a comma separated list of domain names.
3084
3085                     Example. "name=domain_search_list", "code=119", "type=do‐
3086                     mains".
3087

DHCPv6_Options TABLE

3089       Each  row  in  this table stores the DHCPv6 Options supported by native
3090       OVN DHCPv6. ovn-northd populates this table with the  supported  DHCPv6
3091       options.  ovn-controller looks up this table to get the DHCPv6 codes of
3092       the DHCPv6 options defined in the put_dhcpv6_opts action. Please  refer
3093       to RFC 3315 and RFC 3646 for the list of DHCPv6 options that can be de‐
3094       fined here.
3095
3096   Summary:
3097       name                          string
3098       code                          integer, in range 0 to 254
3099       type                          string, one of domain, ipv6, mac, or str
3100
3101   Details:
3102       name: string
3103              Name of the DHCPv6 option.
3104
3105              Example. name="ia_addr"
3106
3107       code: integer, in range 0 to 254
3108              DHCPv6 option code for the DHCPv6 option as defined in  the  ap‐
3109              propriate RFC.
3110
3111              Example. code=3
3112
3113       type: string, one of domain, ipv6, mac, or str
3114              Data type of the DHCPv6 option code.
3115
3116              value: ipv6
3117                     This  indicates that the value of the DHCPv6 option is an
3118                     IPv6 address(es).
3119
3120                     Example. "name=ia_addr", "code=5", "type=ipv6".
3121
3122                     put_dhcpv6_opts(..., ia_addr = ae70::4,...)
3123
3124              value: str
3125                     This indicates that the value of the DHCPv6 option  is  a
3126                     string.
3127
3128                     Example. "name=domain_search", "code=24", "type=str".
3129
3130                     put_dhcpv6_opts(..., domain_search = ovn.domain,...)
3131
3132              value: mac
3133                     This  indicates  that the value of the DHCPv6 option is a
3134                     MAC address.
3135
3136                     Example. "name=server_id", "code=2", "type=mac".
3137
3138                     put_dhcpv6_opts(..., server_id = 01:02:03:04L05:06,...)
3139

Connection TABLE

3141       Configuration for a database connection to  an  Open  vSwitch  database
3142       (OVSDB) client.
3143
3144       This  table  primarily  configures  the  Open  vSwitch  database server
3145       (ovsdb-server).
3146
3147       The Open vSwitch database server can initiate and maintain active  con‐
3148       nections  to  remote  clients.  It can also listen for database connec‐
3149       tions.
3150
3151   Summary:
3152       Core Features:
3153         target                      string (must be unique within table)
3154         read_only                   boolean
3155         role                        string
3156       Client Failure Detection and Handling:
3157         max_backoff                 optional integer, at least 1,000
3158         inactivity_probe            optional integer
3159       Status:
3160         is_connected                boolean
3161         status : last_error         optional string
3162         status : state              optional string, one of ACTIVE,  BACKOFF,
3163                                     CONNECTING, IDLE, or VOID
3164         status : sec_since_connect  optional  string,  containing an integer,
3165                                     at least 0
3166         status : sec_since_disconnect
3167                                     optional string, containing  an  integer,
3168                                     at least 0
3169         status : locks_held         optional string
3170         status : locks_waiting      optional string
3171         status : locks_lost         optional string
3172         status : n_connections      optional  string,  containing an integer,
3173                                     at least 2
3174         status : bound_port         optional string, containing an integer
3175       Common Columns:
3176         external_ids                map of string-string pairs
3177         other_config                map of string-string pairs
3178
3179   Details:
3180     Core Features:
3181
3182       target: string (must be unique within table)
3183              Connection methods for clients.
3184
3185              The following connection methods are currently supported:
3186
3187              ssl:host[:port]
3188                     The specified SSL port on the given host, which  can  ei‐
3189                     ther  be a DNS name (if built with unbound library) or an
3190                     IP address. A valid SSL configuration  must  be  provided
3191                     when  this form is used, this configuration can be speci‐
3192                     fied via command-line options or the SSL table.
3193
3194                     If port is not specified, it defaults to 6640.
3195
3196                     SSL support is an optional feature  that  is  not  always
3197                     built as part of Open vSwitch.
3198
3199              tcp:host[:port]
3200                     The  specified  TCP port on the given host, which can ei‐
3201                     ther be a DNS name (if built with unbound library) or  an
3202                     IP  address  (IPv4  or IPv6). If host is an IPv6 address,
3203                     wrap it in square brackets, e.g. tcp:[::1]:6640.
3204
3205                     If port is not specified, it defaults to 6640.
3206
3207              pssl:[port][:host]
3208                     Listens for SSL connections on the  specified  TCP  port.
3209                     Specify  0  for  port  to  have  the kernel automatically
3210                     choose an available port. If host, which can either be  a
3211                     DNS  name  (if  built  with unbound library) or an IP ad‐
3212                     dress, is specified, then connections are  restricted  to
3213                     the  resolved  or specified local IP address (either IPv4
3214                     or IPv6 address). If host is an  IPv6  address,  wrap  in
3215                     square  brackets,  e.g.  pssl:6640:[::1].  If host is not
3216                     specified then it listens only on IPv4 (but not IPv6) ad‐
3217                     dresses.  A valid SSL configuration must be provided when
3218                     this form is used, this can be specified either via  com‐
3219                     mand-line options or the SSL table.
3220
3221                     If port is not specified, it defaults to 6640.
3222
3223                     SSL  support  is  an  optional feature that is not always
3224                     built as part of Open vSwitch.
3225
3226              ptcp:[port][:host]
3227                     Listens for connections on the specified TCP port.  Spec‐
3228                     ify 0 for port to have the kernel automatically choose an
3229                     available port. If host, which can either be a  DNS  name
3230                     (if  built  with  unbound  library)  or an IP address, is
3231                     specified, then connections are  restricted  to  the  re‐
3232                     solved or specified local IP address (either IPv4 or IPv6
3233                     address). If host is an IPv6 address, wrap it  in  square
3234                     brackets,  e.g. ptcp:6640:[::1]. If host is not specified
3235                     then it listens only on IPv4 addresses.
3236
3237                     If port is not specified, it defaults to 6640.
3238
3239              When multiple clients are configured, the target values must  be
3240              unique. Duplicate target values yield unspecified results.
3241
3242       read_only: boolean
3243              true  to  restrict  these connections to read-only transactions,
3244              false to allow them to modify the database.
3245
3246       role: string
3247              String containing role name for this connection entry.
3248
3249     Client Failure Detection and Handling:
3250
3251       max_backoff: optional integer, at least 1,000
3252              Maximum number of milliseconds to wait  between  connection  at‐
3253              tempts. Default is implementation-specific.
3254
3255       inactivity_probe: optional integer
3256              Maximum number of milliseconds of idle time on connection to the
3257              client before sending  an  inactivity  probe  message.  If  Open
3258              vSwitch  does  not communicate with the client for the specified
3259              number of seconds, it will send a probe. If a  response  is  not
3260              received  for  the  same additional amount of time, Open vSwitch
3261              assumes the connection has been broken and  attempts  to  recon‐
3262              nect.  Default is implementation-specific. A value of 0 disables
3263              inactivity probes.
3264
3265     Status:
3266
3267       Key-value pair of is_connected is always updated. Other key-value pairs
3268       in the status columns may be updated depends on the target type.
3269
3270       When target specifies a connection method that listens for inbound con‐
3271       nections (e.g. ptcp: or punix:), both  n_connections  and  is_connected
3272       may also be updated while the remaining key-value pairs are omitted.
3273
3274       On  the  other  hand, when target specifies an outbound connection, all
3275       key-value pairs may be updated, except  the  above-mentioned  two  key-
3276       value  pairs associated with inbound connection targets. They are omit‐
3277       ted.
3278
3279       is_connected: boolean
3280              true if currently connected to this client, false otherwise.
3281
3282       status : last_error: optional string
3283              A human-readable description of the last error on the connection
3284              to  the  manager; i.e. strerror(errno). This key will exist only
3285              if an error has occurred.
3286
3287       status : state: optional string, one of  ACTIVE,  BACKOFF,  CONNECTING,
3288       IDLE, or VOID
3289              The state of the connection to the manager:
3290
3291              VOID   Connection is disabled.
3292
3293              BACKOFF
3294                     Attempting to reconnect at an increasing period.
3295
3296              CONNECTING
3297                     Attempting to connect.
3298
3299              ACTIVE Connected, remote host responsive.
3300
3301              IDLE   Connection is idle. Waiting for response to keep-alive.
3302
3303              These  values  may  change in the future. They are provided only
3304              for human consumption.
3305
3306       status : sec_since_connect: optional string, containing an integer,  at
3307       least 0
3308              The amount of time since this client last successfully connected
3309              to the database (in seconds). Value is empty if client has never
3310              successfully been connected.
3311
3312       status  : sec_since_disconnect: optional string, containing an integer,
3313       at least 0
3314              The amount of time since this client last disconnected from  the
3315              database  (in  seconds). Value is empty if client has never dis‐
3316              connected.
3317
3318       status : locks_held: optional string
3319              Space-separated list of the names of OVSDB locks that  the  con‐
3320              nection  holds.  Omitted  if  the  connection  does not hold any
3321              locks.
3322
3323       status : locks_waiting: optional string
3324              Space-separated list of the names of OVSDB locks that  the  con‐
3325              nection  is currently waiting to acquire. Omitted if the connec‐
3326              tion is not waiting for any locks.
3327
3328       status : locks_lost: optional string
3329              Space-separated list of the names of OVSDB locks that  the  con‐
3330              nection  has  had  stolen by another OVSDB client. Omitted if no
3331              locks have been stolen from this connection.
3332
3333       status : n_connections: optional  string,  containing  an  integer,  at
3334       least 2
3335              When  target  specifies a connection method that listens for in‐
3336              bound connections (e.g. ptcp: or pssl:) and more than  one  con‐
3337              nection  is  actually  active, the value is the number of active
3338              connections. Otherwise, this key-value pair is omitted.
3339
3340       status : bound_port: optional string, containing an integer
3341              When target is ptcp: or pssl:, this is the TCP port on which the
3342              OVSDB  server  is  listening.  (This is particularly useful when
3343              target specifies a port of 0, allowing the kernel to choose  any
3344              available port.)
3345
3346     Common Columns:
3347
3348       The  overall purpose of these columns is described under Common Columns
3349       at the beginning of this document.
3350
3351       external_ids: map of string-string pairs
3352
3353       other_config: map of string-string pairs
3354

SSL TABLE

3356       SSL configuration for ovn-sb database access.
3357
3358   Summary:
3359       private_key                   string
3360       certificate                   string
3361       ca_cert                       string
3362       bootstrap_ca_cert             boolean
3363       ssl_protocols                 string
3364       ssl_ciphers                   string
3365       Common Columns:
3366         external_ids                map of string-string pairs
3367
3368   Details:
3369       private_key: string
3370              Name of a PEM file  containing  the  private  key  used  as  the
3371              switch’s identity for SSL connections to the controller.
3372
3373       certificate: string
3374              Name  of a PEM file containing a certificate, signed by the cer‐
3375              tificate authority (CA) used by the controller and manager, that
3376              certifies  the  switch’s  private key, identifying a trustworthy
3377              switch.
3378
3379       ca_cert: string
3380              Name of a PEM file containing the CA certificate used to  verify
3381              that the switch is connected to a trustworthy controller.
3382
3383       bootstrap_ca_cert: boolean
3384              If  set to true, then Open vSwitch will attempt to obtain the CA
3385              certificate from the controller on its first SSL connection  and
3386              save  it to the named PEM file. If it is successful, it will im‐
3387              mediately drop the connection and reconnect, and  from  then  on
3388              all  SSL  connections  must  be  authenticated  by a certificate
3389              signed by the CA certificate thus obtained. This option  exposes
3390              the  SSL  connection to a man-in-the-middle attack obtaining the
3391              initial CA certificate. It may still be  useful  for  bootstrap‐
3392              ping.
3393
3394       ssl_protocols: string
3395              List of SSL protocols to be enabled for SSL connections. The de‐
3396              fault when this option is omitted is TLSv1,TLSv1.1,TLSv1.2.
3397
3398       ssl_ciphers: string
3399              List of ciphers (in OpenSSL cipher string  format)  to  be  sup‐
3400              ported  for  SSL  connections.  The  default when this option is
3401              omitted is HIGH:!aNULL:!MD5.
3402
3403     Common Columns:
3404
3405       The overall purpose of these columns is described under Common  Columns
3406       at the beginning of this document.
3407
3408       external_ids: map of string-string pairs
3409

DNS TABLE

3411       Each  row  in  this  table  stores  the  DNS  records.  The  OVN action
3412       dns_lookup uses this table for DNS resolution.
3413
3414   Summary:
3415       records                       map of string-string pairs
3416       datapaths                     set of 1 or more Datapath_Bindings
3417       Common Columns:
3418         external_ids                map of string-string pairs
3419
3420   Details:
3421       records: map of string-string pairs
3422              Key-value pair of DNS records with DNS query name as the key and
3423              a  string  of  IP address(es) separated by comma or space as the
3424              value. ovn-northd stores the DNS query name in all lowercase  in
3425              order to facilitate case-insensitive lookups.
3426
3427              Example:  "vm1.ovn.org" = "10.0.0.4 aef0::4"
3428
3429       datapaths: set of 1 or more Datapath_Bindings
3430              The  DNS  records  defined in the column records will be applied
3431              only to the DNS queries originating from the  datapaths  defined
3432              in this column.
3433
3434     Common Columns:
3435
3436       external_ids: map of string-string pairs
3437              See External IDs at the beginning of this document.
3438

RBAC_Role TABLE

3440       Role table for role-based access controls.
3441
3442   Summary:
3443       name                          string
3444       permissions                   map of string-weak reference to RBAC_Per‐
3445                                     mission pairs
3446
3447   Details:
3448       name: string
3449              The role name, corresponding to the role column in  the  Connec‐
3450              tion table.
3451
3452       permissions: map of string-weak reference to RBAC_Permission pairs
3453              A mapping of table names to rows in the RBAC_Permission table.
3454

RBAC_Permission TABLE

3456       Permissions table for role-based access controls.
3457
3458   Summary:
3459       table                         string
3460       authorization                 set of strings
3461       insert_delete                 boolean
3462       update                        set of strings
3463
3464   Details:
3465       table: string
3466              Name of table to which this row applies.
3467
3468       authorization: set of strings
3469              Set  of  strings  identifying columns and column:key pairs to be
3470              compared with client ID. At least one match is required in order
3471              to  be  authorized. A zero-length string is treated as a special
3472              value indicating all clients should be considered authorized.
3473
3474       insert_delete: boolean
3475              When "true", row insertions and  authorized  row  deletions  are
3476              permitted.
3477
3478       update: set of strings
3479              Set of strings identifying columns and column:key pairs that au‐
3480              thorized clients are allowed to modify.
3481

Gateway_Chassis TABLE

3483       Association of Port_Binding rows of type chassisredirect to a  Chassis.
3484       The  traffic  going out through a specific chassisredirect port will be
3485       redirected to a chassis, or a set of them in high availability configu‐
3486       rations.
3487
3488   Summary:
3489       name                          string (must be unique within table)
3490       chassis                       optional weak reference to Chassis
3491       priority                      integer, in range 0 to 32,767
3492       options                       map of string-string pairs
3493       Common Columns:
3494         external_ids                map of string-string pairs
3495
3496   Details:
3497       name: string (must be unique within table)
3498              Name of the Gateway_Chassis.
3499
3500              A   suggested,   but   not   required   naming   convention   is
3501              ${port_name}_${chassis_name}.
3502
3503       chassis: optional weak reference to Chassis
3504              The Chassis to which we send the traffic.
3505
3506       priority: integer, in range 0 to 32,767
3507              This is the  priority  the  specific  Chassis  among  all  Gate‐
3508              way_Chassis belonging to the same Port_Binding.
3509
3510       options: map of string-string pairs
3511              Reserved for future use.
3512
3513     Common Columns:
3514
3515       The  overall purpose of these columns is described under Common Columns
3516       at the beginning of this document.
3517
3518       external_ids: map of string-string pairs
3519

HA_Chassis TABLE

3521   Summary:
3522       chassis                       optional weak reference to Chassis
3523       priority                      integer, in range 0 to 32,767
3524       Common Columns:
3525         external_ids                map of string-string pairs
3526
3527   Details:
3528       chassis: optional weak reference to Chassis
3529              The Chassis which provides the HA functionality.
3530
3531       priority: integer, in range 0 to 32,767
3532              Priority of the HA chassis. Chassis with highest  priority  will
3533              be the master in the HA chassis group.
3534
3535     Common Columns:
3536
3537       external_ids: map of string-string pairs
3538              See External IDs at the beginning of this document.
3539

HA_Chassis_Group TABLE

3541       Table representing a group of chassis which can provide High availabil‐
3542       ity services. Each chassis in the group is  represented  by  the  table
3543       HA_Chassis.  The HA chassis with highest priority will be the master of
3544       this group. If the master chassis failover is detected, the HA  chassis
3545       with  the next higher priority takes over the responsibility of provid‐
3546       ing the HA. If ha_chassis_group column of the table Port_Binding refer‐
3547       ences this table, then this HA chassis group provides the gateway func‐
3548       tionality and redirects the gateway  traffic  to  the  master  of  this
3549       group.
3550
3551   Summary:
3552       name                          string (must be unique within table)
3553       ha_chassis                    set of HA_Chassises
3554       ref_chassis                   set of weak reference to Chassis
3555       Common Columns:
3556         external_ids                map of string-string pairs
3557
3558   Details:
3559       name: string (must be unique within table)
3560              Name of the HA_Chassis_Group. Name should be unique.
3561
3562       ha_chassis: set of HA_Chassises
3563              A list of HA_Chassis which belongs to this group.
3564
3565       ref_chassis: set of weak reference to Chassis
3566              The  set of Chassis that reference this HA chassis group. To de‐
3567              termine the  correct  Chassis,  find  the  chassisredirect  type
3568              Port_Binding   that   references   this  HA_Chassis_Group.  This
3569              Port_Binding is derived from  some  particular  logical  router.
3570              Starting  from that LR, find the set of all logical switches and
3571              routers connected to it, directly or indirectly,  across  router
3572              ports  that link one LRP to another or to a LSP. For each LSP in
3573              these logical switches, find the corresponding Port_Binding  and
3574              add its bound Chassis (if any) to ref_chassis.
3575
3576     Common Columns:
3577
3578       external_ids: map of string-string pairs
3579              See External IDs at the beginning of this document.
3580

Controller_Event TABLE

3582       Database  table  used  by  ovn-controller to report CMS related events.
3583       Please note there is no guarantee a given event is written exactly once
3584       in  the  db.  It is CMS responsibility to squash duplicated lines or to
3585       filter out duplicated events
3586
3587   Summary:
3588       event_type                    string, must be empty_lb_backends
3589       event_info                    map of string-string pairs
3590       chassis                       optional weak reference to Chassis
3591       seq_num                       integer
3592
3593   Details:
3594       event_type: string, must be empty_lb_backends
3595              Event type occurred
3596
3597       event_info: map of string-string pairs
3598              Key-value pairs used to specify event info to the CMS.  Possible
3599              values are:
3600
3601vip: VIP reported for the empty_lb_backends event
3602
3603protocol:    Transport    protocol   reported   for   the
3604                     empty_lb_backends event
3605
3606load_balancer: UUID of the load balancer reported for the
3607                     empty_lb_backends event
3608
3609       chassis: optional weak reference to Chassis
3610              This column is a Chassis record to identify the chassis that has
3611              managed a given event.
3612
3613       seq_num: integer
3614              Event sequence number. Global counter for  controller  generated
3615              events. It can be used by the CMS to detect possible duplication
3616              of the same event.
3617

IP_Multicast TABLE

3619       IP Multicast configuration options. For now only applicable to IGMP.
3620
3621   Summary:
3622       datapath                      weak reference to Datapath_Binding  (must
3623                                     be unique within table)
3624       enabled                       optional boolean
3625       querier                       optional boolean
3626       table_size                    optional integer
3627       idle_timeout                  optional integer
3628       query_interval                optional integer
3629       seq_no                        integer
3630       Querier configuration options:
3631         eth_src                     string
3632         ip4_src                     string
3633         ip6_src                     string
3634         query_max_resp              optional integer
3635
3636   Details:
3637       datapath: weak reference to Datapath_Binding (must be unique within ta‐
3638       ble)
3639              Datapath_Binding entry for which these configuration options are
3640              defined.
3641
3642       enabled: optional boolean
3643              Enables/disables multicast snooping. Default: disabled.
3644
3645       querier: optional boolean
3646              Enables/disables  multicast  querying. If enabled then multicast
3647              querying is enabled by default.
3648
3649       table_size: optional integer
3650              Limits the number of multicast groups that can be  learned.  De‐
3651              fault: 2048 groups per datapath.
3652
3653       idle_timeout: optional integer
3654              Configures the idle timeout (in seconds) for IP multicast groups
3655              if multicast snooping is enabled. Default: 300 seconds.
3656
3657       query_interval: optional integer
3658              Configures the  interval  (in  seconds)  for  sending  multicast
3659              queries if snooping and querier are enabled. Default: idle_time‐
3660              out/2 seconds.
3661
3662       seq_no: integer
3663              ovn-controller reads this value and flushes all  learned  multi‐
3664              cast groups when it detects that seq_no was changed.
3665
3666     Querier configuration options:
3667
3668       The  ovn-controller  process that runs on OVN hypervisor nodes uses the
3669       following columns to determine field values in IGMP/MLD queries that it
3670       originates:
3671
3672       eth_src: string
3673              Source Ethernet address.
3674
3675       ip4_src: string
3676              Source IPv4 address.
3677
3678       ip6_src: string
3679              Source IPv6 address.
3680
3681       query_max_resp: optional integer
3682              Value  (in seconds) to be used as "max-response" field in multi‐
3683              cast queries. Default: 1 second.
3684

IGMP_Group TABLE

3686       Contains learned IGMP groups indexed by address/datapath/chassis.
3687
3688   Summary:
3689       address                       string
3690       datapath                      optional weak reference to Datapath_Bind‐
3691                                     ing
3692       chassis                       optional weak reference to Chassis
3693       ports                         set of weak reference to Port_Bindings
3694
3695   Details:
3696       address: string
3697              Destination IPv4 address for the IGMP group.
3698
3699       datapath: optional weak reference to Datapath_Binding
3700              Datapath to which this IGMP group belongs.
3701
3702       chassis: optional weak reference to Chassis
3703              Chassis to which this IGMP group belongs.
3704
3705       ports: set of weak reference to Port_Bindings
3706              The destination port bindings for this IGMP group.
3707

Service_Monitor TABLE

3709       Each  row  in  this table configures monitoring a service for its live‐
3710       ness. The service can be an IPv4 TCP or UDP service. ovn-controller pe‐
3711       riodically  sends out service monitor packets and updates the status of
3712       the service. Service monitoring for IPv6 services is not supported.
3713
3714       ovn-northd uses this feature to  implement  the  load  balancer  health
3715       check feature offered to the CMS through the northbound database.
3716
3717   Summary:
3718       Configuration:
3719         ip                          string
3720         protocol                    optional string, either tcp or udp
3721         port                        integer, in range 0 to 65,535
3722         logical_port                string
3723         src_mac                     string
3724         src_ip                      string
3725         options : interval          optional string, containing an integer
3726         options : timeout           optional string, containing an integer
3727         options : success_count     optional string, containing an integer
3728         options : failure_count     optional string, containing an integer
3729       Status Reporting:
3730         status                      optional  string,  one of error, offline,
3731                                     or online
3732       Common Columns:
3733         external_ids                map of string-string pairs
3734
3735   Details:
3736     Configuration:
3737
3738       ovn-northd sets these columns and values to configure the service moni‐
3739       tor.
3740
3741       ip: string
3742              IP of the service to be monitored. Only IPv4 is supported.
3743
3744       protocol: optional string, either tcp or udp
3745              The protocol of the service.
3746
3747       port: integer, in range 0 to 65,535
3748              The TCP or UDP port of the service.
3749
3750       logical_port: string
3751              The VIF of the logical port on which the service is running. The
3752              ovn-controller that binds this logical_port monitors the service
3753              by sending periodic monitor packets.
3754
3755       src_mac: string
3756              Source Ethernet address to use in the service monitor packet.
3757
3758       src_ip: string
3759              Source IPv4 address to use in the service monitor packet.
3760
3761       options : interval: optional string, containing an integer
3762              The interval, in seconds, between service monitor checks.
3763
3764       options : timeout: optional string, containing an integer
3765              The  time,  in  seconds,  after  which the service monitor check
3766              times out.
3767
3768       options : success_count: optional string, containing an integer
3769              The number of successful checks after which the service is  con‐
3770              sidered online.
3771
3772       options : failure_count: optional string, containing an integer
3773              The  number of failure checks after which the service is consid‐
3774              ered offline.
3775
3776     Status Reporting:
3777
3778       The ovn-controller on the chassis that hosts the  logical_port  updates
3779       this column to report the service’s status.
3780
3781       status: optional string, one of error, offline, or online
3782              For  TCP  service, ovn-controller sends a SYN to the service and
3783              expects an ACK response to consider the service to be online.
3784
3785              For UDP service, ovn-controller sends a UDP packet to  the  ser‐
3786              vice and doesn’t expect any reply. If it receives an ICMP reply,
3787              then it considers the service to be offline.
3788
3789     Common Columns:
3790
3791       external_ids: map of string-string pairs
3792              See External IDs at the beginning of this document.
3793

Load_Balancer TABLE

3795       Each row represents a load balancer.
3796
3797   Summary:
3798       name                          string
3799       vips                          map of string-string pairs
3800       protocol                      optional string, one of sctp, tcp, or udp
3801       datapaths                     set of Datapath_Bindings
3802       datapath_group                optional Logical_DP_Group
3803       ls_datapath_group             optional Logical_DP_Group
3804       lr_datapath_group             optional Logical_DP_Group
3805       Load_Balancer options:
3806         options : hairpin_snat_ip   optional string
3807         options : hairpin_orig_tuple
3808                                     optional string, either true or false
3809       Common Columns:
3810         external_ids                map of string-string pairs
3811
3812   Details:
3813       name: string
3814              A name for the load balancer. This name has no  special  meaning
3815              or  purpose other than to provide convenience for human interac‐
3816              tion with the ovn-nb database.
3817
3818       vips: map of string-string pairs
3819              A map of virtual IP addresses (and an optional port number  with
3820              :  as  a separator) associated with this load balancer and their
3821              corresponding endpoint IP addresses (and optional  port  numbers
3822              with : as separators) separated by commas.
3823
3824       protocol: optional string, one of sctp, tcp, or udp
3825              Valid  protocols  are  tcp,  udp, or sctp. This column is useful
3826              when a port number is provided as part of the  vips  column.  If
3827              this  column  is  empty and a port number is provided as part of
3828              vips column, OVN assumes the protocol to be tcp.
3829
3830       datapaths: set of Datapath_Bindings
3831              Datapaths to which this load balancer applies to.
3832
3833       datapath_group: optional Logical_DP_Group
3834              Deprecated. The group of datapaths to which this  load  balancer
3835              applies  to.  This  means that the same load balancer applies to
3836              all datapaths in a group.
3837
3838       ls_datapath_group: optional Logical_DP_Group
3839              The group of datapaths to which this load balancer  applies  to.
3840              This  means that the same load balancer applies to all datapaths
3841              in a group.
3842
3843       lr_datapath_group: optional Logical_DP_Group
3844              The group of logical router datapaths to which  this  load  bal‐
3845              ancer applies to. This means that the same load balancer applies
3846              to all datapaths in a group.
3847
3848     Load_Balancer options:
3849
3850       options : hairpin_snat_ip: optional string
3851              IP to be used as source IP for  packets  that  have  been  hair-
3852              pinned  after  load balancing. This value is automatically popu‐
3853              lated by ovn-northd.
3854
3855       options : hairpin_orig_tuple: optional string, either true or false
3856              This value is automatically set to true by ovn-northd when orig‐
3857              inal  destination  IP  and  transport  port of the load balanced
3858              packets are stored in registers reg1, reg2, xxreg1.
3859
3860     Common Columns:
3861
3862       external_ids: map of string-string pairs
3863              See External IDs at the beginning of this document.
3864

BFD TABLE

3866       Contains BFD parameter for ovn-controller bfd configuration.
3867
3868   Summary:
3869       Configuration:
3870         src_port                    integer, in range 49,152 to 65,535
3871         disc                        integer
3872         logical_port                string
3873         dst_ip                      string
3874         min_tx                      integer
3875         min_rx                      integer
3876         detect_mult                 integer
3877         options                     map of string-string pairs
3878         external_ids                map of string-string pairs
3879       Status Reporting:
3880         status                      string, one of admin_down, down, init, or
3881                                     up
3882
3883   Details:
3884     Configuration:
3885
3886       src_port: integer, in range 49,152 to 65,535
3887              udp  source  port  used  in bfd control packets. The source port
3888              MUST be in the range 49152 through 65535 (RFC5881 section 4).
3889
3890       disc: integer
3891              A unique, nonzero discriminator value generated by the transmit‐
3892              ting  system,  used to demultiplex multiple BFD sessions between
3893              the same pair of systems.
3894
3895       logical_port: string
3896              OVN logical port when BFD engine is running.
3897
3898       dst_ip: string
3899              BFD peer IP address.
3900
3901       min_tx: integer
3902              This is the minimum interval, in milliseconds,  that  the  local
3903              system  would like to use when transmitting BFD Control packets,
3904              less any jitter applied. The value zero is reserved.
3905
3906       min_rx: integer
3907              This is the minimum interval, in milliseconds, between  received
3908              BFD  Control  packets that this system is capable of supporting,
3909              less any jitter applied by the sender. If this  value  is  zero,
3910              the  transmitting system does not want the remote system to send
3911              any periodic BFD Control packets.
3912
3913       detect_mult: integer
3914              Detection time multiplier.  The  negotiated  transmit  interval,
3915              multiplied  by  this  value, provides the Detection Time for the
3916              receiving system in Asynchronous mode.
3917
3918       options: map of string-string pairs
3919              Reserved for future use.
3920
3921       external_ids: map of string-string pairs
3922              See External IDs at the beginning of this document.
3923
3924     Status Reporting:
3925
3926       status: string, one of admin_down, down, init, or up
3927              BFD port logical states. Possible values are:
3928
3929admin_down
3930
3931down
3932
3933init
3934
3935up
3936

FDB TABLE

3938       This table is primarily used to learn the MACs observed on a VIF (or  a
3939       localnet  port  with  ’localnet_learn_fdb’  enabled) which belongs to a
3940       Logical_Switch_Port record in OVN_Northbound  whose  port  security  is
3941       disabled  and  ’unknown’ address set. If port security is disabled on a
3942       Logical_Switch_Port record, OVN should allow traffic  with  any  source
3943       mac  from  the  VIF. This table will be used to deliver a packet to the
3944       VIF, If a packet’s eth.dst is learnt.
3945
3946   Summary:
3947       mac                           string
3948       dp_key                        integer, in range 1 to 16,777,215
3949       port_key                      integer, in range 1 to 16,777,215
3950       timestamp                     integer
3951
3952   Details:
3953       mac: string
3954              The learnt mac address.
3955
3956       dp_key: integer, in range 1 to 16,777,215
3957              The key of the datapath on which this FDB was learnt.
3958
3959       port_key: integer, in range 1 to 16,777,215
3960              The key of the port binding on which this FDB was learnt.
3961
3962       timestamp: integer
3963              The timestamp in msec when the FDB was added or updated. Records
3964              that existed before this column will have 0.
3965

Static_MAC_Binding TABLE

3967       Each record represents a Static_MAC_Binding entry for a logical router.
3968
3969   Summary:
3970       logical_port                  string
3971       ip                            string
3972       mac                           string
3973       override_dynamic_mac          boolean
3974       datapath                      Datapath_Binding
3975
3976   Details:
3977       logical_port: string
3978              The logical router port for the binding.
3979
3980       ip: string
3981              The bound IP address.
3982
3983       mac: string
3984              The Ethernet address to which the IP is bound.
3985
3986       override_dynamic_mac: boolean
3987              Override dynamically learnt MACs.
3988
3989       datapath: Datapath_Binding
3990              The logical datapath to which the logical router port belongs.
3991

Chassis_Template_Var TABLE

3993       Each  record represents the set of template variable instantiations for
3994       a given chassis and is populated by ovn-northd from the contents of the
3995       OVN_Northbound.Chassis_Template_Var table.
3996
3997   Summary:
3998       chassis                       string (must be unique within table)
3999       variables                     map of string-string pairs
4000
4001   Details:
4002       chassis: string (must be unique within table)
4003              The chassis this set of variable values applies to.
4004
4005       variables: map of string-string pairs
4006              The set of variable values for a given chassis.
4007
4008
4009
4010Open vSwitch 23.09.2           DB Schema 20.29.0                     ovn-sb(5)
Impressum