1ovn-sb(5) Open vSwitch Manual ovn-sb(5)
2
6 ovn-sb - OVN_Southbound database schema
7 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 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 Database Structure
18 The OVN Southbound database contains classes of data with different
19 properties, as described in the sections below.
20 Physical network
22 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 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 The Chassis and Encap tables are the physical network tables.
33 Logical Network
35 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 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 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 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 The Logical_Flow, Multicast_Group, Address_Group, DHCP_Options,
59 DHCPv6_Options, and DNS tables contain logical network data.
60 Logical-physical bindings
62 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 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 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 The Port_Binding and Datapath_Binding tables contain binding data.
77 MAC bindings
79 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 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 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 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 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 Connection Options:
195 connections set of Connections
196 ssl optional SSL
197 Security Configurations:
198 ipsec boolean
199 Details:
201 Status:
202 This column allow a client to track the overall configuration state of
204 the system.
205 nb_cfg: integer
207 Sequence number for the configuration. When a CMS or ovn-nbctl
208 updates the northbound database, it increments the nb_cfg column
209 in the NB_Global table in the northbound database. In turn, when
210 ovn-northd updates the southbound database to bring it up to
211 date with these changes, it updates this column to the same
212 value.
213 Common Columns:
215 external_ids: map of string-string pairs
217 See External IDs at the beginning of this document.
218 options: map of string-string pairs
220 Common options:
222 options: map of string-string pairs
224 This column provides general key/value settings. The supported
225 options are described individually below.
226 Options for configuring BFD:
228 These options apply when ovn-controller configures BFD on tunnels in‐
230 terfaces.
231 options : bfd-min-rx: optional string
233 BFD option min-rx value to use when configuring BFD on tunnel
234 interfaces.
235 options : bfd-decay-min-rx: optional string
237 BFD option decay-min-rx value to use when configuring BFD on
238 tunnel interfaces.
239 options : bfd-min-tx: optional string
241 BFD option min-tx value to use when configuring BFD on tunnel
242 interfaces.
243 options : bfd-mult: optional string
245 BFD option mult value to use when configuring BFD on tunnel in‐
246 terfaces.
247 options : debug_drop_domain_id: optional string
249 If set to a 8-bit number and if debug_drop_collector_set is also
250 configured, ovn-controller will add a sample action to every
251 flow that does not come from a logical flow that contains a
252 ’drop’ action. The 8 most significant bits of the observa‐
253 tion_domain_id field will be those specified in the de‐
254 bug_drop_domain_id. The 24 least significant bits of the obser‐
255 vation_domain_id field will be zero.
256 The observation_point_id will be set to the OpenFlow table num‐
258 ber.
259 options : debug_drop_collector_set: optional string
261 If set to a 32-bit number ovn-controller will add a sample ac‐
262 tion to every flow that does not come from a logical flow that
263 contains a ’drop’ action. The sample action will have the speci‐
264 fied collector_set_id. The value must match that of the local
265 OVS configuration as described in ovs-actions(7).
266 Options for configuring Load Balancers:
268 These options apply when ovn-controller configures load balancer re‐
270 lated flows.
271 options : lb_hairpin_use_ct_mark: optional string
273 By default this option is turned on (even if not present in the
274 database) unless its value is explicitly set to false. This
275 value is automatically set to false by ovn-northd when action
276 ct_lb_mark cannot be used for new load balancer sessions and ac‐
277 tion ct_lb will be used instead. ovn-controller then knows that
278 it should check ct_label.natted to detect load balanced traffic.
279 Connection Options:
281 connections: set of Connections
283 Database clients to which the Open vSwitch database server
284 should connect or on which it should listen, along with options
285 for how these connections should be configured. See the Connec‐
286 tion table for more information.
287 ssl: optional SSL
289 Global SSL configuration.
290 Security Configurations:
292 ipsec: boolean
294 Tunnel encryption configuration. If this column is set to be
295 true, all OVN tunnels will be encrypted with IPsec.
296
298 Each row in this table represents a hypervisor or gateway (a chassis)
299 in the physical network. Each chassis, via ovn-controller/ovn-con‐
300 troller-vtep, adds and updates its own row, and keeps a copy of the re‐
301 maining rows to determine how to reach other hypervisors.
302 When a chassis shuts down gracefully, it should remove its own row.
304 (This is not critical because resources hosted on the chassis are
305 equally unreachable regardless of whether the row is present.) If a
306 chassis shuts down permanently without removing its row, some kind of
307 manual or automatic cleanup is eventually needed; we can devise a
308 process for that as necessary.
309 Summary:
311 name string (must be unique within table)
312 hostname string
313 nb_cfg integer
314 other_config : ovn-bridge-mappings
315 optional string
316 other_config : datapath-type optional string
317 other_config : iface-types optional string
318 other_config : ovn-cms-options
319 optional string
320 other_config : is-interconn optional string
321 other_config : is-remote optional string
322 transport_zones set of strings
323 other_config : ovn-chassis-mac-mappings
324 optional string
325 other_config : port-up-notif optional string
326 Common Columns:
327 external_ids map of string-string pairs
328 Encapsulation Configuration:
329 encaps set of 1 or more Encaps
330 Gateway Configuration:
331 vtep_logical_switches set of strings
332 Details:
334 name: string (must be unique within table)
335 OVN does not prescribe a particular format for chassis names.
336 ovn-controller populates this column using external_ids:system-
337 id in the Open_vSwitch database’s Open_vSwitch table. ovn-con‐
338 troller-vtep populates this column with name in the hard‐
339 ware_vtep database’s Physical_Switch table.
340 hostname: string
342 The hostname of the chassis, if applicable. ovn-controller will
343 populate this column with the hostname of the host it is running
344 on. ovn-controller-vtep will leave this column empty.
345 nb_cfg: integer
347 Deprecated. This column is replaced by the nb_cfg column of the
348 Chassis_Private table.
349 other_config : ovn-bridge-mappings: optional string
351 ovn-controller populates this key with the set of bridge map‐
352 pings it has been configured to use. Other applications should
353 treat this key as read-only. See ovn-controller(8) for more in‐
354 formation.
355 other_config : datapath-type: optional string
357 ovn-controller populates this key with the datapath type config‐
358 ured in the datapath_type column of the Open_vSwitch database’s
359 Bridge table. Other applications should treat this key as read-
360 only. See ovn-controller(8) for more information.
361 other_config : iface-types: optional string
363 ovn-controller populates this key with the interface types con‐
364 figured in the iface_types column of the Open_vSwitch database’s
365 Open_vSwitch table. Other applications should treat this key as
366 read-only. See ovn-controller(8) for more information.
367 other_config : ovn-cms-options: optional string
369 ovn-controller populates this key with the set of options con‐
370 figured in the external_ids:ovn-cms-options column of the
371 Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
372 troller(8) for more information.
373 other_config : is-interconn: optional string
375 ovn-controller populates this key with the setting configured in
376 the external_ids:ovn-is-interconn column of the Open_vSwitch
377 database’s Open_vSwitch table. If set to true, the chassis is
378 used as an interconnection gateway. See ovn-controller(8) for
379 more information.
380 other_config : is-remote: optional string
382 ovn-ic set this key to true for remote interconnection gateway
383 chassises learned from the interconnection southbound database.
384 See ovn-ic(8) for more information.
385 transport_zones: set of strings
387 ovn-controller populates this key with the transport zones con‐
388 figured in the external_ids:ovn-transport-zones column of the
389 Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
390 troller(8) for more information.
391 other_config : ovn-chassis-mac-mappings: optional string
393 ovn-controller populates this key with the set of options con‐
394 figured in the external_ids:ovn-chassis-mac-mappings column of
395 the Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
396 troller(8) for more information.
397 other_config : port-up-notif: optional string
399 ovn-controller populates this key with true when it supports
400 Port_Binding.up.
401 Common Columns:
403 The overall purpose of these columns is described under Common Columns
405 at the beginning of this document.
406 external_ids: map of string-string pairs
408 Encapsulation Configuration:
410 OVN uses encapsulation to transmit logical dataplane packets between
412 chassis.
413 encaps: set of 1 or more Encaps
415 Points to supported encapsulation configurations to transmit
416 logical dataplane packets to this chassis. Each entry is a Encap
417 record that describes the configuration.
418 Gateway Configuration:
420 A gateway is a chassis that forwards traffic between the OVN-managed
422 part of a logical network and a physical VLAN, extending a tunnel-based
423 logical network into a physical network. Gateways are typically dedi‐
424 cated nodes that do not host VMs and will be controlled by ovn-con‐
425 troller-vtep.
426 vtep_logical_switches: set of strings
428 Stores all VTEP logical switch names connected by this gateway
429 chassis. The Port_Binding table entry with options:vtep-physi‐
430 cal-switch equal Chassis name, and options:vtep-logical-switch
431 value in Chassis vtep_logical_switches, will be associated with
432 this Chassis.
433
435 Each row in this table maintains per chassis private data that are ac‐
436 cessed only by the owning chassis (write only) and ovn-northd, not by
437 any other chassis. These data are stored in this separate table instead
438 of the Chassis table for performance considerations: the rows in this
439 table can be conditionally monitored by chassises so that each chassis
440 only get update notifications for its own row, to avoid unnecessary
441 chassis private data update flooding in a large scale deployment.
442 Summary:
444 name string (must be unique within table)
445 chassis optional weak reference to Chassis
446 nb_cfg integer
447 nb_cfg_timestamp integer
448 Common Columns:
449 external_ids map of string-string pairs
450 Details:
452 name: string (must be unique within table)
453 The name of the chassis that owns these chassis-private data.
454 chassis: optional weak reference to Chassis
456 The reference to Chassis table for the chassis that owns these
457 chassis-private data.
458 nb_cfg: integer
460 Sequence number for the configuration. When ovn-controller up‐
461 dates the configuration of a chassis from the contents of the
462 southbound database, it copies nb_cfg from the SB_Global table
463 into this column.
464 nb_cfg_timestamp: integer
466 The timestamp when ovn-controller finishes processing the change
467 corresponding to nb_cfg.
468 Common Columns:
470 The overall purpose of these columns is described under Common Columns
472 at the beginning of this document.
473 external_ids: map of string-string pairs
475
477 The encaps column in the Chassis table refers to rows in this table to
478 identify how OVN may transmit logical dataplane packets to this chas‐
479 sis. Each chassis, via ovn-controller(8) or ovn-controller-vtep(8),
480 adds and updates its own rows and keeps a copy of the remaining rows to
481 determine how to reach other chassis.
482 Summary:
484 type string, one of geneve, stt, or vxlan
485 options map of string-string pairs
486 options : csum optional string, either true or false
487 options : dst_port optional string, containing an integer
488 ip string
489 chassis_name string
490 Details:
492 type: string, one of geneve, stt, or vxlan
493 The encapsulation to use to transmit packets to this chassis.
494 Hypervisors must use either geneve or stt. Gateways may use
495 vxlan, geneve, or stt.
496 options: map of string-string pairs
498 Options for configuring the encapsulation, which may be type
499 specific.
500 options : csum: optional string, either true or false
502 csum indicates whether this chassis can transmit and receive
503 packets that include checksums with reasonable performance. It
504 hints to senders transmitting data to this chassis that they
505 should use checksums to protect OVN metadata. ovn-controller
506 populates this key with the value defined in external_ids:ovn-
507 encap-csum column of the Open_vSwitch database’s Open_vSwitch
508 table. Other applications should treat this key as read-only.
509 See ovn-controller(8) for more information.
510 In terms of performance, checksumming actually significantly in‐
512 creases throughput in most common cases when running on Linux
513 based hosts without NICs supporting encapsulation hardware off‐
514 load (around 60% for bulk traffic). The reason is that generally
515 all NICs are capable of offloading transmitted and received
516 TCP/UDP checksums (viewed as ordinary data packets and not as
517 tunnels). The benefit comes on the receive side where the vali‐
518 dated outer checksum can be used to additionally validate an in‐
519 ner checksum (such as TCP), which in turn allows aggregation of
520 packets to be more efficiently handled by the rest of the stack.
521 Not all devices see such a benefit. The most notable exception
523 is hardware VTEPs. These devices are designed to not buffer en‐
524 tire packets in their switching engines and are therefore unable
525 to efficiently compute or validate full packet checksums. In ad‐
526 dition certain versions of the Linux kernel are not able to
527 fully take advantage of encapsulation NIC offloads in the pres‐
528 ence of checksums. (This is actually a pretty narrow corner case
529 though: earlier versions of Linux don’t support encapsulation
530 offloads at all and later versions support both offloads and
531 checksums well.)
532 csum defaults to false for hardware VTEPs and true for all other
534 cases.
535 This option applies to geneve and vxlan encapsulations.
537 options : dst_port: optional string, containing an integer
539 If set, overrides the UDP (for geneve and vxlan) or TCP (for
540 stt) destination port.
541 ip: string
543 The IPv4 address of the encapsulation tunnel endpoint.
544 chassis_name: string
546 The name of the chassis that created this encap.
547
549 This table contains address sets synced from the Address_Set table in
550 the OVN_Northbound database and address sets generated from the
551 Port_Group table in the OVN_Northbound database.
552 See the documentation for the Address_Set table and Port_Group table in
554 the OVN_Northbound database for details.
555 Summary:
557 name string (must be unique within table)
558 addresses set of strings
559 Details:
561 name: string (must be unique within table)
562 addresses: set of strings
564
566 This table contains names for the logical switch ports in the
567 OVN_Northbound database that belongs to the same group that is defined
568 in Port_Group in the OVN_Northbound database.
569 Summary:
571 name string (must be unique within table)
572 ports set of strings
573 Details:
575 name: string (must be unique within table)
576 ports: set of strings
578
580 Each row in this table represents one logical flow. ovn-northd popu‐
581 lates this table with logical flows that implement the L2 and L3
582 topologies specified in the OVN_Northbound database. Each hypervisor,
583 via ovn-controller, translates the logical flows into OpenFlow flows
584 specific to its hypervisor and installs them into Open vSwitch.
585 Logical flows are expressed in an OVN-specific format, described here.
587 A logical datapath flow is much like an OpenFlow flow, except that the
588 flows are written in terms of logical ports and logical datapaths in‐
589 stead of physical ports and physical datapaths. Translation between
590 logical and physical flows helps to ensure isolation between logical
591 datapaths. (The logical flow abstraction also allows the OVN central‐
592 ized components to do less work, since they do not have to separately
593 compute and push out physical flows to each chassis.)
594 The default action when no flow matches is to drop packets.
596 Architectural Logical Life Cycle of a Packet
598 This following description focuses on the life cycle of a packet
600 through a logical datapath, ignoring physical details of the implemen‐
601 tation. Please refer to Architectural Physical Life Cycle of a Packet
602 in ovn-architecture(7) for the physical information.
603 The description here is written as if OVN itself executes these steps,
605 but in fact OVN (that is, ovn-controller) programs Open vSwitch, via
606 OpenFlow and OVSDB, to execute them on its behalf.
607 At a high level, OVN passes each packet through the logical datapath’s
609 logical ingress pipeline, which may output the packet to one or more
610 logical port or logical multicast groups. For each such logical output
611 port, OVN passes the packet through the datapath’s logical egress pipe‐
612 line, which may either drop the packet or deliver it to the destina‐
613 tion. Between the two pipelines, outputs to logical multicast groups
614 are expanded into logical ports, so that the egress pipeline only pro‐
615 cesses a single logical output port at a time. Between the two pipe‐
616 lines is also where, when necessary, OVN encapsulates a packet in a
617 tunnel (or tunnels) to transmit to remote hypervisors.
618 In more detail, to start, OVN searches the Logical_Flow table for a row
620 with correct logical_datapath or a logical_dp_group, a pipeline of
621 ingress, a table_id of 0, and a match that is true for the packet. If
622 none is found, OVN drops the packet. If OVN finds more than one, it
623 chooses the match with the highest priority. Then OVN executes each of
624 the actions specified in the row’s actions column, in the order speci‐
625 fied. Some actions, such as those to modify packet headers, require no
626 further details. The next and output actions are special.
627 The next action causes the above process to be repeated recursively,
629 except that OVN searches for table_id of 1 instead of 0. Similarly, any
630 next action in a row found in that table would cause a further search
631 for a table_id of 2, and so on. When recursive processing completes,
632 flow control returns to the action following next.
633 The output action also introduces recursion. Its effect depends on the
635 current value of the outport field. Suppose outport designates a logi‐
636 cal port. First, OVN compares inport to outport; if they are equal, it
637 treats the output as a no-op by default. In the common case, where they
638 are different, the packet enters the egress pipeline. This transition
639 to the egress pipeline discards register data, e.g. reg0 ... reg9 and
640 connection tracking state, to achieve uniform behavior regardless of
641 whether the egress pipeline is on a different hypervisor (because reg‐
642 isters aren’t preserve across tunnel encapsulation).
643 To execute the egress pipeline, OVN again searches the Logical_Flow ta‐
645 ble for a row with correct logical_datapath or a logical_dp_group, a
646 table_id of 0, a match that is true for the packet, but now looking for
647 a pipeline of egress. If no matching row is found, the output becomes a
648 no-op. Otherwise, OVN executes the actions for the matching flow (which
649 is chosen from multiple, if necessary, as already described).
650 In the egress pipeline, the next action acts as already described, ex‐
652 cept that it, of course, searches for egress flows. The output action,
653 however, now directly outputs the packet to the output port (which is
654 now fixed, because outport is read-only within the egress pipeline).
655 The description earlier assumed that outport referred to a logical
657 port. If it instead designates a logical multicast group, then the de‐
658 scription above still applies, with the addition of fan-out from the
659 logical multicast group to each logical port in the group. For each
660 member of the group, OVN executes the logical pipeline as described,
661 with the logical output port replaced by the group member.
662 Pipeline Stages
664 ovn-northd populates the Logical_Flow table with the logical flows de‐
666 scribed in detail in ovn-northd(8).
667 Summary:
669 logical_datapath optional Datapath_Binding
670 logical_dp_group optional Logical_DP_Group
671 pipeline string, either egress or ingress
672 table_id integer, in range 0 to 32
673 priority integer, in range 0 to 65,535
674 match string
675 actions string
676 tags map of string-string pairs
677 controller_meter optional string
678 external_ids : stage-name optional string
679 external_ids : stage-hint optional string, containing an uuid
680 external_ids : source optional string
681 Common Columns:
682 external_ids map of string-string pairs
683 Details:
685 logical_datapath: optional Datapath_Binding
686 The logical datapath to which the logical flow belongs.
687 logical_dp_group: optional Logical_DP_Group
689 The group of logical datapaths to which the logical flow be‐
690 longs. This means that the same logical flow belongs to all
691 datapaths in a group.
692 pipeline: string, either egress or ingress
694 The primary flows used for deciding on a packet’s destination
695 are the ingress flows. The egress flows implement ACLs. See Log‐
696 ical Life Cycle of a Packet, above, for details.
697 table_id: integer, in range 0 to 32
699 The stage in the logical pipeline, analogous to an OpenFlow ta‐
700 ble number.
701 priority: integer, in range 0 to 65,535
703 The flow’s priority. Flows with numerically higher priority take
704 precedence over those with lower. If two logical datapath flows
705 with the same priority both match, then the one actually applied
706 to the packet is undefined.
707 match: string
709 A matching expression. OVN provides a superset of OpenFlow
710 matching capabilities, using a syntax similar to Boolean expres‐
711 sions in a programming language.
712 The most important components of match expression are compar‐
714 isons between symbols and constants, e.g. ip4.dst ==
715 192.168.0.1, ip.proto == 6, arp.op == 1, eth.type == 0x800. The
716 logical AND operator && and logical OR operator || can combine
717 comparisons into a larger expression.
718 Matching expressions also support parentheses for grouping, the
720 logical NOT prefix operator !, and literals 0 and 1 to express
721 ``false’’ or ``true,’’ respectively. The latter is useful by it‐
722 self as a catch-all expression that matches every packet.
723 Match expressions also support a kind of function syntax. The
725 following functions are supported:
726 is_chassis_resident(lport)
728 Evaluates to true on a chassis on which logical port
729 lport (a quoted string) resides, and to false elsewhere.
730 This function was introduced in OVN 2.7.
731 Symbols
733 Type. Symbols have integer or string type. Integer symbols have
735 a width in bits.
736 Kinds. There are three kinds of symbols:
738 • Fields. A field symbol represents a packet header or
740 metadata field. For example, a field named vlan.tci might
741 represent the VLAN TCI field in a packet.
742 A field symbol can have integer or string type. Integer
744 fields can be nominal or ordinal (see Level of Measure‐
745 ment, below).
746 • Subfields. A subfield represents a subset of bits from a
748 larger field. For example, a field vlan.vid might be de‐
749 fined as an alias for vlan.tci[0..11]. Subfields are pro‐
750 vided for syntactic convenience, because it is always
751 possible to instead refer to a subset of bits from a
752 field directly.
753 Only ordinal fields (see Level of Measurement, below) may
755 have subfields. Subfields are always ordinal.
756 • Predicates. A predicate is shorthand for a Boolean ex‐
758 pression. Predicates may be used much like 1-bit fields.
759 For example, ip4 might expand to eth.type == 0x800. Pred‐
760 icates are provided for syntactic convenience, because it
761 is always possible to instead specify the underlying ex‐
762 pression directly.
763 A predicate whose expansion refers to any nominal field
765 or predicate (see Level of Measurement, below) is nomi‐
766 nal; other predicates have Boolean level of measurement.
767 Level of Measurement. See
769 http://en.wikipedia.org/wiki/Level_of_measurement for the sta‐
770 tistical concept on which this classification is based. There
771 are three levels:
772 • Ordinal. In statistics, ordinal values can be ordered on
774 a scale. OVN considers a field (or subfield) to be ordi‐
775 nal if its bits can be examined individually. This is
776 true for the OpenFlow fields that OpenFlow or Open
777 vSwitch makes ``maskable.’’
778 Any use of a ordinal field may specify a single bit or a
780 range of bits, e.g. vlan.tci[13..15] refers to the PCP
781 field within the VLAN TCI, and eth.dst[40] refers to the
782 multicast bit in the Ethernet destination address.
783 OVN supports all the usual arithmetic relations (==, !=,
785 <, <=, >, and >=) on ordinal fields and their subfields,
786 because OVN can implement these in OpenFlow and Open
787 vSwitch as collections of bitwise tests.
788 • Nominal. In statistics, nominal values cannot be usefully
790 compared except for equality. This is true of OpenFlow
791 port numbers, Ethernet types, and IP protocols are exam‐
792 ples: all of these are just identifiers assigned arbi‐
793 trarily with no deeper meaning. In OpenFlow and Open
794 vSwitch, bits in these fields generally aren’t individu‐
795 ally addressable.
796 OVN only supports arithmetic tests for equality on nomi‐
798 nal fields, because OpenFlow and Open vSwitch provide no
799 way for a flow to efficiently implement other comparisons
800 on them. (A test for inequality can be sort of built out
801 of two flows with different priorities, but OVN matching
802 expressions always generate flows with a single prior‐
803 ity.)
804 String fields are always nominal.
806 • Boolean. A nominal field that has only two values, 0 and
808 1, is somewhat exceptional, since it is easy to support
809 both equality and inequality tests on such a field: ei‐
810 ther one can be implemented as a test for 0 or 1.
811 Only predicates (see above) have a Boolean level of mea‐
813 surement.
814 This isn’t a standard level of measurement.
816 Prerequisites. Any symbol can have prerequisites, which are ad‐
818 ditional condition implied by the use of the symbol. For exam‐
819 ple, For example, icmp4.type symbol might have prerequisite
820 icmp4, which would cause an expression icmp4.type == 0 to be in‐
821 terpreted as icmp4.type == 0 && icmp4, which would in turn ex‐
822 pand to icmp4.type == 0 && eth.type == 0x800 && ip4.proto == 1
823 (assuming icmp4 is a predicate defined as suggested under Types
824 above).
825 Relational operators
827 All of the standard relational operators ==, !=, <, <=, >, and
829 >= are supported. Nominal fields support only == and !=, and
830 only in a positive sense when outer ! are taken into account,
831 e.g. given string field inport, inport == "eth0" and !(inport !=
832 "eth0") are acceptable, but not inport != "eth0".
833 The implementation of == (or != when it is negated), is more ef‐
835 ficient than that of the other relational operators.
836 Constants
838 Integer constants may be expressed in decimal, hexadecimal pre‐
840 fixed by 0x, or as dotted-quad IPv4 addresses, IPv6 addresses in
841 their standard forms, or Ethernet addresses as colon-separated
842 hex digits. A constant in any of these forms may be followed by
843 a slash and a second constant (the mask) in the same form, to
844 form a masked constant. IPv4 and IPv6 masks may be given as in‐
845 tegers, to express CIDR prefixes.
846 String constants have the same syntax as quoted strings in JSON
848 (thus, they are Unicode strings).
849 Some operators support sets of constants written inside curly
851 braces { ... }. Commas between elements of a set, and after the
852 last elements, are optional. With ==, ``field == { constant1,
853 constant2, ... }’’ is syntactic sugar for ``field == constant1
854 || field == constant2 || .... Similarly, ``field != { constant1,
855 constant2, ... }’’ is equivalent to ``field != constant1 &&
856 field != constant2 && ...’’.
857 You may refer to a set of IPv4, IPv6, or MAC addresses stored in
859 the Address_Set table by its name. An Address_Set with a name of
860 set1 can be referred to as $set1.
861 You may refer to a group of logical switch ports stored in the
863 Port_Group table by its name. An Port_Group with a name of
864 port_group1 can be referred to as @port_group1.
865 Additionally, you may refer to the set of addresses belonging to
867 a group of logical switch ports stored in the Port_Group table
868 by its name followed by a suffix ’_ip4’/’_ip6’. The IPv4 address
869 set of a Port_Group with a name of port_group1 can be referred
870 to as $port_group1_ip4, and the IPv6 address set of the same
871 Port_Group can be referred to as $port_group1_ip6
872 Miscellaneous
874 Comparisons may name the symbol or the constant first, e.g.
876 tcp.src == 80 and 80 == tcp.src are both acceptable.
877 Tests for a range may be expressed using a syntax like 1024 <=
879 tcp.src <= 49151, which is equivalent to 1024 <= tcp.src &&
880 tcp.src <= 49151.
881 For a one-bit field or predicate, a mention of its name is
883 equivalent to symobl == 1, e.g. vlan.present is equivalent to
884 vlan.present == 1. The same is true for one-bit subfields, e.g.
885 vlan.tci[12]. There is no technical limitation to implementing
886 the same for ordinal fields of all widths, but the implementa‐
887 tion is expensive enough that the syntax parser requires writing
888 an explicit comparison against zero to make mistakes less
889 likely, e.g. in tcp.src != 0 the comparison against 0 is re‐
890 quired.
891 Operator precedence is as shown below, from highest to lowest.
893 There are two exceptions where parentheses are required even
894 though the table would suggest that they are not: && and || re‐
895 quire parentheses when used together, and ! requires parentheses
896 when applied to a relational expression. Thus, in (eth.type ==
897 0x800 || eth.type == 0x86dd) && ip.proto == 6 or !(arp.op == 1),
898 the parentheses are mandatory.
899 • ()
901 • == != < <= > >=
903 • !
905 • && ||
907 Comments may be introduced by //, which extends to the next new-
909 line. Comments within a line may be bracketed by /* and */. Mul‐
910 tiline comments are not supported.
911 Symbols
913 Most of the symbols below have integer type. Only inport and
915 outport have string type. inport names a logical port. Thus, its
916 value is a logical_port name from the Port_Binding table. out‐
917 port may name a logical port, as inport, or a logical multicast
918 group defined in the Multicast_Group table. For both symbols,
919 only names within the flow’s logical datapath may be used.
920 The regX symbols are 32-bit integers. The xxregX symbols are
922 128-bit integers, which overlay four of the 32-bit registers:
923 xxreg0 overlays reg0 through reg3, with reg0 supplying the most-
924 significant bits of xxreg0 and reg3 the least-significant.
925 xxreg1 similarly overlays reg4 through reg7.
926 • reg0...reg9
928 • xxreg0 xxreg1
930 • inport outport
932 • flags.loopback
934 • pkt.mark
936 • eth.src eth.dst eth.type
938 • vlan.tci vlan.vid vlan.pcp vlan.present
940 • ip.proto ip.dscp ip.ecn ip.ttl ip.frag
942 • ip4.src ip4.dst
944 • ip6.src ip6.dst ip6.label
946 • arp.op arp.spa arp.tpa arp.sha arp.tha
948 • rarp.op rarp.spa rarp.tpa rarp.sha rarp.tha
950 • tcp.src tcp.dst tcp.flags
952 • udp.src udp.dst
954 • sctp.src sctp.dst
956 • icmp4.type icmp4.code
958 • icmp6.type icmp6.code
960 • nd.target nd.sll nd.tll
962 • ct_mark ct_label
964 • ct_state, which has several Boolean subfields. The
966 ct_next action initializes the following subfields:
967 • ct.trk: Always set to true by ct_next to indicate
969 that connection tracking has taken place. All
970 other ct subfields have ct.trk as a prerequisite.
971 • ct.new: True for a new flow
973 • ct.est: True for an established flow
975 • ct.rel: True for a related flow
977 • ct.rpl: True for a reply flow
979 • ct.inv: True for a connection entry in a bad state
981 The ct_dnat, ct_snat, and ct_lb actions initialize the
983 following subfields:
984 • ct.dnat: True for a packet whose destination IP
986 address has been changed.
987 • ct.snat: True for a packet whose source IP address
989 has been changed.
990 The following predicates are supported:
992 • eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff
994 • eth.mcast expands to eth.dst[40]
996 • vlan.present expands to vlan.tci[12]
998 • ip4 expands to eth.type == 0x800
1000 • ip4.src_mcast expands to ip4.src[28..31] == 0xe
1002 • ip4.mcast expands to ip4.dst[28..31] == 0xe
1004 • ip6 expands to eth.type == 0x86dd
1006 • ip expands to ip4 || ip6
1008 • icmp4 expands to ip4 && ip.proto == 1
1010 • icmp6 expands to ip6 && ip.proto == 58
1012 • icmp expands to icmp4 || icmp6
1014 • ip.is_frag expands to ip.frag[0]
1016 • ip.later_frag expands to ip.frag[1]
1018 • ip.first_frag expands to ip.is_frag && !ip.later_frag
1020 • arp expands to eth.type == 0x806
1022 • rarp expands to eth.type == 0x8035
1024 • nd expands to icmp6.type == {135, 136} && icmp6.code == 0
1026 && ip.ttl == 255
1027 • nd_ns expands to icmp6.type == 135 && icmp6.code == 0 &&
1029 ip.ttl == 255
1030 • nd_na expands to icmp6.type == 136 && icmp6.code == 0 &&
1032 ip.ttl == 255
1033 • nd_rs expands to icmp6.type == 133 && icmp6.code == 0 &&
1035 ip.ttl == 255
1036 • nd_ra expands to icmp6.type == 134 && icmp6.code == 0 &&
1038 ip.ttl == 255
1039 • tcp expands to ip.proto == 6
1041 • udp expands to ip.proto == 17
1043 • sctp expands to ip.proto == 132
1045 actions: string
1047 Logical datapath actions, to be executed when the logical flow
1048 represented by this row is the highest-priority match.
1049 Actions share lexical syntax with the match column. An empty set
1051 of actions (or one that contains just white space or comments),
1052 or a set of actions that consists of just drop;, causes the
1053 matched packets to be dropped. Otherwise, the column should con‐
1054 tain a sequence of actions, each terminated by a semicolon.
1055 The following actions are defined:
1057 output;
1059 In the ingress pipeline, this action executes the egress
1060 pipeline as a subroutine. If outport names a logical
1061 port, the egress pipeline executes once; if it is a mul‐
1062 ticast group, the egress pipeline runs once for each log‐
1063 ical port in the group.
1064 In the egress pipeline, this action performs the actual
1066 output to the outport logical port. (In the egress pipe‐
1067 line, outport never names a multicast group.)
1068 By default, output to the input port is implicitly
1070 dropped, that is, output becomes a no-op if outport ==
1071 inport. Occasionally it may be useful to override this
1072 behavior, e.g. to send an ARP reply to an ARP request; to
1073 do so, use flags.loopback = 1 to allow the packet to
1074 "hair-pin" back to the input port.
1075 next;
1077 next(table);
1078 next(pipeline=pipeline, table=table);
1079 Executes the given logical datapath table in pipeline as a
1080 subroutine. The default table is just after the current
1081 one. If pipeline is specified, it may be ingress or egress;
1082 the default pipeline is the one currently executing. Ac‐
1083 tions in the both ingress and egress pipeline can use next
1084 to jump across the other pipeline. Actions in the ingress
1085 pipeline should use next to jump into the specific table of
1086 egress pipeline only if it is certain that the packets are
1087 local and not tunnelled and wants to skip certain stages in
1088 the packet processing.
1089 field = constant;
1091 Sets data or metadata field field to constant value con‐
1092 stant, e.g. outport = "vif0"; to set the logical output
1093 port. To set only a subset of bits in a field, specify a
1094 subfield for field or a masked constant, e.g. one may use
1095 vlan.pcp[2] = 1; or vlan.pcp = 4/4; to set the most signif‐
1096 icant bit of the VLAN PCP.
1097 Assigning to a field with prerequisites implicitly adds
1099 those prerequisites to match; thus, for example, a flow
1100 that sets tcp.dst applies only to TCP flows, regardless of
1101 whether its match mentions any TCP field.
1102 Not all fields are modifiable (e.g. eth.type and ip.proto
1104 are read-only), and not all modifiable fields may be par‐
1105 tially modified (e.g. ip.ttl must assigned as a whole). The
1106 outport field is modifiable in the ingress pipeline but not
1107 in the egress pipeline.
1108 ovn_field = constant;
1110 Sets OVN field ovn_field to constant value constant.
1111 OVN supports setting the values of certain fields which are
1113 not yet supported in OpenFlow to set or modify them.
1114 Below are the supported OVN fields:
1116 • icmp4.frag_mtu icmp6.frag_mtu
1118 This field sets the low-order 16 bits of the
1120 ICMP{4,6} header field that is labelled "unused" in
1121 the ICMP specification as defined in the RFC 1191
1122 with the value specified in constant.
1123 Eg. icmp4.frag_mtu = 1500;
1125 field1 = field2;
1127 Sets data or metadata field field1 to the value of data or
1128 metadata field field2, e.g. reg0 = ip4.src; copies ip4.src
1129 into reg0. To modify only a subset of a field’s bits, spec‐
1130 ify a subfield for field1 or field2 or both, e.g. vlan.pcp
1131 = reg0[0..2]; copies the least-significant bits of reg0
1132 into the VLAN PCP.
1133 field1 and field2 must be the same type, either both string
1135 or both integer fields. If they are both integer fields,
1136 they must have the same width.
1137 If field1 or field2 has prerequisites, they are added im‐
1139 plicitly to match. It is possible to write an assignment
1140 with contradictory prerequisites, such as ip4.src =
1141 ip6.src[0..31];, but the contradiction means that a logical
1142 flow with such an assignment will never be matched.
1143 field1 <-> field2;
1145 Similar to field1 = field2; except that the two values are
1146 exchanged instead of copied. Both field1 and field2 must
1147 modifiable.
1148 push(field);
1150 Push the value of field to the stack top.
1151 pop(field);
1153 Pop the stack top and store the value to field, which must
1154 be modifiable.
1155 ip.ttl--;
1157 Decrements the IPv4 or IPv6 TTL. If this would make the TTL
1158 zero or negative, then processing of the packet halts; no
1159 further actions are processed. (To properly handle such
1160 cases, a higher-priority flow should match on ip.ttl == {0,
1161 1};.)
1162 Prerequisite: ip
1164 ct_next;
1166 Apply connection tracking to the flow, initializing
1167 ct_state for matching in later tables. Automatically moves
1168 on to the next table, as if followed by next.
1169 As a side effect, IP fragments will be reassembled for
1171 matching. If a fragmented packet is output, then it will be
1172 sent with any overlapping fragments squashed. The connec‐
1173 tion tracking state is scoped by the logical port when the
1174 action is used in a flow for a logical switch, so overlap‐
1175 ping addresses may be used. To allow traffic related to the
1176 matched flow, execute ct_commit . Connection tracking state
1177 is scoped by the logical topology when the action is used
1178 in a flow for a router.
1179 It is possible to have actions follow ct_next, but they
1181 will not have access to any of its side-effects and is not
1182 generally useful.
1183 ct_commit { };
1185 ct_commit { ct_mark=value[/mask]; };
1186 ct_commit { ct_label=value[/mask]; };
1187 ct_commit { ct_mark=value[/mask]; ct_label=value[/mask]; };
1188 Commit the flow to the connection tracking entry associated
1189 with it by a previous call to ct_next. When
1190 ct_mark=value[/mask] and/or ct_label=value[/mask] are sup‐
1191 plied, ct_mark and/or ct_label will be set to the values
1192 indicated by value[/mask] on the connection tracking entry.
1193 ct_mark is a 32-bit field. ct_label is a 128-bit field. The
1194 value[/mask] should be specified in hex string if more than
1195 64bits are to be used. Registers and other named fields can
1196 be used for value. ct_mark and ct_label may be sub-ad‐
1197 dressed in order to have specific bits set.
1198 Note that if you want processing to continue in the next
1200 table, you must execute the next action after ct_commit.
1201 You may also leave out next which will commit connection
1202 tracking state, and then drop the packet. This could be
1203 useful for setting ct_mark on a connection tracking entry
1204 before dropping a packet, for example.
1205 ct_dnat;
1207 ct_dnat(IP);
1208 ct_dnat sends the packet through the DNAT zone in connec‐
1209 tion tracking table to unDNAT any packet that was DNATed in
1210 the opposite direction. The packet is then automatically
1211 sent to to the next tables as if followed by next; action.
1212 The next tables will see the changes in the packet caused
1213 by the connection tracker.
1214 ct_dnat(IP) sends the packet through the DNAT zone to
1216 change the destination IP address of the packet to the one
1217 provided inside the parentheses and commits the connection.
1218 The packet is then automatically sent to the next tables as
1219 if followed by next; action. The next tables will see the
1220 changes in the packet caused by the connection tracker.
1221 ct_snat;
1223 ct_snat(IP);
1224 ct_snat sends the packet through the SNAT zone to unSNAT
1225 any packet that was SNATed in the opposite direction. The
1226 packet is automatically sent to the next tables as if fol‐
1227 lowed by the next; action. The next tables will see the
1228 changes in the packet caused by the connection tracker.
1229 ct_snat(IP) sends the packet through the SNAT zone to
1231 change the source IP address of the packet to the one pro‐
1232 vided inside the parenthesis and commits the connection.
1233 The packet is then automatically sent to the next tables as
1234 if followed by next; action. The next tables will see the
1235 changes in the packet caused by the connection tracker.
1236 ct_dnat_in_czone;
1238 ct_dnat_in_czone(IP);
1239 ct_dnat_in_czone sends the packet through the common NAT
1240 zone (used for both DNAT and SNAT) in connection tracking
1241 table to unDNAT any packet that was DNATed in the opposite
1242 direction. The packet is then automatically sent to to the
1243 next tables as if followed by next; action. The next tables
1244 will see the changes in the packet caused by the connection
1245 tracker.
1246 ct_dnat_in_czone(IP) sends the packet through the common
1248 NAT zone to change the destination IP address of the packet
1249 to the one provided inside the parentheses and commits the
1250 connection. The packet is then automatically sent to the
1251 next tables as if followed by next; action. The next tables
1252 will see the changes in the packet caused by the connection
1253 tracker.
1254 ct_snat_in_czone;
1256 ct_snat_in_czone(IP);
1257 ct_snat_in_czone sends the packet through the common NAT
1258 zone to unSNAT any packet that was SNATed in the opposite
1259 direction. The packet is automatically sent to the next ta‐
1260 bles as if followed by the next; action. The next tables
1261 will see the changes in the packet caused by the connection
1262 tracker.
1263 ct_snat_in_czone(IP) sends the packet\ through the common
1265 NAT zone to change the source IP address of the packet to
1266 the one provided inside the parenthesis 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 ct_clear;
1273 Clears connection tracking state.
1274 ct_commit_nat;
1276 Applies NAT and commits the connection to the CT. Automati‐
1277 cally moves on to the next table, as if followed by next.
1278 This is very useful for connections that are in related
1279 state for already existing connections and allows the NAT
1280 to be applied to them as well.
1281 clone { action; ... };
1283 Makes a copy of the packet being processed and executes
1284 each action on the copy. Actions following the clone ac‐
1285 tion, if any, apply to the original, unmodified packet.
1286 This can be used as a way to ``save and restore’’ the
1287 packet around a set of actions that may modify it and
1288 should not persist.
1289 arp { action; ... };
1291 Temporarily replaces the IPv4 packet being processed by an
1292 ARP packet and executes each nested action on the ARP
1293 packet. Actions following the arp action, if any, apply to
1294 the original, unmodified packet.
1295 The ARP packet that this action operates on is initialized
1297 based on the IPv4 packet being processed, as follows. These
1298 are default values that the nested actions will probably
1299 want to change:
1300 • eth.src unchanged
1302 • eth.dst unchanged
1304 • eth.type = 0x0806
1306 • arp.op = 1 (ARP request)
1308 • arp.sha copied from eth.src
1310 • arp.spa copied from ip4.src
1312 • arp.tha = 00:00:00:00:00:00
1314 • arp.tpa copied from ip4.dst
1316 The ARP packet has the same VLAN header, if any, as the IP
1318 packet it replaces.
1319 Prerequisite: ip4
1321 get_arp(P, A);
1323 Parameters: logical port string field P, 32-bit IP address
1324 field A.
1325 Looks up A in P’s mac binding table. If an entry is found,
1327 stores its Ethernet address in eth.dst, otherwise stores
1328 00:00:00:00:00:00 in eth.dst.
1329 Example: get_arp(outport, ip4.dst);
1331 put_arp(P, A, E);
1333 Parameters: logical port string field P, 32-bit IP address
1334 field A, 48-bit Ethernet address field E.
1335 Adds or updates the entry for IP address A in logical port
1337 P’s mac binding table, setting its Ethernet address to E.
1338 Example: put_arp(inport, arp.spa, arp.sha);
1340 R = lookup_arp(P, A, M);
1342 Parameters: logical port string field P, 32-bit IP address
1343 field A, 48-bit MAC address field M.
1344 Result: stored to a 1-bit subfield R.
1346 Looks up A and M in P’s mac binding table. If an entry is
1348 found, stores 1 in the 1-bit subfield R, else 0.
1349 Example: reg0[0] = lookup_arp(inport, arp.spa, arp.sha);
1351 R = lookup_arp_ip(P, A);
1353 Parameters: logical port string field P, 32-bit IP address
1354 field A.
1355 Result: stored to a 1-bit subfield R.
1357 Looks up A in P’s mac binding table. If an entry is found,
1359 stores 1 in the 1-bit subfield R, else 0.
1360 Example: reg0[0] = lookup_arp_ip(inport, arp.spa);
1362 P = get_fdb(A);
1364 Parameters:48-bit MAC address field A.
1365 Looks up A in fdb table. If an entry is found, stores the
1367 logical port key to the out parameter P.
1368 Example: outport = get_fdb(eth.src);
1370 put_fdb(P, A);
1372 Parameters: logical port string field P, 48-bit MAC address
1373 field A.
1374 Adds or updates the entry for Ethernet address A in fdb ta‐
1376 ble, setting its logical port key to P.
1377 Example: put_fdb(inport, arp.spa);
1379 R = lookup_fdb(P, A);
1381 Parameters: 48-bit MAC address field M, logical port string
1382 field P.
1383 Result: stored to a 1-bit subfield R.
1385 Looks up A in fdb table. If an entry is found and the the
1387 logical port key is P, P, stores 1 in the 1-bit subfield R,
1388 else 0.
1389 Example: reg0[0] = lookup_fdb(inport, eth.src);
1391 nd_ns { action; ... };
1393 Temporarily replaces the IPv6 packet being processed by an
1394 IPv6 Neighbor Solicitation packet and executes each nested
1395 action on the IPv6 NS packet. Actions following the nd_ns
1396 action, if any, apply to the original, unmodified packet.
1397 The IPv6 NS packet that this action operates on is initial‐
1399 ized based on the IPv6 packet being processed, as follows.
1400 These are default values that the nested actions will prob‐
1401 ably want to change:
1402 • eth.src unchanged
1404 • eth.dst set to IPv6 multicast MAC address
1406 • eth.type = 0x86dd
1408 • ip6.src copied from ip6.src
1410 • ip6.dst set to IPv6 Solicited-Node multicast address
1412 • icmp6.type = 135 (Neighbor Solicitation)
1414 • nd.target copied from ip6.dst
1416 The IPv6 NS packet has the same VLAN header, if any, as the
1418 IP packet it replaces.
1419 Prerequisite: ip6
1421 nd_na { action; ... };
1423 Temporarily replaces the IPv6 neighbor solicitation packet
1424 being processed by an IPv6 neighbor advertisement (NA)
1425 packet and executes each nested action on the NA packet.
1426 Actions following the nd_na action, if any, apply to the
1427 original, unmodified packet.
1428 The NA packet that this action operates on is initialized
1430 based on the IPv6 packet being processed, as follows. These
1431 are default values that the nested actions will probably
1432 want to change:
1433 • eth.dst exchanged with eth.src
1435 • eth.type = 0x86dd
1437 • ip6.dst copied from ip6.src
1439 • ip6.src copied from nd.target
1441 • icmp6.type = 136 (Neighbor Advertisement)
1443 • nd.target unchanged
1445 • nd.sll = 00:00:00:00:00:00
1447 • nd.tll copied from eth.dst
1449 The ND packet has the same VLAN header, if any, as the IPv6
1451 packet it replaces.
1452 Prerequisite: nd_ns
1454 nd_na_router { action; ... };
1456 Temporarily replaces the IPv6 neighbor solicitation packet
1457 being processed by an IPv6 neighbor advertisement (NA)
1458 packet, sets ND_NSO_ROUTER in the RSO flags and executes
1459 each nested action on the NA packet. Actions following the
1460 nd_na_router action, if any, apply to the original, unmodi‐
1461 fied packet.
1462 The NA packet that this action operates on is initialized
1464 based on the IPv6 packet being processed, as follows. These
1465 are default values that the nested actions will probably
1466 want to change:
1467 • eth.dst exchanged with eth.src
1469 • eth.type = 0x86dd
1471 • ip6.dst copied from ip6.src
1473 • ip6.src copied from nd.target
1475 • icmp6.type = 136 (Neighbor Advertisement)
1477 • nd.target unchanged
1479 • nd.sll = 00:00:00:00:00:00
1481 • nd.tll copied from eth.dst
1483 The ND packet has the same VLAN header, if any, as the IPv6
1485 packet it replaces.
1486 Prerequisite: nd_ns
1488 get_nd(P, A);
1490 Parameters: logical port string field P, 128-bit IPv6 ad‐
1491 dress field A.
1492 Looks up A in P’s mac binding table. If an entry is found,
1494 stores its Ethernet address in eth.dst, otherwise stores
1495 00:00:00:00:00:00 in eth.dst.
1496 Example: get_nd(outport, ip6.dst);
1498 put_nd(P, A, E);
1500 Parameters: logical port string field P, 128-bit IPv6 ad‐
1501 dress field A, 48-bit Ethernet address field E.
1502 Adds or updates the entry for IPv6 address A in logical
1504 port P’s mac binding table, setting its Ethernet address to
1505 E.
1506 Example: put_nd(inport, nd.target, nd.tll);
1508 R = lookup_nd(P, A, M);
1510 Parameters: logical port string field P, 128-bit IP address
1511 field A, 48-bit MAC address field M.
1512 Result: stored to a 1-bit subfield R.
1514 Looks up A and M in P’s mac binding table. If an entry is
1516 found, stores 1 in the 1-bit subfield R, else 0.
1517 Example: reg0[0] = lookup_nd(inport, ip6.src, eth.src);
1519 R = lookup_nd_ip(P, A);
1521 Parameters: logical port string field P, 128-bit IP address
1522 field A.
1523 Result: stored to a 1-bit subfield R.
1525 Looks up A in P’s mac binding table. If an entry is found,
1527 stores 1 in the 1-bit subfield R, else 0.
1528 Example: reg0[0] = lookup_nd_ip(inport, ip6.src);
1530 R = put_dhcp_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1532 Parameters: one or more DHCP option/value pairs, which must
1533 include an offerip option (with code 0).
1534 Result: stored to a 1-bit subfield R.
1536 Valid only in the ingress pipeline.
1538 When this action is applied to a DHCP request packet
1540 (DHCPDISCOVER or DHCPREQUEST), it changes the packet into a
1541 DHCP reply (DHCPOFFER or DHCPACK, respectively), replaces
1542 the options by those specified as parameters, and stores 1
1543 in R.
1544 When this action is applied to a non-DHCP packet or a DHCP
1546 packet that is not DHCPDISCOVER or DHCPREQUEST, it leaves
1547 the packet unchanged and stores 0 in R.
1548 The contents of the DHCP_Option table control the DHCP op‐
1550 tion names and values that this action supports.
1551 Example: reg0[0] = put_dhcp_opts(offerip = 10.0.0.2, router
1553 = 10.0.0.1, netmask = 255.255.255.0, dns_server = {8.8.8.8,
1554 7.7.7.7});
1555 R = put_dhcpv6_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1557 Parameters: one or more DHCPv6 option/value pairs.
1558 Result: stored to a 1-bit subfield R.
1560 Valid only in the ingress pipeline.
1562 When this action is applied to a DHCPv6 request packet, it
1564 changes the packet into a DHCPv6 reply, replaces the op‐
1565 tions by those specified as parameters, and stores 1 in R.
1566 When this action is applied to a non-DHCPv6 packet or an
1568 invalid DHCPv6 request packet , it leaves the packet un‐
1569 changed and stores 0 in R.
1570 The contents of the DHCPv6_Options table control the DHCPv6
1572 option names and values that this action supports.
1573 Example: reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4,
1575 server_id = 00:00:00:00:10:02,
1576 dns_server={ae70::1,ae70::2});
1577 set_queue(queue_number);
1579 Parameters: Queue number queue_number, in the range 0 to
1580 61440.
1581 This is a logical equivalent of the OpenFlow set_queue ac‐
1583 tion. It affects packets that egress a hypervisor through a
1584 physical interface. For nonzero queue_number, it configures
1585 packet queuing to match the settings configured for the
1586 Port_Binding with options:qdisc_queue_id matching
1587 queue_number. When queue_number is zero, it resets queuing
1588 to the default strategy.
1589 Example: set_queue(10);
1591 ct_lb;
1593 ct_lb(backends=ip[:port][,...][;
1594 hash_fields=field1,field2,...][; ct_flag]);
1595 With arguments, ct_lb commits the packet to the connection
1596 tracking table and DNATs the packet’s destination IP ad‐
1597 dress (and port) to the IP address or addresses (and op‐
1598 tional ports) specified in the backends. If multiple comma-
1599 separated IP addresses are specified, each is given equal
1600 weight for picking the DNAT address. By default, dp_hash is
1601 used as the OpenFlow group selection method, but if
1602 hash_fields is specified, hash is used as the selection
1603 method, and the fields listed are used as the hash fields.
1604 The ct_flag field represents one of supported flag:
1605 skip_snat or force_snat, this flag will be stored in ct_la‐
1606 bel register.
1607 Without arguments, ct_lb sends the packet to the connection
1609 tracking table to NAT the packets. If the packet is part of
1610 an established connection that was previously committed to
1611 the connection tracker via ct_lb(...), it will automati‐
1612 cally get DNATed to the same IP address as the first packet
1613 in that connection.
1614 Processing automatically moves on to the next table, as if
1616 next; were specified, and later tables act on the packet as
1617 modified by the connection tracker. Connection tracking
1618 state is scoped by the logical port when the action is used
1619 in a flow for a logical switch, so overlapping addresses
1620 may be used. Connection tracking state is scoped by the
1621 logical topology when the action is used in a flow for a
1622 router.
1623 ct_lb_mark;
1625 ct_lb_mark(backends=ip[:port][,...][;
1626 hash_fields=field1,field2,...][; ct_flag]);
1627 Same as ct_lb, except that it internally uses ct_mark to
1628 store the NAT flag, while ct_lb uses ct_label for the same
1629 purpose.
1630 R = dns_lookup();
1632 Parameters: No parameters.
1633 Result: stored to a 1-bit subfield R.
1635 Valid only in the ingress pipeline.
1637 When this action is applied to a valid DNS request (a UDP
1639 packet typically directed to port 53), it attempts to re‐
1640 solve the query using the contents of the DNS table. If it
1641 is successful, it changes the packet into a DNS reply and
1642 stores 1 in R. If the action is applied to a non-DNS
1643 packet, an invalid DNS request packet, or a valid DNS re‐
1644 quest for which the DNS table does not supply an answer, it
1645 leaves the packet unchanged and stores 0 in R.
1646 Regardless of success, the action does not make any of the
1648 changes to the flow that are necessary to direct the packet
1649 back to the requester. The logical pipeline can implement
1650 this behavior with matches and actions in later tables.
1651 Example: reg0[3] = dns_lookup();
1653 Prerequisite: udp
1655 R = put_nd_ra_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1657 Parameters: The following IPv6 ND Router Advertisement op‐
1658 tion/value pairs as defined in RFC 4861.
1659 • addr_mode
1661 Mandatory parameter which specifies the address mode
1663 flag to be set in the RA flag options field. The
1664 value of this option is a string and the following
1665 values can be defined - "slaac", "dhcpv6_stateful"
1666 and "dhcpv6_stateless".
1667 • slla
1669 Mandatory parameter which specifies the link-layer
1671 address of the interface from which the Router Ad‐
1672 vertisement is sent.
1673 • mtu
1675 Optional parameter which specifies the MTU.
1677 • prefix
1679 Optional parameter which should be specified if the
1681 addr_mode is "slaac" or "dhcpv6_stateless". The
1682 value should be an IPv6 prefix which will be used
1683 for stateless IPv6 address configuration. This op‐
1684 tion can be defined multiple times.
1685 Result: stored to a 1-bit subfield R.
1687 Valid only in the ingress pipeline.
1689 When this action is applied to an IPv6 Router solicitation
1691 request packet, it changes the packet into an IPv6 Router
1692 Advertisement reply and adds the options specified in the
1693 parameters, and stores 1 in R.
1694 When this action is applied to a non-IPv6 Router solicita‐
1696 tion packet or an invalid IPv6 request packet , it leaves
1697 the packet unchanged and stores 0 in R.
1698 Example: reg0[3] = put_nd_ra_opts(addr_mode = "slaac", slla
1700 = 00:00:00:00:10:02, prefix = aef0::/64, mtu = 1450);
1701 set_meter(rate);
1703 set_meter(rate, burst);
1704 Parameters: rate limit int field rate in kbps, burst rate
1705 limits int field burst in kbps.
1706 This action sets the rate limit for a flow.
1708 Example: set_meter(100, 1000);
1710 R = check_pkt_larger(L)
1712 Parameters: packet length L to check for in bytes.
1713 Result: stored to a 1-bit subfield R.
1715 This is a logical equivalent of the OpenFlow
1717 check_pkt_larger action. If the packet is larger than the
1718 length specified in L, it stores 1 in the subfield R.
1719 Example: reg0[6] = check_pkt_larger(1000);
1721 log(key=value, ...);
1723 Causes ovn-controller to log the packet on the chassis
1724 that processes it. Packet logging currently uses the same
1725 logging mechanism as other Open vSwitch and OVN messages,
1726 which means that whether and where log messages appear
1727 depends on the local logging configuration that can be
1728 configured with ovs-appctl, etc.
1729 The log action takes zero or more of the following key-
1731 value pair arguments that control what is logged:
1732 name=string
1734 An optional name for the ACL. The string is cur‐
1735 rently limited to 64 bytes.
1736 severity=level
1738 Indicates the severity of the event. The level is
1739 one of following (from more to less serious):
1740 alert, warning, notice, info, or debug. If a
1741 severity is not provided, the default is info.
1742 verdict=value
1744 The verdict for packets matching the flow. The
1745 value must be one of allow, deny, or reject.
1746 meter=string
1748 An optional rate-limiting meter to be applied to
1749 the logs. The string should reference a name entry
1750 from the Meter table. The only meter action that
1751 is appropriate is drop.
1752 fwd_group(liveness=bool, childports=port, ...);
1754 Parameters: optional liveness, either true or false, de‐
1755 faulting to false; childports, a comma-delimited list of
1756 strings denoting logical ports to load balance across.
1757 Load balance traffic to one or more child ports in a log‐
1759 ical switch. ovn-controller translates the fwd_group into
1760 an OpenFlow group with one bucket for each child port. If
1761 liveness=true is specified, it also integrates the bucket
1762 selection with BFD status on the tunnel interface corre‐
1763 sponding to child port.
1764 Example: fwd_group(liveness=true, childports="p1", "p2");
1766 icmp4 { action; ... };
1768 icmp4_error { action; ... };
1769 Temporarily replaces the IPv4 packet being processed by an
1770 ICMPv4 packet and executes each nested action on the ICMPv4
1771 packet. Actions following these actions, if any, apply to
1772 the original, unmodified packet.
1773 The ICMPv4 packet that these actions operates on is ini‐
1775 tialized based on the IPv4 packet being processed, as fol‐
1776 lows. These are default values that the nested actions will
1777 probably want to change. Ethernet and IPv4 fields not
1778 listed here are not changed:
1779 • ip.proto = 1 (ICMPv4)
1781 • ip.frag = 0 (not a fragment)
1783 • ip.ttl = 255
1785 • icmp4.type = 3 (destination unreachable)
1787 • icmp4.code = 1 (host unreachable)
1789 icmp4_error action is expected to be used to generate an
1791 ICMPv4 packet in response to an error in original IP
1792 packet. When this action generates the ICMPv4 packet, it
1793 also copies the original IP datagram following the ICMPv4
1794 header as per RFC 1122: 3.2.2.
1795 Prerequisite: ip4
1797 icmp6 { action; ... };
1799 icmp6_error { action; ... };
1800 Temporarily replaces the IPv6 packet being processed by an
1801 ICMPv6 packet and executes each nested action on the ICMPv6
1802 packet. Actions following the icmp6 action, if any, apply
1803 to the original, unmodified packet.
1804 The ICMPv6 packet that this action operates on is initial‐
1806 ized based on the IPv6 packet being processed, as follows.
1807 These are default values that the nested actions will prob‐
1808 ably want to change. Ethernet and IPv6 fields not listed
1809 here are not changed:
1810 • ip.proto = 58 (ICMPv6)
1812 • ip.ttl = 255
1814 • icmp6.type = 1 (destination unreachable)
1816 • icmp6.code = 1 (administratively prohibited)
1818 icmp6_error action is expected to be used to generate an
1820 ICMPv6 packet in response to an error in original IPv6
1821 packet.
1822 Prerequisite: ip6
1824 tcp_reset;
1826 This action transforms the current TCP packet according to
1827 the following pseudocode:
1828 if (tcp.ack) {
1830 tcp.seq = tcp.ack;
1831 } else {
1832 tcp.ack = tcp.seq + length(tcp.payload);
1833 tcp.seq = 0;
1834 }
1835 tcp.flags = RST;
1836 Then, the action drops all TCP options and payload data,
1838 and updates the TCP checksum. IP ttl is set to 255.
1839 Prerequisite: tcp
1841 reject { action; ... };
1843 If the original packet is IPv4 or IPv6 TCP packet, it re‐
1844 places it with IPv4 or IPv6 TCP RST packet and executes the
1845 inner actions. Otherwise it replaces it with an ICMPv4 or
1846 ICMPv6 packet and executes the inner actions.
1847 The inner actions should not attempt to swap eth source
1849 with eth destination and IP source with IP destination as
1850 this action implicitly does that.
1851 trigger_event;
1853 This action is used to allow ovs-vswitchd to report CMS re‐
1854 lated events writing them in Controller_Event table. It is
1855 possible to associate a meter to a each event in order to
1856 not overload pinctrl thread under heavy load; each meter is
1857 identified though a defined naming convention. Supported
1858 events:
1859 • empty_lb_backends. This event is raised if a re‐
1861 ceived packet is destined for a load balancer VIP
1862 that has no configured backend destinations. For
1863 this event, the event info includes the load bal‐
1864 ancer VIP, the load balancer UUID, and the transport
1865 protocol. Associated meter: event-elb
1866 igmp;
1868 This action sends the packet to ovn-controller for multi‐
1869 cast snooping.
1870 Prerequisite: igmp
1872 bind_vport(V, P);
1874 Parameters: logical port string field V of type virtual,
1875 logical port string field P.
1876 Binds the virtual logical port V and sets the chassis col‐
1878 umn and virtual_parent of the table Port_Binding. vir‐
1879 tual_parent is set to P.
1880 handle_svc_check(P);
1882 Parameters: logical port string field P.
1883 Handles the service monitor reply received from the VIF of
1885 the logical port P. ovn-controller periodically sends out
1886 the service monitor packets for the services configured in
1887 the Service_Monitor table and this action updates the sta‐
1888 tus of those services.
1889 Example: handle_svc_check(inport);
1891 handle_dhcpv6_reply;
1893 Handle DHCPv6 prefix delegation advertisements/replies from
1894 a IPv6 delegation server. ovn-controller will add an entry
1895 ipv6_ra_pd_list in the options table for each prefix re‐
1896 ceived from the delegation server
1897 R = select(N1[=W1], N2[=W2], ...);
1899 Parameters: Integer N1, N2..., with optional weight W1, W2,
1900 ...
1901 Result: stored to a logical field or subfield R.
1903 Select from a list of integers N1, N2..., each within the
1905 range 0 ~ 65535, and store the selected one in the field R.
1906 There must be 2 or more integers listed, each with an op‐
1907 tional weight, which is an integer within the range 1 ~
1908 65535. If weight is not specified, it defaults to 100. The
1909 selection method is based on the 5-tuple hash of packet
1910 header.
1911 Processing automatically moves on to the next table, as if
1913 next; were specified. The select action must be put as the
1914 last action of the logical flow when there are multiple ac‐
1915 tions (actions put after select will not take effect).
1916 Example: reg8[16..31] = select(1=20, 2=30, 3=50);
1918 handle_dhcpv6_reply;
1920 This action is used to parse DHCPv6 replies from IPv6 Dele‐
1921 gation Router and managed IPv6 Prefix delegation state ma‐
1922 chine
1923 R = chk_lb_hairpin();
1925 This action checks if the packet under consideration was
1926 destined to a load balancer VIP and it is hairpinned, i.e.,
1927 after load balancing the destination IP matches the source
1928 IP. If it is so, then the 1-bit destination register R is
1929 set to 1.
1930 R = chk_lb_hairpin_reply();
1932 This action checks if the packet under consideration is
1933 from one of the backend IP of a load balancer VIP and the
1934 destination IP is the load balancer VIP. If it is so, then
1935 the 1-bit destination register R is set to 1.
1936 R = ct_snat_to_vip;
1938 This action sends the packet through the SNAT zone to
1939 change the source IP address of the packet to the load bal‐
1940 ancer VIP if the original destination IP was load balancer
1941 VIP and commits the connection. This action applies suc‐
1942 cessfully only for the hairpinned traffic i.e if the action
1943 chk_lb_hairpin returned success. This action doesn’t take
1944 any arguments and it determines the SNAT IP internally. The
1945 packet is not automatically sent to the next table. The
1946 caller has to execute the next; action explicitly after
1947 this action to advance the packet to the next stage.
1948 R = check_in_port_sec();
1950 This action checks if the packet under consideration passes
1951 the inport port security checks. If the packet fails the
1952 port security checks, then 1 is stored in the destination
1953 register R. Else 0 is stored. The port security values to
1954 check are retrieved from the the inport logical port.
1955 This action should be used in the ingress logical switch
1957 pipeline.
1958 Example: reg8[0..7] = check_in_port_sec();
1960 R = check_out_port_sec();
1962 This action checks if the packet under consideration passes
1963 the outport port security checks. If the packet fails the
1964 port security checks, then 1 is stored in the destination
1965 register R. Else 0 is stored. The port security values to
1966 check are retrieved from the the outport logical port.
1967 This action should be used in the egress logical switch
1969 pipeline.
1970 Example: reg8[0..7] = check_out_port_sec();
1972 commit_ecmp_nh(ipv6);
1974 Parameters: IPv4/IPv6 traffic.
1975 This action translates to an openflow "learn" action that
1977 inserts two new flows in tables 76 and 77.
1978 • Match on the the 5-tuple and the expected next-hop
1980 mac address in table 76: nw_src=ip0, nw_dst=ip1,
1981 ip_proto,tp_src=l4_port0,
1982 tp_dst=l4_port1,dl_src=ethaddr and set reg9[5].
1983 • Match on the 5-tuple in table 77: nw_src=ip1,
1985 nw_dst=ip0, ip_proto, tp_src=l4_port1,
1986 tp_dst=l4_port0 and set reg9[5] to 1
1987 This action is applied if the packet arrives via ECMP route
1989 or if it is routed via an ECMP route
1990 R = check_ecmp_nh_mac();
1992 This action checks if the packet under consideration
1993 matches any flow in table 76. If it is so, then the 1-bit
1994 destination register R is set to 1.
1995 R = check_ecmp_nh();
1997 This action checks if the packet under consideration
1998 matches the any flow in table 77. If it is so, then the
1999 1-bit destination register R is set to 1.
2000 commit_lb_aff(vip, backend, proto, timeout); Parameters:
2002 load-balancer virtual ip:port vip, load-balancer backend
2003 ip:port backend, load-balancer protocol proto, affinity
2004 timeout timeout.
2005 This action translates to an openflow "learn" action that
2007 inserts a new flow in table 78.
2008 • Match on the 4-tuple in table 78: nw_src=ip client,
2010 nw_dst=vip ip, ip_proto, tp_dst=vip port and set
2011 reg9[6] to 1, reg4 and reg8 to backend ip and port
2012 respectively. For IPv6 register xxreg1 is used to
2013 store the backend ip.
2014 This action is applied for new connections received by a
2016 specific load-balacer with affinity timeout configured.
2017 R = chk_lb_aff();
2019 This action checks if the packet under consideration
2020 matches any flow in table 78. If it is so, then the 1-bit
2021 destination register R is set to 1.
2022 sample(probability=packets, ...)
2024 This action causes the matched traffic to be sampled using
2025 IPFIX protocol. More information about how per-flow IPFIX
2026 sampling works in OVS can be found in ovs-actions(7) and
2027 ovs-vswitchd.conf.db(5).
2028 In order to reliably identify each sampled packet when it
2030 is received by the IPFIX collector, this action sets the
2031 content of the ObservationDomainID and ObservationPointID
2032 IPFIX fields (see argument description below).
2033 The following key-value arguments are supported:
2035 probability=packets
2037 The number of sampled packets out of 65535. It must
2038 be greater or equal to 1.
2039 collector_set=id
2041 The unsigned 32-bit integer identifier of the sample
2042 collector to send sampled packets to. It must match
2043 the value configured in the Flow_Sample_Collec‐
2044 tor_Set Table in OVS. Defaults to 0.
2045 obs_domain=id
2047 An unsigned 8-bit integer that identifies the sam‐
2048 pling application. It will be placed in the 8 most
2049 significant bits of the ObservationDomainID field of
2050 IPFIX samples. The 24 less significant bits will be
2051 automatically filled in with the datapath key. De‐
2052 faults to 0.
2053 obs_point=id
2055 An unsigned 32-bit integer to be used as Obsserva‐
2056 tionPointID or the string @cookie to indicate that
2057 the first 32 bits of the Logical_Flow’s UUID shall
2058 be used instead.
2059 tags: map of string-string pairs
2061 Key-value pairs that provide additional information to help ovn-
2062 controller processing the logical flow. Below are the tags used
2063 by ovn-controller.
2064 in_out_port
2066 In the logical flow’s "match" column, if a logical port P
2067 is compared with "inport" and the logical flow is on a
2068 logical switch ingress pipeline, or if P is compared with
2069 "outport" and the logical flow is on a logical switch
2070 egress pipeline, and the expression is combined with
2071 other expressions (if any) using the operator &&, then
2072 the port P should be added as the value in this tag. If
2073 there are multiple logical ports meeting this criteria,
2074 one of them can be added. ovn-controller uses this infor‐
2075 mation to skip parsing flows that are not needed on the
2076 chassis. Failing to add the tag will affect efficiency,
2077 while adding wrong value will affect correctness.
2078 controller_meter: optional string
2080 The name of the meter in table Meter to be used for all packets
2081 that the logical flow might send to ovn-controller.
2082 external_ids : stage-name: optional string
2084 Human-readable name for this flow’s stage in the pipeline.
2085 external_ids : stage-hint: optional string, containing an uuid
2087 UUID of a OVN_Northbound record that caused this logical flow to
2088 be created. Currently used only for attribute of logical flows
2089 to northbound ACL records.
2090 external_ids : source: optional string
2092 Source file and line number of the code that added this flow to
2093 the pipeline.
2094 Common Columns:
2096 The overall purpose of these columns is described under Common Columns
2098 at the beginning of this document.
2099 external_ids: map of string-string pairs
2101
2103 Each row in this table represents a group of logical datapaths refer‐
2104 enced by the logical_dp_group column in the Logical_Flow table.
2105 Summary:
2107 datapaths set of weak reference to Datapath_Bind‐
2108 ings
2109 Details:
2111 datapaths: set of weak reference to Datapath_Bindings
2112 List of Datapath_Binding entries.
2113
2115 The rows in this table define multicast groups of logical ports. Multi‐
2116 cast groups allow a single packet transmitted over a tunnel to a hyper‐
2117 visor to be delivered to multiple VMs on that hypervisor, which uses
2118 bandwidth more efficiently.
2119 Each row in this table defines a logical multicast group numbered tun‐
2121 nel_key within datapath, whose logical ports are listed in the ports
2122 column.
2123 Summary:
2125 datapath Datapath_Binding
2126 tunnel_key integer, in range 32,768 to 65,535
2127 name string
2128 ports set of weak reference to Port_Bindings
2129 Details:
2131 datapath: Datapath_Binding
2132 The logical datapath in which the multicast group resides.
2133 tunnel_key: integer, in range 32,768 to 65,535
2135 The value used to designate this logical egress port in tunnel
2136 encapsulations. An index forces the key to be unique within the
2137 datapath. The unusual range ensures that multicast group IDs do
2138 not overlap with logical port IDs.
2139 name: string
2141 The logical multicast group’s name. An index forces the name to
2142 be unique within the datapath. Logical flows in the ingress
2143 pipeline may output to the group just as for individual logical
2144 ports, by assigning the group’s name to outport and executing an
2145 output action.
2146 Multicast group names and logical port names share a single
2148 namespace and thus should not overlap (but the database schema
2149 cannot enforce this). To try to avoid conflicts, ovn-northd uses
2150 names that begin with _MC_.
2151 ports: set of weak reference to Port_Bindings
2153 The logical ports included in the multicast group. All of these
2154 ports must be in the datapath logical datapath (but the database
2155 schema cannot enforce this).
2156
2158 Each row in this table represents a mirror that can be used for port
2159 mirroring. These mirrors are referenced by the mirror_rules column in
2160 the Port_Binding table.
2161 Summary:
2163 name string (must be unique within table)
2164 filter string, either from-lport or to-lport
2165 sink string
2166 type string, either erspan or gre
2167 index integer
2168 external_ids map of string-string pairs
2169 Details:
2171 name: string (must be unique within table)
2172 Represents the name of the mirror.
2173 filter: string, either from-lport or to-lport
2175 The value of this field represents selection criteria of the
2176 mirror.
2177 sink: string
2179 The value of this field represents the destination/sink of the
2180 mirror.
2181 type: string, either erspan or gre
2183 The value of this field represents the type of the tunnel used
2184 for sending the mirrored packets
2185 index: integer
2187 The value of this field represents the key/idx depending on the
2188 tunnel type configured
2189 external_ids: map of string-string pairs
2191 See External IDs at the beginning of this document.
2192
2194 Each row in this table represents a meter that can be used for QoS or
2195 rate-limiting.
2196 Summary:
2198 name string (must be unique within table)
2199 unit string, either kbps or pktps
2200 bands set of 1 or more Meter_Bands
2201 Details:
2203 name: string (must be unique within table)
2204 A name for this meter.
2205 Names that begin with "__" (two underscores) are reserved for
2207 OVN internal use and should not be added manually.
2208 unit: string, either kbps or pktps
2210 The unit for rate and burst_rate parameters in the bands entry.
2211 kbps specifies kilobits per second, and pktps specifies packets
2212 per second.
2213 bands: set of 1 or more Meter_Bands
2215 The bands associated with this meter. Each band specifies a rate
2216 above which the band is to take the action action. If multiple
2217 bands’ rates are exceeded, then the band with the highest rate
2218 among the exceeded bands is selected.
2219
2221 Each row in this table represents a meter band which specifies the rate
2222 above which the configured action should be applied. These bands are
2223 referenced by the bands column in the Meter table.
2224 Summary:
2226 action string, must be drop
2227 rate integer, in range 1 to 4,294,967,295
2228 burst_size integer, in range 0 to 4,294,967,295
2229 Details:
2231 action: string, must be drop
2232 The action to execute when this band matches. The only supported
2233 action is drop.
2234 rate: integer, in range 1 to 4,294,967,295
2236 The rate limit for this band, in kilobits per second or bits per
2237 second, depending on whether the parent Meter entry’s unit col‐
2238 umn specified kbps or pktps.
2239 burst_size: integer, in range 0 to 4,294,967,295
2241 The maximum burst allowed for the band in kilobits or packets,
2242 depending on whether kbps or pktps was selected in the parent
2243 Meter entry’s unit column. If the size is zero, the switch is
2244 free to select some reasonable value depending on its configura‐
2245 tion.
2246
2248 Each row in this table represents a logical datapath, which implements
2249 a logical pipeline among the ports in the Port_Binding table associated
2250 with it. In practice, the pipeline in a given logical datapath imple‐
2251 ments either a logical switch or a logical router.
2252 The main purpose of a row in this table is provide a physical binding
2254 for a logical datapath. A logical datapath does not have a physical lo‐
2255 cation, so its physical binding information is limited: just tun‐
2256 nel_key. The rest of the data in this table does not affect packet for‐
2257 warding.
2258 Summary:
2260 tunnel_key integer, in range 1 to 16,777,215 (must
2261 be unique within table)
2262 load_balancers set of uuids
2263 OVN_Northbound Relationship:
2264 external_ids : logical-switch
2265 optional string, containing an uuid
2266 external_ids : logical-router
2267 optional string, containing an uuid
2268 external_ids : interconn-ts
2269 optional string
2270 Naming:
2271 external_ids : name optional string
2272 external_ids : name2 optional string
2273 Common Columns:
2274 external_ids map of string-string pairs
2275 Details:
2277 tunnel_key: integer, in range 1 to 16,777,215 (must be unique within
2278 table)
2279 The tunnel key value to which the logical datapath is bound. The
2280 Tunnel Encapsulation section in ovn-architecture(7) describes
2281 how tunnel keys are constructed for each supported encapsula‐
2282 tion.
2283 load_balancers: set of uuids
2285 Not used anymore; kept for backwards compatibility of the
2286 schema.
2287 OVN_Northbound Relationship:
2289 Each row in Datapath_Binding is associated with some logical datapath.
2291 ovn-northd uses these keys to track the association of a logical data‐
2292 path with concepts in the OVN_Northbound database.
2293 external_ids : logical-switch: optional string, containing an uuid
2295 For a logical datapath that represents a logical switch,
2296 ovn-northd stores in this key the UUID of the corresponding Log‐
2297 ical_Switch row in the OVN_Northbound database.
2298 external_ids : logical-router: optional string, containing an uuid
2300 For a logical datapath that represents a logical router,
2301 ovn-northd stores in this key the UUID of the corresponding Log‐
2302 ical_Router row in the OVN_Northbound database.
2303 external_ids : interconn-ts: optional string
2305 For a logical datapath that represents a logical switch that
2306 represents a transit switch for interconnection, ovn-northd
2307 stores in this key the value of the same interconn-ts key of the
2308 external_ids column of the corresponding Logical_Switch row in
2309 the OVN_Northbound database.
2310 Naming:
2312 ovn-northd copies these from the name fields in the OVN_Northbound
2314 database, either from name and external_ids:neutron:router_name in the
2315 Logical_Router table or from name and external_ids:neutron:network_name
2316 in the Logical_Switch table.
2317 external_ids : name: optional string
2319 A name for the logical datapath.
2320 external_ids : name2: optional string
2322 Another name for the logical datapath.
2323 Common Columns:
2325 The overall purpose of these columns is described under Common Columns
2327 at the beginning of this document.
2328 external_ids: map of string-string pairs
2330
2332 Each row in this table binds a logical port to a realization. For most
2333 logical ports, this means binding to some physical location, for exam‐
2334 ple by binding a logical port to a VIF that belongs to a VM running on
2335 a particular hypervisor. Other logical ports, such as logical patch
2336 ports, can be realized without a specific physical location, but their
2337 bindings are still expressed through rows in this table.
2338 For every Logical_Switch_Port record in OVN_Northbound database,
2340 ovn-northd creates a record in this table. ovn-northd populates and
2341 maintains every column except the chassis and virtual_parent columns,
2342 which it leaves empty in new records.
2343 ovn-controller/ovn-controller-vtep populates the chassis column for the
2345 records that identify the logical ports that are located on its hyper‐
2346 visor/gateway, which ovn-controller/ovn-controller-vtep in turn finds
2347 out by monitoring the local hypervisor’s Open_vSwitch database, which
2348 identifies logical ports via the conventions described in Integra‐
2349 tionGuide.rst. (The exceptions are for Port_Binding records with type
2350 of l3gateway, whose locations are identified by ovn-northd via the op‐
2351 tions:l3gateway-chassis column in this table. ovn-controller is still
2352 responsible to populate the chassis column.)
2353 ovn-controller also populates the virtual_parent column of records
2355 whose type is virtual.
2356 When a chassis shuts down gracefully, it should clean up the chassis
2358 column that it previously had populated. (This is not critical because
2359 resources hosted on the chassis are equally unreachable regardless of
2360 whether their rows are present.) To handle the case where a VM is shut
2361 down abruptly on one chassis, then brought up again on a different one,
2362 ovn-controller/ovn-controller-vtep must overwrite the chassis column
2363 with new information.
2364 Summary:
2366 Core Features:
2367 datapath Datapath_Binding
2368 logical_port string (must be unique within table)
2369 encap optional weak reference to Encap
2370 additional_encap set of weak reference to Encaps
2371 chassis optional weak reference to Chassis
2372 additional_chassis set of weak reference to Chassis
2373 gateway_chassis set of Gateway_Chassises
2374 ha_chassis_group optional HA_Chassis_Group
2375 up optional boolean
2376 tunnel_key integer, in range 1 to 32,767
2377 mac set of strings
2378 port_security set of strings
2379 type string
2380 requested_chassis optional weak reference to Chassis
2381 requested_additional_chassis
2382 set of weak reference to Chassis
2383 mirror_rules set of weak reference to Mirrors
2384 Patch Options:
2385 options : peer optional string
2386 nat_addresses set of strings
2387 L3 Gateway Options:
2388 options : peer optional string
2389 options : l3gateway-chassis
2390 optional string
2391 nat_addresses set of strings
2392 Localnet Options:
2393 options : network_name optional string
2394 tag optional integer, in range 1 to 4,095
2395 L2 Gateway Options:
2396 options : network_name optional string
2397 options : l2gateway-chassis
2398 optional string
2399 tag optional integer, in range 1 to 4,095
2400 VTEP Options:
2401 options : vtep-physical-switch
2402 optional string
2403 options : vtep-logical-switch
2404 optional string
2405 VMI (or VIF) Options:
2406 options : requested-chassis
2407 optional string
2408 options : activation-strategy
2409 optional string
2410 options : additional-chassis-activated
2411 optional string
2412 options : iface-id-ver optional string
2413 options : qos_min_rate optional string
2414 options : qos_max_rate optional string
2415 options : qos_burst optional string
2416 options : qdisc_queue_id optional string, containing an integer,
2417 in range 1 to 61,440
2418 Distributed Gateway Port Options:
2419 options : chassis-redirect-port
2420 optional string
2421 Chassis Redirect Options:
2422 options : distributed-port optional string
2423 options : redirect-type optional string
2424 options : always-redirect optional string
2425 Nested Containers:
2426 parent_port optional string
2427 tag optional integer, in range 1 to 4,095
2428 Virtual ports:
2429 virtual_parent optional string
2430 Naming:
2431 external_ids : name optional string
2432 Common Columns:
2433 external_ids map of string-string pairs
2434 Details:
2436 Core Features:
2437 datapath: Datapath_Binding
2439 The logical datapath to which the logical port belongs.
2440 logical_port: string (must be unique within table)
2442 A logical port. For a logical switch port, this is taken from
2443 name in the OVN_Northbound database’s Logical_Switch_Port table.
2444 For a logical router port, this is taken from name in the
2445 OVN_Northbound database’s Logical_Router_port table. (This means
2446 that logical switch ports and router port names must not share
2447 names in an OVN deployment.) OVN does not prescribe a particular
2448 format for the logical port ID.
2449 encap: optional weak reference to Encap
2451 Points to preferred encapsulation configuration to transmit log‐
2452 ical dataplane packets to this chassis. The entry is reference
2453 to a Encap record.
2454 additional_encap: set of weak reference to Encaps
2456 Points to preferred encapsulation configuration to transmit log‐
2457 ical dataplane packets to this additional chassis. The entry is
2458 reference to a Encap record. See also additional_chassis.
2459 chassis: optional weak reference to Chassis
2461 The meaning of this column depends on the value of the type col‐
2462 umn. This is the meaning for each type
2463 (empty string)
2465 The physical location of the logical port. To success‐
2466 fully identify a chassis, this column must be a Chassis
2467 record. This is populated by ovn-controller.
2468 vtep The physical location of the hardware_vtep gateway. To
2470 successfully identify a chassis, this column must be a
2471 Chassis record. This is populated by ovn-controller-vtep.
2472 localnet
2474 Always empty. A localnet port is realized on every chas‐
2475 sis that has connectivity to the corresponding physical
2476 network.
2477 localport
2479 Always empty. A localport port is present on every chas‐
2480 sis.
2481 l3gateway
2483 The physical location of the L3 gateway. To successfully
2484 identify a chassis, this column must be a Chassis record.
2485 This is populated by ovn-controller based on the value of
2486 the options:l3gateway-chassis column in this table.
2487 l2gateway
2489 The physical location of this L2 gateway. To successfully
2490 identify a chassis, this column must be a Chassis record.
2491 This is populated by ovn-controller based on the value of
2492 the options:l2gateway-chassis column in this table.
2493 additional_chassis: set of weak reference to Chassis
2495 The meaning of this column is the same as for the chassis. The
2496 column is used to track an additional physical location of the
2497 logical port. Used with regular (empty type) port bindings.
2498 gateway_chassis: set of Gateway_Chassises
2500 A list of Gateway_Chassis.
2501 This should only be populated for ports with type set to chas‐
2503 sisredirect. This column defines the list of chassis used as
2504 gateways where traffic will be redirected through.
2505 ha_chassis_group: optional HA_Chassis_Group
2507 This should only be populated for ports with type set to chas‐
2508 sisredirect. This column defines the HA chassis group with a
2509 list of HA chassis used as gateways where traffic will be redi‐
2510 rected through.
2511 up: optional boolean
2513 This is set to true whenever all OVS flows required by this
2514 Port_Binding have been installed. This is populated by ovn-con‐
2515 troller.
2516 tunnel_key: integer, in range 1 to 32,767
2518 A number that represents the logical port in the key (e.g. STT
2519 key or Geneve TLV) field carried within tunnel protocol packets.
2520 The tunnel ID must be unique within the scope of a logical data‐
2522 path.
2523 mac: set of strings
2525 This column is a misnomer as it may contain MAC addresses and IP
2526 addresses. It is copied from the addresses column in the Logi‐
2527 cal_Switch_Port table in the Northbound database. It follows the
2528 same format as that column.
2529 port_security: set of strings
2531 This column controls the addresses from which the host attached
2532 to the logical port (``the host’’) is allowed to send packets
2533 and to which it is allowed to receive packets. If this column is
2534 empty, all addresses are permitted.
2535 It is copied from the port_security column in the Logi‐
2537 cal_Switch_Port table in the Northbound database. It follows the
2538 same format as that column.
2539 type: string
2541 A type for this logical port. Logical ports can be used to model
2542 other types of connectivity into an OVN logical switch. The fol‐
2543 lowing types are defined:
2544 (empty string)
2546 VM (or VIF) interface.
2547 patch One of a pair of logical ports that act as if connected
2549 by a patch cable. Useful for connecting two logical data‐
2550 paths, e.g. to connect a logical router to a logical
2551 switch or to another logical router.
2552 l3gateway
2554 One of a pair of logical ports that act as if connected
2555 by a patch cable across multiple chassis. Useful for con‐
2556 necting a logical switch with a Gateway router (which is
2557 only resident on a particular chassis).
2558 localnet
2560 A connection to a locally accessible network from
2561 ovn-controller instances that have a corresponding bridge
2562 mapping. A logical switch can have multiple localnet
2563 ports attached. This type is used to model direct connec‐
2564 tivity to existing networks. In this case, each chassis
2565 should have a mapping for one of the physical networks
2566 only. Note: nothing said above implies that a chassis
2567 cannot be plugged to multiple physical networks as long
2568 as they belong to different switches.
2569 localport
2571 A connection to a local VIF. Traffic that arrives on a
2572 localport is never forwarded over a tunnel to another
2573 chassis. These ports are present on every chassis and
2574 have the same address in all of them. This is used to
2575 model connectivity to local services that run on every
2576 hypervisor.
2577 l2gateway
2579 An L2 connection to a physical network. The chassis this
2580 Port_Binding is bound to will serve as an L2 gateway to
2581 the network named by options:network_name.
2582 vtep A port to a logical switch on a VTEP gateway chassis. In
2584 order to get this port correctly recognized by the OVN
2585 controller, the options:vtep-physical-switch and op‐
2586 tions:vtep-logical-switch must also be defined.
2587 chassisredirect
2589 A logical port that represents a particular instance,
2590 bound to a specific chassis, of an otherwise distributed
2591 parent port (e.g. of type patch). A chassisredirect port
2592 should never be used as an inport. When an ingress pipe‐
2593 line sets the outport, it may set the value to a logical
2594 port of type chassisredirect. This will cause the packet
2595 to be directed to a specific chassis to carry out the
2596 egress pipeline. At the beginning of the egress pipeline,
2597 the outport will be reset to the value of the distributed
2598 port.
2599 virtual
2601 Represents a logical port with an virtual ip. This vir‐
2602 tual ip can be configured on a logical port (which is re‐
2603 ferred as virtual parent).
2604 requested_chassis: optional weak reference to Chassis
2606 This column exists so that the ovn-controller can effectively
2607 monitor all Port_Binding records destined for it, and is a sup‐
2608 plement to the options:requested-chassis option. The option is
2609 still required so that the ovn-controller can check the CMS in‐
2610 tent when the chassis pointed to does not currently exist, which
2611 for example occurs when the ovn-controller is stopped without
2612 passing the -restart argument. This column must be a Chassis
2613 record. This is populated by ovn-northd when the options:re‐
2614 quested-chassis is defined and contains a string matching the
2615 name or hostname of an existing chassis. See also requested_ad‐
2616 ditional_chassis.
2617 requested_additional_chassis: set of weak reference to Chassis
2619 This column exists so that the ovn-controller can effectively
2620 monitor all Port_Binding records destined for it, and is a sup‐
2621 plement to the options:requested-chassis option when multiple
2622 chassis are listed. This column must be a list of Chassis
2623 records. This is populated by ovn-northd when the options:re‐
2624 quested-chassis is defined as a list of chassis names or host‐
2625 names. See also requested_chassis.
2626 mirror_rules: set of weak reference to Mirrors
2628 Mirror rules that apply to the port binding. Please see the Mir‐
2629 ror table.
2630 Patch Options:
2632 These options apply to logical ports with type of patch.
2634 options : peer: optional string
2636 The logical_port in the Port_Binding record for the other side
2637 of the patch. The named logical_port must specify this logi‐
2638 cal_port in its own peer option. That is, the two patch logical
2639 ports must have reversed logical_port and peer values.
2640 nat_addresses: set of strings
2642 MAC address followed by a list of SNAT and DNAT external IP ad‐
2643 dresses, followed by is_chassis_resident("lport"), where lport
2644 is the name of a logical port on the same chassis where the cor‐
2645 responding NAT rules are applied. This is used to send gratu‐
2646 itous ARPs for SNAT and DNAT external IP addresses via localnet,
2647 from the chassis where lport resides. Example: 80:fa:5b:06:72:b7
2648 158.36.44.22 158.36.44.24 is_chassis_resident("foo1"). This
2649 would result in generation of gratuitous ARPs for IP addresses
2650 158.36.44.22 and 158.36.44.24 with a MAC address of
2651 80:fa:5b:06:72:b7 from the chassis where the logical port "foo1"
2652 resides.
2653 L3 Gateway Options:
2655 These options apply to logical ports with type of l3gateway.
2657 options : peer: optional string
2659 The logical_port in the Port_Binding record for the other side
2660 of the ’l3gateway’ port. The named logical_port must specify
2661 this logical_port in its own peer option. That is, the two
2662 ’l3gateway’ logical ports must have reversed logical_port and
2663 peer values.
2664 options : l3gateway-chassis: optional string
2666 The chassis in which the port resides.
2667 nat_addresses: set of strings
2669 MAC address of the l3gateway port followed by a list of SNAT and
2670 DNAT external IP addresses. This is used to send gratuitous ARPs
2671 for SNAT and DNAT external IP addresses via localnet. Example:
2672 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
2673 in generation of gratuitous ARPs for IP addresses 158.36.44.22
2674 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
2675 is used in OVS version 2.8 and later versions.
2676 Localnet Options:
2678 These options apply to logical ports with type of localnet.
2680 options : network_name: optional string
2682 Required. ovn-controller uses the configuration entry
2683 ovn-bridge-mappings to determine how to connect to this network.
2684 ovn-bridge-mappings is a list of network names mapped to a local
2685 OVS bridge that provides access to that network. An example of
2686 configuring ovn-bridge-mappings would be: .IP
2687 $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
2688 When a logical switch has a localnet port attached, every chas‐
2690 sis that may have a local vif attached to that logical switch
2691 must have a bridge mapping configured to reach that localnet.
2692 Traffic that arrives on a localnet port is never forwarded over
2693 a tunnel to another chassis. If there are multiple localnet
2694 ports in a logical switch, each chassis should only have a sin‐
2695 gle bridge mapping for one of the physical networks. Note: In
2696 case of multiple localnet ports, to provide interconnectivity
2697 between all VIFs located on different chassis with different
2698 fabric connectivity, the fabric should implement some form of
2699 routing between the segments.
2700 tag: optional integer, in range 1 to 4,095
2702 If set, indicates that the port represents a connection to a
2703 specific VLAN on a locally accessible network. The VLAN ID is
2704 used to match incoming traffic and is also added to outgoing
2705 traffic.
2706 L2 Gateway Options:
2708 These options apply to logical ports with type of l2gateway.
2710 options : network_name: optional string
2712 Required. ovn-controller uses the configuration entry
2713 ovn-bridge-mappings to determine how to connect to this network.
2714 ovn-bridge-mappings is a list of network names mapped to a local
2715 OVS bridge that provides access to that network. An example of
2716 configuring ovn-bridge-mappings would be: .IP
2717 $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
2718 When a logical switch has a l2gateway port attached, the chassis
2720 that the l2gateway port is bound to must have a bridge mapping
2721 configured to reach the network identified by network_name.
2722 options : l2gateway-chassis: optional string
2724 Required. The chassis in which the port resides.
2725 tag: optional integer, in range 1 to 4,095
2727 If set, indicates that the gateway is connected to a specific
2728 VLAN on the physical network. The VLAN ID is used to match in‐
2729 coming traffic and is also added to outgoing traffic.
2730 VTEP Options:
2732 These options apply to logical ports with type of vtep.
2734 options : vtep-physical-switch: optional string
2736 Required. The name of the VTEP gateway.
2737 options : vtep-logical-switch: optional string
2739 Required. A logical switch name connected by the VTEP gateway.
2740 Must be set when type is vtep.
2741 VMI (or VIF) Options:
2743 These options apply to logical ports with type having (empty string)
2745 options : requested-chassis: optional string
2747 If set, identifies a specific chassis (by name or hostname) that
2748 is allowed to bind this port. Using this option will prevent
2749 thrashing between two chassis trying to bind the same port dur‐
2750 ing a live migration. It can also prevent similar thrashing due
2751 to a mis-configuration, if a port is accidentally created on
2752 more than one chassis.
2753 If set to a comma separated list, the first entry identifies the
2755 main chassis and the rest are one or more additional chassis
2756 that are allowed to bind the same port.
2757 When multiple chassis are set for the port, and the logical
2759 switch is connected to an external network through a localnet
2760 port, tunneling is enforced for the port to guarantee delivery
2761 of packets directed to the port to all its locations. This has
2762 MTU implications because the network used for tunneling must
2763 have MTU larger than localnet for stable connectivity.
2764 options : activation-strategy: optional string
2766 If used with multiple chassis set in requested-chassis, speci‐
2767 fies an activation strategy for all additional chassis. By de‐
2768 fault, no activation strategy is used, meaning additional port
2769 locations are immediately available for use. When set to "rarp",
2770 the port is blocked for ingress and egress communication until a
2771 RARP packet is sent from a new location. The "rarp" strategy is
2772 useful in live migration scenarios for virtual machines.
2773 options : additional-chassis-activated: optional string
2775 When activation-strategy is set, this option indicates that the
2776 port was activated using the strategy specified.
2777 options : iface-id-ver: optional string
2779 If set, this port will be bound by ovn-controller only if this
2780 same key and value is configured in the external_ids column in
2781 the Open_vSwitch database’s Interface table.
2782 options : qos_min_rate: optional string
2784 If set, indicates the minimum guaranteed rate available for data
2785 sent from this interface, in bit/s.
2786 options : qos_max_rate: optional string
2788 If set, indicates the maximum rate for data sent from this in‐
2789 terface, in bit/s. The traffic will be shaped according to this
2790 limit.
2791 options : qos_burst: optional string
2793 If set, indicates the maximum burst size for data sent from this
2794 interface, in bits.
2795 options : qdisc_queue_id: optional string, containing an integer, in
2797 range 1 to 61,440
2798 Indicates the queue number on the physical device. This is same
2799 as the queue_id used in OpenFlow in struct ofp_action_enqueue.
2800 Distributed Gateway Port Options:
2802 These options apply to the distributed parent ports of logical ports
2804 with type of chasssisredirect.
2805 options : chassis-redirect-port: optional string
2807 The name of the chassis redirect port derived from this port if
2808 this port is a distributed parent of a chassis redirect port.
2809 Chassis Redirect Options:
2811 These options apply to logical ports with type of chassisredirect.
2813 options : distributed-port: optional string
2815 The name of the distributed port for which this chassisredirect
2816 port represents a particular instance.
2817 options : redirect-type: optional string
2819 The value is copied from the column options in the OVN_North‐
2820 bound database’s Logical_Router_Port table for the distributed
2821 parent of this port.
2822 options : always-redirect: optional string
2824 A boolean option that is set to true if the distributed parent
2825 of this chassis redirect port does not need distributed process‐
2826 ing.
2827 Nested Containers:
2829 These columns support containers nested within a VM. Specifically, they
2831 are used when type is empty and logical_port identifies the interface
2832 of a container spawned inside a VM. They are empty for containers or
2833 VMs that run directly on a hypervisor.
2834 parent_port: optional string
2836 This is taken from parent_name in the OVN_Northbound database’s
2837 Logical_Switch_Port table.
2838 tag: optional integer, in range 1 to 4,095
2840 Identifies the VLAN tag in the network traffic associated with
2841 that container’s network interface.
2842 This column is used for a different purpose when type is local‐
2844 net (see Localnet Options, above) or l2gateway (see L2 Gateway
2845 Options, above).
2846 Virtual ports:
2848 virtual_parent: optional string
2850 This column is set by ovn-controller with one of the value from
2851 the options:virtual-parents in the OVN_Northbound database’s
2852 Logical_Switch_Port table when the OVN action bind_vport is exe‐
2853 cuted. ovn-controller also sets the chassis column when it exe‐
2854 cutes this action with its chassis id.
2855 ovn-controller sets this column only if the type is "virtual".
2857 Naming:
2859 external_ids : name: optional string
2861 For a logical switch port, ovn-northd copies this from exter‐
2862 nal_ids:neutron:port_name in the Logical_Switch_Port table in
2863 the OVN_Northbound database, if it is a nonempty string.
2864 For a logical switch port, ovn-northd does not currently set
2866 this key.
2867 Common Columns:
2869 external_ids: map of string-string pairs
2871 See External IDs at the beginning of this document.
2872 The ovn-northd program populates this column with all entries
2874 into the external_ids column of the Logical_Switch_Port and Log‐
2875 ical_Router_Port tables of the OVN_Northbound database.
2876
2878 Each row in this table specifies a binding from an IP address to an
2879 Ethernet address that has been discovered through ARP (for IPv4) or
2880 neighbor discovery (for IPv6). This table is primarily used to discover
2881 bindings on physical networks, because IP-to-MAC bindings for virtual
2882 machines are usually populated statically into the Port_Binding table.
2883 This table expresses a functional relationship: MAC_Binding(logi‐
2885 cal_port, ip) = mac.
2886 In outline, the lifetime of a logical router’s MAC binding looks like
2888 this:
2889 1. On hypervisor 1, a logical router determines that a packet
2891 should be forwarded to IP address A on one of its router
2892 ports. It uses its logical flow table to determine that A
2893 lacks a static IP-to-MAC binding and the get_arp action to
2894 determine that it lacks a dynamic IP-to-MAC binding.
2895 2. Using an OVN logical arp action, the logical router gener‐
2897 ates and sends a broadcast ARP request to the router port.
2898 It drops the IP packet.
2899 3. The logical switch attached to the router port delivers the
2901 ARP request to all of its ports. (It might make sense to de‐
2902 liver it only to ports that have no static IP-to-MAC bind‐
2903 ings, but this could also be surprising behavior.)
2904 4. A host or VM on hypervisor 2 (which might be the same as hy‐
2906 pervisor 1) attached to the logical switch owns the IP ad‐
2907 dress in question. It composes an ARP reply and unicasts it
2908 to the logical router port’s Ethernet address.
2909 5. The logical switch delivers the ARP reply to the logical
2911 router port.
2912 6. The logical router flow table executes a put_arp action. To
2914 record the IP-to-MAC binding, ovn-controller adds a row to
2915 the MAC_Binding table.
2916 7. On hypervisor 1, ovn-controller receives the updated
2918 MAC_Binding table from the OVN southbound database. The next
2919 packet destined to A through the logical router is sent di‐
2920 rectly to the bound Ethernet address.
2921 Summary:
2923 logical_port string
2924 ip string
2925 mac string
2926 timestamp integer
2927 datapath Datapath_Binding
2928 Details:
2930 logical_port: string
2931 The logical port on which the binding was discovered.
2932 ip: string
2934 The bound IP address.
2935 mac: string
2937 The Ethernet address to which the IP is bound.
2938 timestamp: integer
2940 The timestamp in msec when the MAC binding was added or updated.
2941 Records that existed before this column will have 0.
2942 datapath: Datapath_Binding
2944 The logical datapath to which the logical port belongs.
2945
2947 Each row in this table stores the DHCP Options supported by native OVN
2948 DHCP. ovn-northd populates this table with the supported DHCP options.
2949 ovn-controller looks up this table to get the DHCP codes of the DHCP
2950 options defined in the "put_dhcp_opts" action. Please refer to the RFC
2951 2132 "https://tools.ietf.org/html/rfc2132" for the possible list of
2952 DHCP options that can be defined here.
2953 Summary:
2955 name string
2956 code integer, in range 0 to 254
2957 type string, one of bool, domains, host_id,
2958 ipv4, static_routes, str, uint16, uint32,
2959 or uint8
2960 Details:
2962 name: string
2963 Name of the DHCP option.
2964 Example. name="router"
2966 code: integer, in range 0 to 254
2968 DHCP option code for the DHCP option as defined in the RFC 2132.
2969 Example. code=3
2971 type: string, one of bool, domains, host_id, ipv4, static_routes, str,
2973 uint16, uint32, or uint8
2974 Data type of the DHCP option code.
2975 value: bool
2977 This indicates that the value of the DHCP option is a
2978 bool.
2979 Example. "name=ip_forward_enable", "code=19",
2981 "type=bool".
2982 put_dhcp_opts(..., ip_forward_enable = 1,...)
2984 value: uint8
2986 This indicates that the value of the DHCP option is an
2987 unsigned int8 (8 bits)
2988 Example. "name=default_ttl", "code=23", "type=uint8".
2990 put_dhcp_opts(..., default_ttl = 50,...)
2992 value: uint16
2994 This indicates that the value of the DHCP option is an
2995 unsigned int16 (16 bits).
2996 Example. "name=mtu", "code=26", "type=uint16".
2998 put_dhcp_opts(..., mtu = 1450,...)
3000 value: uint32
3002 This indicates that the value of the DHCP option is an
3003 unsigned int32 (32 bits).
3004 Example. "name=lease_time", "code=51", "type=uint32".
3006 put_dhcp_opts(..., lease_time = 86400,...)
3008 value: ipv4
3010 This indicates that the value of the DHCP option is an
3011 IPv4 address or addresses.
3012 Example. "name=router", "code=3", "type=ipv4".
3014 put_dhcp_opts(..., router = 10.0.0.1,...)
3016 Example. "name=dns_server", "code=6", "type=ipv4".
3018 put_dhcp_opts(..., dns_server = {8.8.8.8 7.7.7.7},...)
3020 value: static_routes
3022 This indicates that the value of the DHCP option contains
3023 a pair of IPv4 route and next hop addresses.
3024 Example. "name=classless_static_route", "code=121",
3026 "type=static_routes".
3027 put_dhcp_opts(..., classless_static_route =
3029 {30.0.0.0/24,10.0.0.4,0.0.0.0/0,10.0.0.1}...)
3030 value: str
3032 This indicates that the value of the DHCP option is a
3033 string.
3034 Example. "name=host_name", "code=12", "type=str".
3036 value: host_id
3038 This indicates that the value of the DHCP option is a
3039 host_id. It can either be a host_name or an IP address.
3040 Example. "name=tftp_server", "code=66", "type=host_id".
3042 value: domains
3044 This indicates that the value of the DHCP option is a do‐
3045 main name or a comma separated list of domain names.
3046 Example. "name=domain_search_list", "code=119", "type=do‐
3048 mains".
3049
3051 Each row in this table stores the DHCPv6 Options supported by native
3052 OVN DHCPv6. ovn-northd populates this table with the supported DHCPv6
3053 options. ovn-controller looks up this table to get the DHCPv6 codes of
3054 the DHCPv6 options defined in the put_dhcpv6_opts action. Please refer
3055 to RFC 3315 and RFC 3646 for the list of DHCPv6 options that can be de‐
3056 fined here.
3057 Summary:
3059 name string
3060 code integer, in range 0 to 254
3061 type string, one of ipv6, mac, or str
3062 Details:
3064 name: string
3065 Name of the DHCPv6 option.
3066 Example. name="ia_addr"
3068 code: integer, in range 0 to 254
3070 DHCPv6 option code for the DHCPv6 option as defined in the ap‐
3071 propriate RFC.
3072 Example. code=3
3074 type: string, one of ipv6, mac, or str
3076 Data type of the DHCPv6 option code.
3077 value: ipv6
3079 This indicates that the value of the DHCPv6 option is an
3080 IPv6 address(es).
3081 Example. "name=ia_addr", "code=5", "type=ipv6".
3083 put_dhcpv6_opts(..., ia_addr = ae70::4,...)
3085 value: str
3087 This indicates that the value of the DHCPv6 option is a
3088 string.
3089 Example. "name=domain_search", "code=24", "type=str".
3091 put_dhcpv6_opts(..., domain_search = ovn.domain,...)
3093 value: mac
3095 This indicates that the value of the DHCPv6 option is a
3096 MAC address.
3097 Example. "name=server_id", "code=2", "type=mac".
3099 put_dhcpv6_opts(..., server_id = 01:02:03:04L05:06,...)
3101
3103 Configuration for a database connection to an Open vSwitch database
3104 (OVSDB) client.
3105 This table primarily configures the Open vSwitch database server
3107 (ovsdb-server).
3108 The Open vSwitch database server can initiate and maintain active con‐
3110 nections to remote clients. It can also listen for database connec‐
3111 tions.
3112 Summary:
3114 Core Features:
3115 target string (must be unique within table)
3116 read_only boolean
3117 role string
3118 Client Failure Detection and Handling:
3119 max_backoff optional integer, at least 1,000
3120 inactivity_probe optional integer
3121 Status:
3122 is_connected boolean
3123 status : last_error optional string
3124 status : state optional string, one of ACTIVE, BACKOFF,
3125 CONNECTING, IDLE, or VOID
3126 status : sec_since_connect optional string, containing an integer,
3127 at least 0
3128 status : sec_since_disconnect
3129 optional string, containing an integer,
3130 at least 0
3131 status : locks_held optional string
3132 status : locks_waiting optional string
3133 status : locks_lost optional string
3134 status : n_connections optional string, containing an integer,
3135 at least 2
3136 status : bound_port optional string, containing an integer
3137 Common Columns:
3138 external_ids map of string-string pairs
3139 other_config map of string-string pairs
3140 Details:
3142 Core Features:
3143 target: string (must be unique within table)
3145 Connection methods for clients.
3146 The following connection methods are currently supported:
3148 ssl:host[:port]
3150 The specified SSL port on the given host, which can ei‐
3151 ther be a DNS name (if built with unbound library) or an
3152 IP address. A valid SSL configuration must be provided
3153 when this form is used, this configuration can be speci‐
3154 fied via command-line options or the SSL table.
3155 If port is not specified, it defaults to 6640.
3157 SSL support is an optional feature that is not always
3159 built as part of Open vSwitch.
3160 tcp:host[:port]
3162 The specified TCP port on the given host, which can ei‐
3163 ther be a DNS name (if built with unbound library) or an
3164 IP address (IPv4 or IPv6). If host is an IPv6 address,
3165 wrap it in square brackets, e.g. tcp:[::1]:6640.
3166 If port is not specified, it defaults to 6640.
3168 pssl:[port][:host]
3170 Listens for SSL connections on the specified TCP port.
3171 Specify 0 for port to have the kernel automatically
3172 choose an available port. If host, which can either be a
3173 DNS name (if built with unbound library) or an IP ad‐
3174 dress, is specified, then connections are restricted to
3175 the resolved or specified local IP address (either IPv4
3176 or IPv6 address). If host is an IPv6 address, wrap in
3177 square brackets, e.g. pssl:6640:[::1]. If host is not
3178 specified then it listens only on IPv4 (but not IPv6) ad‐
3179 dresses. A valid SSL configuration must be provided when
3180 this form is used, this can be specified either via com‐
3181 mand-line options or the SSL table.
3182 If port is not specified, it defaults to 6640.
3184 SSL support is an optional feature that is not always
3186 built as part of Open vSwitch.
3187 ptcp:[port][:host]
3189 Listens for connections on the specified TCP port. Spec‐
3190 ify 0 for port to have the kernel automatically choose an
3191 available port. If host, which can either be a DNS name
3192 (if built with unbound library) or an IP address, is
3193 specified, then connections are restricted to the re‐
3194 solved or specified local IP address (either IPv4 or IPv6
3195 address). If host is an IPv6 address, wrap it in square
3196 brackets, e.g. ptcp:6640:[::1]. If host is not specified
3197 then it listens only on IPv4 addresses.
3198 If port is not specified, it defaults to 6640.
3200 When multiple clients are configured, the target values must be
3202 unique. Duplicate target values yield unspecified results.
3203 read_only: boolean
3205 true to restrict these connections to read-only transactions,
3206 false to allow them to modify the database.
3207 role: string
3209 String containing role name for this connection entry.
3210 Client Failure Detection and Handling:
3212 max_backoff: optional integer, at least 1,000
3214 Maximum number of milliseconds to wait between connection at‐
3215 tempts. Default is implementation-specific.
3216 inactivity_probe: optional integer
3218 Maximum number of milliseconds of idle time on connection to the
3219 client before sending an inactivity probe message. If Open
3220 vSwitch does not communicate with the client for the specified
3221 number of seconds, it will send a probe. If a response is not
3222 received for the same additional amount of time, Open vSwitch
3223 assumes the connection has been broken and attempts to recon‐
3224 nect. Default is implementation-specific. A value of 0 disables
3225 inactivity probes.
3226 Status:
3228 Key-value pair of is_connected is always updated. Other key-value pairs
3230 in the status columns may be updated depends on the target type.
3231 When target specifies a connection method that listens for inbound con‐
3233 nections (e.g. ptcp: or punix:), both n_connections and is_connected
3234 may also be updated while the remaining key-value pairs are omitted.
3235 On the other hand, when target specifies an outbound connection, all
3237 key-value pairs may be updated, except the above-mentioned two key-
3238 value pairs associated with inbound connection targets. They are omit‐
3239 ted.
3240 is_connected: boolean
3242 true if currently connected to this client, false otherwise.
3243 status : last_error: optional string
3245 A human-readable description of the last error on the connection
3246 to the manager; i.e. strerror(errno). This key will exist only
3247 if an error has occurred.
3248 status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
3250 IDLE, or VOID
3251 The state of the connection to the manager:
3252 VOID Connection is disabled.
3254 BACKOFF
3256 Attempting to reconnect at an increasing period.
3257 CONNECTING
3259 Attempting to connect.
3260 ACTIVE Connected, remote host responsive.
3262 IDLE Connection is idle. Waiting for response to keep-alive.
3264 These values may change in the future. They are provided only
3266 for human consumption.
3267 status : sec_since_connect: optional string, containing an integer, at
3269 least 0
3270 The amount of time since this client last successfully connected
3271 to the database (in seconds). Value is empty if client has never
3272 successfully been connected.
3273 status : sec_since_disconnect: optional string, containing an integer,
3275 at least 0
3276 The amount of time since this client last disconnected from the
3277 database (in seconds). Value is empty if client has never dis‐
3278 connected.
3279 status : locks_held: optional string
3281 Space-separated list of the names of OVSDB locks that the con‐
3282 nection holds. Omitted if the connection does not hold any
3283 locks.
3284 status : locks_waiting: optional string
3286 Space-separated list of the names of OVSDB locks that the con‐
3287 nection is currently waiting to acquire. Omitted if the connec‐
3288 tion is not waiting for any locks.
3289 status : locks_lost: optional string
3291 Space-separated list of the names of OVSDB locks that the con‐
3292 nection has had stolen by another OVSDB client. Omitted if no
3293 locks have been stolen from this connection.
3294 status : n_connections: optional string, containing an integer, at
3296 least 2
3297 When target specifies a connection method that listens for in‐
3298 bound connections (e.g. ptcp: or pssl:) and more than one con‐
3299 nection is actually active, the value is the number of active
3300 connections. Otherwise, this key-value pair is omitted.
3301 status : bound_port: optional string, containing an integer
3303 When target is ptcp: or pssl:, this is the TCP port on which the
3304 OVSDB server is listening. (This is particularly useful when
3305 target specifies a port of 0, allowing the kernel to choose any
3306 available port.)
3307 Common Columns:
3309 The overall purpose of these columns is described under Common Columns
3311 at the beginning of this document.
3312 external_ids: map of string-string pairs
3314 other_config: map of string-string pairs
3316
3318 SSL configuration for ovn-sb database access.
3319 Summary:
3321 private_key string
3322 certificate string
3323 ca_cert string
3324 bootstrap_ca_cert boolean
3325 ssl_protocols string
3326 ssl_ciphers string
3327 Common Columns:
3328 external_ids map of string-string pairs
3329 Details:
3331 private_key: string
3332 Name of a PEM file containing the private key used as the
3333 switch’s identity for SSL connections to the controller.
3334 certificate: string
3336 Name of a PEM file containing a certificate, signed by the cer‐
3337 tificate authority (CA) used by the controller and manager, that
3338 certifies the switch’s private key, identifying a trustworthy
3339 switch.
3340 ca_cert: string
3342 Name of a PEM file containing the CA certificate used to verify
3343 that the switch is connected to a trustworthy controller.
3344 bootstrap_ca_cert: boolean
3346 If set to true, then Open vSwitch will attempt to obtain the CA
3347 certificate from the controller on its first SSL connection and
3348 save it to the named PEM file. If it is successful, it will im‐
3349 mediately drop the connection and reconnect, and from then on
3350 all SSL connections must be authenticated by a certificate
3351 signed by the CA certificate thus obtained. This option exposes
3352 the SSL connection to a man-in-the-middle attack obtaining the
3353 initial CA certificate. It may still be useful for bootstrap‐
3354 ping.
3355 ssl_protocols: string
3357 List of SSL protocols to be enabled for SSL connections. The de‐
3358 fault when this option is omitted is TLSv1,TLSv1.1,TLSv1.2.
3359 ssl_ciphers: string
3361 List of ciphers (in OpenSSL cipher string format) to be sup‐
3362 ported for SSL connections. The default when this option is
3363 omitted is HIGH:!aNULL:!MD5.
3364 Common Columns:
3366 The overall purpose of these columns is described under Common Columns
3368 at the beginning of this document.
3369 external_ids: map of string-string pairs
3371
3373 Each row in this table stores the DNS records. The OVN action
3374 dns_lookup uses this table for DNS resolution.
3375 Summary:
3377 records map of string-string pairs
3378 datapaths set of 1 or more Datapath_Bindings
3379 Common Columns:
3380 external_ids map of string-string pairs
3381 Details:
3383 records: map of string-string pairs
3384 Key-value pair of DNS records with DNS query name as the key and
3385 a string of IP address(es) separated by comma or space as the
3386 value. ovn-northd stores the DNS query name in all lowercase in
3387 order to facilitate case-insensitive lookups.
3388 Example: "vm1.ovn.org" = "10.0.0.4 aef0::4"
3390 datapaths: set of 1 or more Datapath_Bindings
3392 The DNS records defined in the column records will be applied
3393 only to the DNS queries originating from the datapaths defined
3394 in this column.
3395 Common Columns:
3397 external_ids: map of string-string pairs
3399 See External IDs at the beginning of this document.
3400
3402 Role table for role-based access controls.
3403 Summary:
3405 name string
3406 permissions map of string-weak reference to RBAC_Per‐
3407 mission pairs
3408 Details:
3410 name: string
3411 The role name, corresponding to the role column in the Connec‐
3412 tion table.
3413 permissions: map of string-weak reference to RBAC_Permission pairs
3415 A mapping of table names to rows in the RBAC_Permission table.
3416
3418 Permissions table for role-based access controls.
3419 Summary:
3421 table string
3422 authorization set of strings
3423 insert_delete boolean
3424 update set of strings
3425 Details:
3427 table: string
3428 Name of table to which this row applies.
3429 authorization: set of strings
3431 Set of strings identifying columns and column:key pairs to be
3432 compared with client ID. At least one match is required in order
3433 to be authorized. A zero-length string is treated as a special
3434 value indicating all clients should be considered authorized.
3435 insert_delete: boolean
3437 When "true", row insertions and authorized row deletions are
3438 permitted.
3439 update: set of strings
3441 Set of strings identifying columns and column:key pairs that au‐
3442 thorized clients are allowed to modify.
3443
3445 Association of Port_Binding rows of type chassisredirect to a Chassis.
3446 The traffic going out through a specific chassisredirect port will be
3447 redirected to a chassis, or a set of them in high availability configu‐
3448 rations.
3449 Summary:
3451 name string (must be unique within table)
3452 chassis optional weak reference to Chassis
3453 priority integer, in range 0 to 32,767
3454 options map of string-string pairs
3455 Common Columns:
3456 external_ids map of string-string pairs
3457 Details:
3459 name: string (must be unique within table)
3460 Name of the Gateway_Chassis.
3461 A suggested, but not required naming convention is
3463 ${port_name}_${chassis_name}.
3464 chassis: optional weak reference to Chassis
3466 The Chassis to which we send the traffic.
3467 priority: integer, in range 0 to 32,767
3469 This is the priority the specific Chassis among all Gate‐
3470 way_Chassis belonging to the same Port_Binding.
3471 options: map of string-string pairs
3473 Reserved for future use.
3474 Common Columns:
3476 The overall purpose of these columns is described under Common Columns
3478 at the beginning of this document.
3479 external_ids: map of string-string pairs
3481
3483 Summary:
3484 chassis optional weak reference to Chassis
3485 priority integer, in range 0 to 32,767
3486 Common Columns:
3487 external_ids map of string-string pairs
3488 Details:
3490 chassis: optional weak reference to Chassis
3491 The Chassis which provides the HA functionality.
3492 priority: integer, in range 0 to 32,767
3494 Priority of the HA chassis. Chassis with highest priority will
3495 be the master in the HA chassis group.
3496 Common Columns:
3498 external_ids: map of string-string pairs
3500 See External IDs at the beginning of this document.
3501
3503 Table representing a group of chassis which can provide High availabil‐
3504 ity services. Each chassis in the group is represented by the table
3505 HA_Chassis. The HA chassis with highest priority will be the master of
3506 this group. If the master chassis failover is detected, the HA chassis
3507 with the next higher priority takes over the responsibility of provid‐
3508 ing the HA. If ha_chassis_group column of the table Port_Binding refer‐
3509 ences this table, then this HA chassis group provides the gateway func‐
3510 tionality and redirects the gateway traffic to the master of this
3511 group.
3512 Summary:
3514 name string (must be unique within table)
3515 ha_chassis set of HA_Chassises
3516 ref_chassis set of weak reference to Chassis
3517 Common Columns:
3518 external_ids map of string-string pairs
3519 Details:
3521 name: string (must be unique within table)
3522 Name of the HA_Chassis_Group. Name should be unique.
3523 ha_chassis: set of HA_Chassises
3525 A list of HA_Chassis which belongs to this group.
3526 ref_chassis: set of weak reference to Chassis
3528 The set of Chassis that reference this HA chassis group. To de‐
3529 termine the correct Chassis, find the chassisredirect type
3530 Port_Binding that references this HA_Chassis_Group. This
3531 Port_Binding is derived from some particular logical router.
3532 Starting from that LR, find the set of all logical switches and
3533 routers connected to it, directly or indirectly, across router
3534 ports that link one LRP to another or to a LSP. For each LSP in
3535 these logical switches, find the corresponding Port_Binding and
3536 add its bound Chassis (if any) to ref_chassis.
3537 Common Columns:
3539 external_ids: map of string-string pairs
3541 See External IDs at the beginning of this document.
3542
3544 Database table used by ovn-controller to report CMS related events.
3545 Please note there is no guarantee a given event is written exactly once
3546 in the db. It is CMS responsibility to squash duplicated lines or to
3547 filter out duplicated events
3548 Summary:
3550 event_type string, must be empty_lb_backends
3551 event_info map of string-string pairs
3552 chassis optional weak reference to Chassis
3553 seq_num integer
3554 Details:
3556 event_type: string, must be empty_lb_backends
3557 Event type occurred
3558 event_info: map of string-string pairs
3560 Key-value pairs used to specify event info to the CMS. Possible
3561 values are:
3562 • vip: VIP reported for the empty_lb_backends event
3564 • protocol: Transport protocol reported for the
3566 empty_lb_backends event
3567 • load_balancer: UUID of the load balancer reported for the
3569 empty_lb_backends event
3570 chassis: optional weak reference to Chassis
3572 This column is a Chassis record to identify the chassis that has
3573 managed a given event.
3574 seq_num: integer
3576 Event sequence number. Global counter for controller generated
3577 events. It can be used by the CMS to detect possible duplication
3578 of the same event.
3579
3581 IP Multicast configuration options. For now only applicable to IGMP.
3582 Summary:
3584 datapath weak reference to Datapath_Binding (must
3585 be unique within table)
3586 enabled optional boolean
3587 querier optional boolean
3588 table_size optional integer
3589 idle_timeout optional integer
3590 query_interval optional integer
3591 seq_no integer
3592 Querier configuration options:
3593 eth_src string
3594 ip4_src string
3595 ip6_src string
3596 query_max_resp optional integer
3597 Details:
3599 datapath: weak reference to Datapath_Binding (must be unique within ta‐
3600 ble)
3601 Datapath_Binding entry for which these configuration options are
3602 defined.
3603 enabled: optional boolean
3605 Enables/disables multicast snooping. Default: disabled.
3606 querier: optional boolean
3608 Enables/disables multicast querying. If enabled then multicast
3609 querying is enabled by default.
3610 table_size: optional integer
3612 Limits the number of multicast groups that can be learned. De‐
3613 fault: 2048 groups per datapath.
3614 idle_timeout: optional integer
3616 Configures the idle timeout (in seconds) for IP multicast groups
3617 if multicast snooping is enabled. Default: 300 seconds.
3618 query_interval: optional integer
3620 Configures the interval (in seconds) for sending multicast
3621 queries if snooping and querier are enabled. Default: idle_time‐
3622 out/2 seconds.
3623 seq_no: integer
3625 ovn-controller reads this value and flushes all learned multi‐
3626 cast groups when it detects that seq_no was changed.
3627 Querier configuration options:
3629 The ovn-controller process that runs on OVN hypervisor nodes uses the
3631 following columns to determine field values in IGMP/MLD queries that it
3632 originates:
3633 eth_src: string
3635 Source Ethernet address.
3636 ip4_src: string
3638 Source IPv4 address.
3639 ip6_src: string
3641 Source IPv6 address.
3642 query_max_resp: optional integer
3644 Value (in seconds) to be used as "max-response" field in multi‐
3645 cast queries. Default: 1 second.
3646
3648 Contains learned IGMP groups indexed by address/datapath/chassis.
3649 Summary:
3651 address string
3652 datapath optional weak reference to Datapath_Bind‐
3653 ing
3654 chassis optional weak reference to Chassis
3655 ports set of weak reference to Port_Bindings
3656 Details:
3658 address: string
3659 Destination IPv4 address for the IGMP group.
3660 datapath: optional weak reference to Datapath_Binding
3662 Datapath to which this IGMP group belongs.
3663 chassis: optional weak reference to Chassis
3665 Chassis to which this IGMP group belongs.
3666 ports: set of weak reference to Port_Bindings
3668 The destination port bindings for this IGMP group.
3669
3671 Each row in this table configures monitoring a service for its live‐
3672 ness. The service can be an IPv4 TCP or UDP service. ovn-controller pe‐
3673 riodically sends out service monitor packets and updates the status of
3674 the service. Service monitoring for IPv6 services is not supported.
3675 ovn-northd uses this feature to implement the load balancer health
3677 check feature offered to the CMS through the northbound database.
3678 Summary:
3680 Configuration:
3681 ip string
3682 protocol optional string, either tcp or udp
3683 port integer, in range 0 to 65,535
3684 logical_port string
3685 src_mac string
3686 src_ip string
3687 options : interval optional string, containing an integer
3688 options : timeout optional string, containing an integer
3689 options : success_count optional string, containing an integer
3690 options : failure_count optional string, containing an integer
3691 Status Reporting:
3692 status optional string, one of error, offline,
3693 or online
3694 Common Columns:
3695 external_ids map of string-string pairs
3696 Details:
3698 Configuration:
3699 ovn-northd sets these columns and values to configure the service moni‐
3701 tor.
3702 ip: string
3704 IP of the service to be monitored. Only IPv4 is supported.
3705 protocol: optional string, either tcp or udp
3707 The protocol of the service.
3708 port: integer, in range 0 to 65,535
3710 The TCP or UDP port of the service.
3711 logical_port: string
3713 The VIF of the logical port on which the service is running. The
3714 ovn-controller that binds this logical_port monitors the service
3715 by sending periodic monitor packets.
3716 src_mac: string
3718 Source Ethernet address to use in the service monitor packet.
3719 src_ip: string
3721 Source IPv4 address to use in the service monitor packet.
3722 options : interval: optional string, containing an integer
3724 The interval, in seconds, between service monitor checks.
3725 options : timeout: optional string, containing an integer
3727 The time, in seconds, after which the service monitor check
3728 times out.
3729 options : success_count: optional string, containing an integer
3731 The number of successful checks after which the service is con‐
3732 sidered online.
3733 options : failure_count: optional string, containing an integer
3735 The number of failure checks after which the service is consid‐
3736 ered offline.
3737 Status Reporting:
3739 The ovn-controller on the chassis that hosts the logical_port updates
3741 this column to report the service’s status.
3742 status: optional string, one of error, offline, or online
3744 For TCP service, ovn-controller sends a SYN to the service and
3745 expects an ACK response to consider the service to be online.
3746 For UDP service, ovn-controller sends a UDP packet to the ser‐
3748 vice and doesn’t expect any reply. If it receives an ICMP reply,
3749 then it considers the service to be offline.
3750 Common Columns:
3752 external_ids: map of string-string pairs
3754 See External IDs at the beginning of this document.
3755
3757 Each row represents a load balancer.
3758 Summary:
3760 name string
3761 vips map of string-string pairs
3762 protocol optional string, one of sctp, tcp, or udp
3763 datapaths set of Datapath_Bindings
3764 datapath_group optional Logical_DP_Group
3765 Load_Balancer options:
3766 options : hairpin_snat_ip optional string
3767 options : hairpin_orig_tuple
3768 optional string, either true or false
3769 Common Columns:
3770 external_ids map of string-string pairs
3771 Details:
3773 name: string
3774 A name for the load balancer. This name has no special meaning
3775 or purpose other than to provide convenience for human interac‐
3776 tion with the ovn-nb database.
3777 vips: map of string-string pairs
3779 A map of virtual IP addresses (and an optional port number with
3780 : as a separator) associated with this load balancer and their
3781 corresponding endpoint IP addresses (and optional port numbers
3782 with : as separators) separated by commas.
3783 protocol: optional string, one of sctp, tcp, or udp
3785 Valid protocols are tcp, udp, or sctp. This column is useful
3786 when a port number is provided as part of the vips column. If
3787 this column is empty and a port number is provided as part of
3788 vips column, OVN assumes the protocol to be tcp.
3789 datapaths: set of Datapath_Bindings
3791 Datapaths to which this load balancer applies to.
3792 datapath_group: optional Logical_DP_Group
3794 The group of datapaths to which this load balancer applies to.
3795 This means that the same load balancer applies to all datapaths
3796 in a group.
3797 Load_Balancer options:
3799 options : hairpin_snat_ip: optional string
3801 IP to be used as source IP for packets that have been hair-
3802 pinned after load balancing. This value is automatically popu‐
3803 lated by ovn-northd.
3804 options : hairpin_orig_tuple: optional string, either true or false
3806 This value is automatically set to true by ovn-northd when orig‐
3807 inal destination IP and transport port of the load balanced
3808 packets are stored in registers reg1, reg2, xxreg1.
3809 Common Columns:
3811 external_ids: map of string-string pairs
3813 See External IDs at the beginning of this document.
3814
3816 Contains BFD parameter for ovn-controller bfd configuration.
3817 Summary:
3819 Configuration:
3820 src_port integer, in range 49,152 to 65,535
3821 disc integer
3822 logical_port string
3823 dst_ip string
3824 min_tx integer
3825 min_rx integer
3826 detect_mult integer
3827 options map of string-string pairs
3828 external_ids map of string-string pairs
3829 Status Reporting:
3830 status string, one of admin_down, down, init, or
3831 up
3832 Details:
3834 Configuration:
3835 src_port: integer, in range 49,152 to 65,535
3837 udp source port used in bfd control packets. The source port
3838 MUST be in the range 49152 through 65535 (RFC5881 section 4).
3839 disc: integer
3841 A unique, nonzero discriminator value generated by the transmit‐
3842 ting system, used to demultiplex multiple BFD sessions between
3843 the same pair of systems.
3844 logical_port: string
3846 OVN logical port when BFD engine is running.
3847 dst_ip: string
3849 BFD peer IP address.
3850 min_tx: integer
3852 This is the minimum interval, in milliseconds, that the local
3853 system would like to use when transmitting BFD Control packets,
3854 less any jitter applied. The value zero is reserved.
3855 min_rx: integer
3857 This is the minimum interval, in milliseconds, between received
3858 BFD Control packets that this system is capable of supporting,
3859 less any jitter applied by the sender. If this value is zero,
3860 the transmitting system does not want the remote system to send
3861 any periodic BFD Control packets.
3862 detect_mult: integer
3864 Detection time multiplier. The negotiated transmit interval,
3865 multiplied by this value, provides the Detection Time for the
3866 receiving system in Asynchronous mode.
3867 options: map of string-string pairs
3869 Reserved for future use.
3870 external_ids: map of string-string pairs
3872 See External IDs at the beginning of this document.
3873 Status Reporting:
3875 status: string, one of admin_down, down, init, or up
3877 BFD port logical states. Possible values are:
3878 • admin_down
3880 • down
3882 • init
3884 • up
3886
3888 This table is primarily used to learn the MACs observed on a VIF (or a
3889 localnet port with ’localnet_learn_fdb’ enabled) which belongs to a
3890 Logical_Switch_Port record in OVN_Northbound whose port security is
3891 disabled and ’unknown’ address set. If port security is disabled on a
3892 Logical_Switch_Port record, OVN should allow traffic with any source
3893 mac from the VIF. This table will be used to deliver a packet to the
3894 VIF, If a packet’s eth.dst is learnt.
3895 Summary:
3897 mac string
3898 dp_key integer, in range 1 to 16,777,215
3899 port_key integer, in range 1 to 16,777,215
3900 Details:
3902 mac: string
3903 The learnt mac address.
3904 dp_key: integer, in range 1 to 16,777,215
3906 The key of the datapath on which this FDB was learnt.
3907 port_key: integer, in range 1 to 16,777,215
3909 The key of the port binding on which this FDB was learnt.
3910
3912 Each record represents a Static_MAC_Binding entry for a logical router.
3913 Summary:
3915 logical_port string
3916 ip string
3917 mac string
3918 override_dynamic_mac boolean
3919 datapath Datapath_Binding
3920 Details:
3922 logical_port: string
3923 The logical router port for the binding.
3924 ip: string
3926 The bound IP address.
3927 mac: string
3929 The Ethernet address to which the IP is bound.
3930 override_dynamic_mac: boolean
3932 Override dynamically learnt MACs.
3933 datapath: Datapath_Binding
3935 The logical datapath to which the logical router port belongs.
3936
3938 Each record represents the set of template variable instantiations for
3939 a given chassis and is populated by ovn-northd from the contents of the
3940 OVN_Northbound.Chassis_Template_Var table.
3941 Summary:
3943 chassis string (must be unique within table)
3944 variables map of string-string pairs
3945 Details:
3947 chassis: string (must be unique within table)
3948 The chassis this set of variable values applies to.
3949 variables: map of string-string pairs
3951 The set of variable values for a given chassis.
3952Open vSwitch 22.12.0 DB Schema 20.27.0 ovn-sb(5)