1ovn-sb(5) Open vSwitch Manual ovn-sb(5)
2
3
4
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
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
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
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
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
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
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
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
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
756 • Fields. 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
764 • Subfields. 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
774 • Predicates. 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
790 • Ordinal. 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
806 • Nominal. 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
824 • Boolean. 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
944 • reg0...reg9
945
946 • xxreg0 xxreg1
947
948 • inport outport
949
950 • flags.loopback
951
952 • pkt.mark
953
954 • eth.src eth.dst eth.type
955
956 • vlan.tci vlan.vid vlan.pcp vlan.present
957
958 • ip.proto ip.dscp ip.ecn ip.ttl ip.frag
959
960 • ip4.src ip4.dst
961
962 • ip6.src ip6.dst ip6.label
963
964 • arp.op arp.spa arp.tpa arp.sha arp.tha
965
966 • rarp.op rarp.spa rarp.tpa rarp.sha rarp.tha
967
968 • tcp.src tcp.dst tcp.flags
969
970 • udp.src udp.dst
971
972 • sctp.src sctp.dst
973
974 • icmp4.type icmp4.code
975
976 • icmp6.type icmp6.code
977
978 • nd.target nd.sll nd.tll
979
980 • ct_mark ct_label
981
982 • ct_state, which has several Boolean subfields. The
983 ct_next action initializes the following subfields:
984
985 • ct.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
989 • ct.new: True for a new flow
990
991 • ct.est: True for an established flow
992
993 • ct.rel: True for a related flow
994
995 • ct.rpl: True for a reply flow
996
997 • ct.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
1002 • ct.dnat: True for a packet whose destination IP
1003 address has been changed.
1004
1005 • ct.snat: True for a packet whose source IP address
1006 has been changed.
1007
1008 The following predicates are supported:
1009
1010 • eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff
1011
1012 • eth.mcast expands to eth.dst[40]
1013
1014 • vlan.present expands to vlan.tci[12]
1015
1016 • ip4 expands to eth.type == 0x800
1017
1018 • ip4.src_mcast expands to ip4.src[28..31] == 0xe
1019
1020 • ip4.mcast expands to ip4.dst[28..31] == 0xe
1021
1022 • ip6 expands to eth.type == 0x86dd
1023
1024 • ip expands to ip4 || ip6
1025
1026 • icmp4 expands to ip4 && ip.proto == 1
1027
1028 • icmp6 expands to ip6 && ip.proto == 58
1029
1030 • icmp expands to icmp4 || icmp6
1031
1032 • ip.is_frag expands to ip.frag[0]
1033
1034 • ip.later_frag expands to ip.frag[1]
1035
1036 • ip.first_frag expands to ip.is_frag && !ip.later_frag
1037
1038 • arp expands to eth.type == 0x806
1039
1040 • rarp expands to eth.type == 0x8035
1041
1042 • nd expands to icmp6.type == {135, 136} && icmp6.code == 0
1043 && ip.ttl == 255
1044
1045 • nd_ns expands to icmp6.type == 135 && icmp6.code == 0 &&
1046 ip.ttl == 255
1047
1048 • nd_na expands to icmp6.type == 136 && icmp6.code == 0 &&
1049 ip.ttl == 255
1050
1051 • nd_rs expands to icmp6.type == 133 && icmp6.code == 0 &&
1052 ip.ttl == 255
1053
1054 • nd_ra expands to icmp6.type == 134 && icmp6.code == 0 &&
1055 ip.ttl == 255
1056
1057 • tcp expands to ip.proto == 6
1058
1059 • udp expands to ip.proto == 17
1060
1061 • sctp 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
1134 • icmp4.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
1318 • eth.src unchanged
1319
1320 • eth.dst unchanged
1321
1322 • eth.type = 0x0806
1323
1324 • arp.op = 1 (ARP request)
1325
1326 • arp.sha copied from eth.src
1327
1328 • arp.spa copied from ip4.src
1329
1330 • arp.tha = 00:00:00:00:00:00
1331
1332 • arp.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
1422 • eth.src unchanged
1423
1424 • eth.dst set to IPv6 multicast MAC address
1425
1426 • eth.type = 0x86dd
1427
1428 • ip6.src copied from ip6.src
1429
1430 • ip6.dst set to IPv6 Solicited-Node multicast address
1431
1432 • icmp6.type = 135 (Neighbor Solicitation)
1433
1434 • nd.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
1453 • eth.dst exchanged with eth.src
1454
1455 • eth.type = 0x86dd
1456
1457 • ip6.dst copied from ip6.src
1458
1459 • ip6.src copied from nd.target
1460
1461 • icmp6.type = 136 (Neighbor Advertisement)
1462
1463 • nd.target unchanged
1464
1465 • nd.sll = 00:00:00:00:00:00
1466
1467 • nd.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
1487 • eth.dst exchanged with eth.src
1488
1489 • eth.type = 0x86dd
1490
1491 • ip6.dst copied from ip6.src
1492
1493 • ip6.src copied from nd.target
1494
1495 • icmp6.type = 136 (Neighbor Advertisement)
1496
1497 • nd.target unchanged
1498
1499 • nd.sll = 00:00:00:00:00:00
1500
1501 • nd.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
1679 • addr_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
1687 • slla
1688
1689 Mandatory parameter which specifies the link-layer
1690 address of the interface from which the Router Ad‐
1691 vertisement is sent.
1692
1693 • mtu
1694
1695 Optional parameter which specifies the MTU.
1696
1697 • prefix
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
1799 • ip.proto = 1 (ICMPv4)
1800
1801 • ip.frag = 0 (not a fragment)
1802
1803 • ip.ttl = 255
1804
1805 • icmp4.type = 3 (destination unreachable)
1806
1807 • icmp4.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
1830 • ip.proto = 58 (ICMPv6)
1831
1832 • ip.ttl = 255
1833
1834 • icmp6.type = 1 (destination unreachable)
1835
1836 • icmp6.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
1879 • empty_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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
3601 • vip: VIP reported for the empty_lb_backends event
3602
3603 • protocol: Transport protocol reported for the
3604 empty_lb_backends event
3605
3606 • load_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
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
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
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
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
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
3929 • admin_down
3930
3931 • down
3932
3933 • init
3934
3935 • up
3936
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
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
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)