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
10 abstraction. For an introduction to OVN, please see ovn-architec‐
11 ture(7).
12 The OVN Southbound database sits at the center of the OVN architecture.
14 It is the one component that speaks both southbound directly to all the
15 hypervisors and gateways, via ovn-controller/ovn-controller-vtep, and
16 northbound to the Cloud Management System, via ovn-northd:
17 Database Structure
19 The OVN Southbound database contains classes of data with different
20 properties, as described in the sections below.
21 Physical network
23 Physical network tables contain information about the chassis nodes in
25 the system. This contains all the information necessary to wire the
26 overlay, such as IP addresses, supported tunnel types, and security
27 keys.
28 The amount of physical network data is small (O(n) in the number of
30 chassis) and it changes infrequently, so it can be replicated to every
31 chassis.
32 The Chassis and Encap tables are the physical network tables.
34 Logical Network
36 Logical network tables contain the topology of logical switches and
38 routers, ACLs, firewall rules, and everything needed to describe how
39 packets traverse a logical network, represented as logical datapath
40 flows (see Logical Datapath Flows, below).
41 Logical network data may be large (O(n) in the number of logical ports,
43 ACL rules, etc.). Thus, to improve scaling, each chassis should receive
44 only data related to logical networks in which that chassis partici‐
45 pates.
46 The logical network data is ultimately controlled by the cloud manage‐
48 ment system (CMS) running northbound of OVN. That CMS determines the
49 entire OVN logical configuration and therefore the logical network data
50 at any given time is a deterministic function of the CMS’s configura‐
51 tion, although that happens indirectly via the OVN_Northbound database
52 and ovn-northd.
53 Logical network data is likely to change more quickly than physical
55 network data. This is especially true in a container environment where
56 containers are created and destroyed (and therefore added to and
57 deleted from logical switches) quickly.
58 The Logical_Flow, Multicast_Group, Address_Group, DHCP_Options,
60 DHCPv6_Options, and DNS tables contain logical network data.
61 Logical-physical bindings
63 These tables link logical and physical components. They show the cur‐
65 rent placement of logical components (such as VMs and VIFs) onto chas‐
66 sis, and map logical entities to the values that represent them in tun‐
67 nel encapsulations.
68 These tables change frequently, at least every time a VM powers up or
70 down or migrates, and especially quickly in a container environment.
71 The amount of data per VM (or VIF) is small.
72 Each chassis is authoritative about the VMs and VIFs that it hosts at
74 any given time and can efficiently flood that state to a central loca‐
75 tion, so the consistency needs are minimal.
76 The Port_Binding and Datapath_Binding tables contain binding data.
78 MAC bindings
80 The MAC_Binding table tracks the bindings from IP addresses to Ethernet
82 addresses that are dynamically discovered using ARP (for IPv4) and
83 neighbor discovery (for IPv6). Usually, IP-to-MAC bindings for virtual
84 machines are statically populated into the Port_Binding table, so
85 MAC_Binding is primarily used to discover bindings on physical net‐
86 works.
87 Common Columns
89 Some tables contain a special column named external_ids. This column
90 has the same form and purpose each place that it appears, so we
91 describe it here to save space later.
92 external_ids: map of string-string pairs
94 Key-value pairs for use by the software that manages the
95 OVN Southbound database rather than by ovn-con‐
96 troller/ovn-controller-vtep. In particular, ovn-northd
97 can use key-value pairs in this column to relate entities
98 in the southbound database to higher-level entities (such
99 as entities in the OVN Northbound database). Individual
100 key-value pairs in this column may be documented in some
101 cases to aid in understanding and troubleshooting, but
102 the reader should not mistake such documentation as com‐
103 prehensive.
104
106 The following list summarizes the purpose of each of the tables in the
107 OVN_Southbound database. Each table is described in more detail on a
108 later page.
109 Table Purpose
111 SB_Global Southbound configuration
112 Chassis Physical Network Hypervisor and Gateway Information
113 Chassis_Private
114 Chassis Private
115 Encap Encapsulation Types
116 Address_Set
117 Address Sets
118 Port_Group
119 Port Groups
120 Logical_Flow
121 Logical Network Flows
122 Logical_DP_Group
123 Logical Datapath Groups
124 Multicast_Group
125 Logical Port Multicast Groups
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
165 Southbound configuration for an OVN system. This table must have
166 exactly one row.
167 Summary:
169 Status:
170 nb_cfg integer
171 Common Columns:
172 external_ids map of string-string pairs
173 options map of string-string pairs
174 Common options:
175 options map of string-string pairs
176 Options for configuring BFD:
177 options : bfd-min-rx optional string
178 options : bfd-decay-min-rx
179 optional string
180 options : bfd-min-tx optional string
181 options : bfd-mult optional string
182 Connection Options:
183 connections set of Connections
184 ssl optional SSL
185 Security Configurations:
186 ipsec boolean
187 Details:
189 Status:
190 This column allow a client to track the overall configuration state of
192 the system.
193 nb_cfg: integer
195 Sequence number for the configuration. When a CMS or ovn-nbctl
196 updates the northbound database, it increments the nb_cfg column
197 in the NB_Global table in the northbound database. In turn, when
198 ovn-northd updates the southbound database to bring it up to
199 date with these changes, it updates this column to the same
200 value.
201 Common Columns:
203 external_ids: map of string-string pairs
205 See External IDs at the beginning of this document.
206 options: map of string-string pairs
208 Common options:
210 options: map of string-string pairs
212 This column provides general key/value settings. The supported
213 options are described individually below.
214 Options for configuring BFD:
216 These options apply when ovn-controller configures BFD on tunnels
218 interfaces.
219 options : bfd-min-rx: optional string
221 BFD option min-rx value to use when configuring BFD on tunnel
222 interfaces.
223 options : bfd-decay-min-rx: optional string
225 BFD option decay-min-rx value to use when configuring BFD on
226 tunnel interfaces.
227 options : bfd-min-tx: optional string
229 BFD option min-tx value to use when configuring BFD on tunnel
230 interfaces.
231 options : bfd-mult: optional string
233 BFD option mult value to use when configuring BFD on tunnel
234 interfaces.
235 Connection Options:
237 connections: set of Connections
239 Database clients to which the Open vSwitch database server
240 should connect or on which it should listen, along with options
241 for how these connections should be configured. See the Connec‐
242 tion table for more information.
243 ssl: optional SSL
245 Global SSL configuration.
246 Security Configurations:
248 ipsec: boolean
250 Tunnel encryption configuration. If this column is set to be
251 true, all OVN tunnels will be encrypted with IPsec.
252
254 Each row in this table represents a hypervisor or gateway (a chassis)
255 in the physical network. Each chassis, via ovn-controller/ovn-con‐
256 troller-vtep, adds and updates its own row, and keeps a copy of the
257 remaining rows to determine how to reach other hypervisors.
258 When a chassis shuts down gracefully, it should remove its own row.
260 (This is not critical because resources hosted on the chassis are
261 equally unreachable regardless of whether the row is present.) If a
262 chassis shuts down permanently without removing its row, some kind of
263 manual or automatic cleanup is eventually needed; we can devise a
264 process for that as necessary.
265 Summary:
267 name string (must be unique within table)
268 hostname string
269 nb_cfg integer
270 other_config : ovn-bridge-mappings
271 optional string
272 other_config : datapath-type optional string
273 other_config : iface-types optional string
274 other_config : ovn-cms-options
275 optional string
276 other_config : is-interconn optional string
277 other_config : is-remote optional string
278 transport_zones set of strings
279 other_config : ovn-chassis-mac-mappings
280 optional string
281 other_config : port-up-notif optional string
282 Common Columns:
283 external_ids map of string-string pairs
284 Encapsulation Configuration:
285 encaps set of 1 or more Encaps
286 Gateway Configuration:
287 vtep_logical_switches set of strings
288 Details:
290 name: string (must be unique within table)
291 OVN does not prescribe a particular format for chassis names.
292 ovn-controller populates this column using external_ids:system-
293 id in the Open_vSwitch database’s Open_vSwitch table. ovn-con‐
294 troller-vtep populates this column with name in the hard‐
295 ware_vtep database’s Physical_Switch table.
296 hostname: string
298 The hostname of the chassis, if applicable. ovn-controller will
299 populate this column with the hostname of the host it is running
300 on. ovn-controller-vtep will leave this column empty.
301 nb_cfg: integer
303 Deprecated. This column is replaced by the nb_cfg column of the
304 Chassis_Private table.
305 other_config : ovn-bridge-mappings: optional string
307 ovn-controller populates this key with the set of bridge map‐
308 pings it has been configured to use. Other applications should
309 treat this key as read-only. See ovn-controller(8) for more
310 information.
311 other_config : datapath-type: optional string
313 ovn-controller populates this key with the datapath type config‐
314 ured in the datapath_type column of the Open_vSwitch database’s
315 Bridge table. Other applications should treat this key as read-
316 only. See ovn-controller(8) for more information.
317 other_config : iface-types: optional string
319 ovn-controller populates this key with the interface types con‐
320 figured in the iface_types column of the Open_vSwitch database’s
321 Open_vSwitch table. Other applications should treat this key as
322 read-only. See ovn-controller(8) for more information.
323 other_config : ovn-cms-options: optional string
325 ovn-controller populates this key with the set of options con‐
326 figured in the external_ids:ovn-cms-options column of the
327 Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
328 troller(8) for more information.
329 other_config : is-interconn: optional string
331 ovn-controller populates this key with the setting configured in
332 the external_ids:ovn-is-interconn column of the Open_vSwitch
333 database’s Open_vSwitch table. If set to true, the chassis is
334 used as an interconnection gateway. See ovn-controller(8) for
335 more information.
336 other_config : is-remote: optional string
338 ovn-ic set this key to true for remote interconnection gateway
339 chassises learned from the interconnection southbound database.
340 See ovn-ic(8) for more information.
341 transport_zones: set of strings
343 ovn-controller populates this key with the transport zones con‐
344 figured in the external_ids:ovn-transport-zones column of the
345 Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
346 troller(8) for more information.
347 other_config : ovn-chassis-mac-mappings: optional string
349 ovn-controller populates this key with the set of options con‐
350 figured in the external_ids:ovn-chassis-mac-mappings column of
351 the Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
352 troller(8) for more information.
353 other_config : port-up-notif: optional string
355 ovn-controller populates this key with true when it supports
356 Port_Binding.up.
357 Common Columns:
359 The overall purpose of these columns is described under Common Columns
361 at the beginning of this document.
362 external_ids: map of string-string pairs
364 Encapsulation Configuration:
366 OVN uses encapsulation to transmit logical dataplane packets between
368 chassis.
369 encaps: set of 1 or more Encaps
371 Points to supported encapsulation configurations to transmit
372 logical dataplane packets to this chassis. Each entry is a Encap
373 record that describes the configuration.
374 Gateway Configuration:
376 A gateway is a chassis that forwards traffic between the OVN-managed
378 part of a logical network and a physical VLAN, extending a tunnel-based
379 logical network into a physical network. Gateways are typically dedi‐
380 cated nodes that do not host VMs and will be controlled by ovn-con‐
381 troller-vtep.
382 vtep_logical_switches: set of strings
384 Stores all VTEP logical switch names connected by this gateway
385 chassis. The Port_Binding table entry with options:vtep-physi‐
386 cal-switch equal Chassis name, and options:vtep-logical-switch
387 value in Chassis vtep_logical_switches, will be associated with
388 this Chassis.
389
391 Each row in this table maintains per chassis private data that are
392 accessed only by the owning chassis (write only) and ovn-northd, not by
393 any other chassis. These data are stored in this separate table instead
394 of the Chassis table for performance considerations: the rows in this
395 table can be conditionally monitored by chassises so that each chassis
396 only get update notifications for its own row, to avoid unnecessary
397 chassis private data update flooding in a large scale deployment.
398 Summary:
400 name string (must be unique within table)
401 chassis optional weak reference to Chassis
402 nb_cfg integer
403 nb_cfg_timestamp integer
404 Common Columns:
405 external_ids map of string-string pairs
406 Details:
408 name: string (must be unique within table)
409 The name of the chassis that owns these chassis-private data.
410 chassis: optional weak reference to Chassis
412 The reference to Chassis table for the chassis that owns these
413 chassis-private data.
414 nb_cfg: integer
416 Sequence number for the configuration. When ovn-controller
417 updates the configuration of a chassis from the contents of the
418 southbound database, it copies nb_cfg from the SB_Global table
419 into this column.
420 nb_cfg_timestamp: integer
422 The timestamp when ovn-controller finishes processing the change
423 corresponding to nb_cfg.
424 Common Columns:
426 The overall purpose of these columns is described under Common Columns
428 at the beginning of this document.
429 external_ids: map of string-string pairs
431
433 The encaps column in the Chassis table refers to rows in this table to
434 identify how OVN may transmit logical dataplane packets to this chas‐
435 sis. Each chassis, via ovn-controller(8) or ovn-controller-vtep(8),
436 adds and updates its own rows and keeps a copy of the remaining rows to
437 determine how to reach other chassis.
438 Summary:
440 type string, one of geneve, stt, or vxlan
441 options map of string-string pairs
442 options : csum optional string, either true or false
443 options : dst_port optional string, containing an integer
444 ip string
445 chassis_name string
446 Details:
448 type: string, one of geneve, stt, or vxlan
449 The encapsulation to use to transmit packets to this chassis.
450 Hypervisors must use either geneve or stt. Gateways may use
451 vxlan, geneve, or stt.
452 options: map of string-string pairs
454 Options for configuring the encapsulation, which may be type
455 specific.
456 options : csum: optional string, either true or false
458 csum indicates whether this chassis can transmit and receive
459 packets that include checksums with reasonable performance. It
460 hints to senders transmitting data to this chassis that they
461 should use checksums to protect OVN metadata. ovn-controller
462 populates this key with the value defined in external_ids:ovn-
463 encap-csum column of the Open_vSwitch database’s Open_vSwitch
464 table. Other applications should treat this key as read-only.
465 See ovn-controller(8) for more information.
466 In terms of performance, checksumming actually significantly
468 increases throughput in most common cases when running on Linux
469 based hosts without NICs supporting encapsulation hardware off‐
470 load (around 60% for bulk traffic). The reason is that generally
471 all NICs are capable of offloading transmitted and received
472 TCP/UDP checksums (viewed as ordinary data packets and not as
473 tunnels). The benefit comes on the receive side where the vali‐
474 dated outer checksum can be used to additionally validate an
475 inner checksum (such as TCP), which in turn allows aggregation
476 of packets to be more efficiently handled by the rest of the
477 stack.
478 Not all devices see such a benefit. The most notable exception
480 is hardware VTEPs. These devices are designed to not buffer
481 entire packets in their switching engines and are therefore
482 unable to efficiently compute or validate full packet checksums.
483 In addition certain versions of the Linux kernel are not able to
484 fully take advantage of encapsulation NIC offloads in the pres‐
485 ence of checksums. (This is actually a pretty narrow corner case
486 though: earlier versions of Linux don’t support encapsulation
487 offloads at all and later versions support both offloads and
488 checksums well.)
489 csum defaults to false for hardware VTEPs and true for all other
491 cases.
492 This option applies to geneve and vxlan encapsulations.
494 options : dst_port: optional string, containing an integer
496 If set, overrides the UDP (for geneve and vxlan) or TCP (for
497 stt) destination port.
498 ip: string
500 The IPv4 address of the encapsulation tunnel endpoint.
501 chassis_name: string
503 The name of the chassis that created this encap.
504
506 This table contains address sets synced from the Address_Set table in
507 the OVN_Northbound database and address sets generated from the
508 Port_Group table in the OVN_Northbound database.
509 See the documentation for the Address_Set table and Port_Group table in
511 the OVN_Northbound database for details.
512 Summary:
514 name string (must be unique within table)
515 addresses set of strings
516 Details:
518 name: string (must be unique within table)
519 addresses: set of strings
521
523 This table contains names for the logical switch ports in the
524 OVN_Northbound database that belongs to the same group that is defined
525 in Port_Group in the OVN_Northbound database.
526 Summary:
528 name string (must be unique within table)
529 ports set of strings
530 Details:
532 name: string (must be unique within table)
533 ports: set of strings
535
537 Each row in this table represents one logical flow. ovn-northd popu‐
538 lates this table with logical flows that implement the L2 and L3
539 topologies specified in the OVN_Northbound database. Each hypervisor,
540 via ovn-controller, translates the logical flows into OpenFlow flows
541 specific to its hypervisor and installs them into Open vSwitch.
542 Logical flows are expressed in an OVN-specific format, described here.
544 A logical datapath flow is much like an OpenFlow flow, except that the
545 flows are written in terms of logical ports and logical datapaths
546 instead of physical ports and physical datapaths. Translation between
547 logical and physical flows helps to ensure isolation between logical
548 datapaths. (The logical flow abstraction also allows the OVN central‐
549 ized components to do less work, since they do not have to separately
550 compute and push out physical flows to each chassis.)
551 The default action when no flow matches is to drop packets.
553 Architectural Logical Life Cycle of a Packet
555 This following description focuses on the life cycle of a packet
557 through a logical datapath, ignoring physical details of the implemen‐
558 tation. Please refer to Architectural Physical Life Cycle of a Packet
559 in ovn-architecture(7) for the physical information.
560 The description here is written as if OVN itself executes these steps,
562 but in fact OVN (that is, ovn-controller) programs Open vSwitch, via
563 OpenFlow and OVSDB, to execute them on its behalf.
564 At a high level, OVN passes each packet through the logical datapath’s
566 logical ingress pipeline, which may output the packet to one or more
567 logical port or logical multicast groups. For each such logical output
568 port, OVN passes the packet through the datapath’s logical egress pipe‐
569 line, which may either drop the packet or deliver it to the destina‐
570 tion. Between the two pipelines, outputs to logical multicast groups
571 are expanded into logical ports, so that the egress pipeline only pro‐
572 cesses a single logical output port at a time. Between the two pipe‐
573 lines is also where, when necessary, OVN encapsulates a packet in a
574 tunnel (or tunnels) to transmit to remote hypervisors.
575 In more detail, to start, OVN searches the Logical_Flow table for a row
577 with correct logical_datapath or a logical_dp_group, a pipeline of
578 ingress, a table_id of 0, and a match that is true for the packet. If
579 none is found, OVN drops the packet. If OVN finds more than one, it
580 chooses the match with the highest priority. Then OVN executes each of
581 the actions specified in the row’s actions column, in the order speci‐
582 fied. Some actions, such as those to modify packet headers, require no
583 further details. The next and output actions are special.
584 The next action causes the above process to be repeated recursively,
586 except that OVN searches for table_id of 1 instead of 0. Similarly, any
587 next action in a row found in that table would cause a further search
588 for a table_id of 2, and so on. When recursive processing completes,
589 flow control returns to the action following next.
590 The output action also introduces recursion. Its effect depends on the
592 current value of the outport field. Suppose outport designates a logi‐
593 cal port. First, OVN compares inport to outport; if they are equal, it
594 treats the output as a no-op by default. In the common case, where they
595 are different, the packet enters the egress pipeline. This transition
596 to the egress pipeline discards register data, e.g. reg0 ... reg9 and
597 connection tracking state, to achieve uniform behavior regardless of
598 whether the egress pipeline is on a different hypervisor (because reg‐
599 isters aren’t preserve across tunnel encapsulation).
600 To execute the egress pipeline, OVN again searches the Logical_Flow ta‐
602 ble for a row with correct logical_datapath or a logical_dp_group, a
603 table_id of 0, a match that is true for the packet, but now looking for
604 a pipeline of egress. If no matching row is found, the output becomes a
605 no-op. Otherwise, OVN executes the actions for the matching flow (which
606 is chosen from multiple, if necessary, as already described).
607 In the egress pipeline, the next action acts as already described,
609 except that it, of course, searches for egress flows. The output
610 action, however, now directly outputs the packet to the output port
611 (which is now fixed, because outport is read-only within the egress
612 pipeline).
613 The description earlier assumed that outport referred to a logical
615 port. If it instead designates a logical multicast group, then the
616 description above still applies, with the addition of fan-out from the
617 logical multicast group to each logical port in the group. For each
618 member of the group, OVN executes the logical pipeline as described,
619 with the logical output port replaced by the group member.
620 Pipeline Stages
622 ovn-northd populates the Logical_Flow table with the logical flows
624 described in detail in ovn-northd(8).
625 Summary:
627 logical_datapath optional Datapath_Binding
628 logical_dp_group optional Logical_DP_Group
629 pipeline string, either egress or ingress
630 table_id integer, in range 0 to 23
631 priority integer, in range 0 to 65,535
632 match string
633 actions string
634 external_ids : stage-name optional string
635 external_ids : stage-hint optional string, containing an uuid
636 external_ids : source optional string
637 Common Columns:
638 external_ids map of string-string pairs
639 Details:
641 logical_datapath: optional Datapath_Binding
642 The logical datapath to which the logical flow belongs.
643 logical_dp_group: optional Logical_DP_Group
645 The group of logical datapaths to which the logical flow
646 belongs. This means that the same logical flow belongs to all
647 datapaths in a group.
648 pipeline: string, either egress or ingress
650 The primary flows used for deciding on a packet’s destination
651 are the ingress flows. The egress flows implement ACLs. See Log‐
652 ical Life Cycle of a Packet, above, for details.
653 table_id: integer, in range 0 to 23
655 The stage in the logical pipeline, analogous to an OpenFlow ta‐
656 ble number.
657 priority: integer, in range 0 to 65,535
659 The flow’s priority. Flows with numerically higher priority take
660 precedence over those with lower. If two logical datapath flows
661 with the same priority both match, then the one actually applied
662 to the packet is undefined.
663 match: string
665 A matching expression. OVN provides a superset of OpenFlow
666 matching capabilities, using a syntax similar to Boolean expres‐
667 sions in a programming language.
668 The most important components of match expression are compar‐
670 isons between symbols and constants, e.g. ip4.dst ==
671 192.168.0.1, ip.proto == 6, arp.op == 1, eth.type == 0x800. The
672 logical AND operator && and logical OR operator || can combine
673 comparisons into a larger expression.
674 Matching expressions also support parentheses for grouping, the
676 logical NOT prefix operator !, and literals 0 and 1 to express
677 ``false’’ or ``true,’’ respectively. The latter is useful by
678 itself as a catch-all expression that matches every packet.
679 Match expressions also support a kind of function syntax. The
681 following functions are supported:
682 is_chassis_resident(lport)
684 Evaluates to true on a chassis on which logical port
685 lport (a quoted string) resides, and to false elsewhere.
686 This function was introduced in OVN 2.7.
687 Symbols
689 Type. Symbols have integer or string type. Integer symbols have
691 a width in bits.
692 Kinds. There are three kinds of symbols:
694 · Fields. A field symbol represents a packet header or
696 metadata field. For example, a field named vlan.tci might
697 represent the VLAN TCI field in a packet.
698 A field symbol can have integer or string type. Integer
700 fields can be nominal or ordinal (see Level of Measure‐
701 ment, below).
702 · Subfields. A subfield represents a subset of bits from a
704 larger field. For example, a field vlan.vid might be
705 defined as an alias for vlan.tci[0..11]. Subfields are
706 provided for syntactic convenience, because it is always
707 possible to instead refer to a subset of bits from a
708 field directly.
709 Only ordinal fields (see Level of Measurement, below) may
711 have subfields. Subfields are always ordinal.
712 · Predicates. A predicate is shorthand for a Boolean
714 expression. Predicates may be used much like 1-bit
715 fields. For example, ip4 might expand to eth.type ==
716 0x800. Predicates are provided for syntactic convenience,
717 because it is always possible to instead specify the
718 underlying expression directly.
719 A predicate whose expansion refers to any nominal field
721 or predicate (see Level of Measurement, below) is nomi‐
722 nal; other predicates have Boolean level of measurement.
723 Level of Measurement. See
725 http://en.wikipedia.org/wiki/Level_of_measurement for the sta‐
726 tistical concept on which this classification is based. There
727 are three levels:
728 · Ordinal. In statistics, ordinal values can be ordered on
730 a scale. OVN considers a field (or subfield) to be ordi‐
731 nal if its bits can be examined individually. This is
732 true for the OpenFlow fields that OpenFlow or Open
733 vSwitch makes ``maskable.’’
734 Any use of a ordinal field may specify a single bit or a
736 range of bits, e.g. vlan.tci[13..15] refers to the PCP
737 field within the VLAN TCI, and eth.dst[40] refers to the
738 multicast bit in the Ethernet destination address.
739 OVN supports all the usual arithmetic relations (==, !=,
741 <, <=, >, and >=) on ordinal fields and their subfields,
742 because OVN can implement these in OpenFlow and Open
743 vSwitch as collections of bitwise tests.
744 · Nominal. In statistics, nominal values cannot be usefully
746 compared except for equality. This is true of OpenFlow
747 port numbers, Ethernet types, and IP protocols are exam‐
748 ples: all of these are just identifiers assigned arbi‐
749 trarily with no deeper meaning. In OpenFlow and Open
750 vSwitch, bits in these fields generally aren’t individu‐
751 ally addressable.
752 OVN only supports arithmetic tests for equality on nomi‐
754 nal fields, because OpenFlow and Open vSwitch provide no
755 way for a flow to efficiently implement other comparisons
756 on them. (A test for inequality can be sort of built out
757 of two flows with different priorities, but OVN matching
758 expressions always generate flows with a single prior‐
759 ity.)
760 String fields are always nominal.
762 · Boolean. A nominal field that has only two values, 0 and
764 1, is somewhat exceptional, since it is easy to support
765 both equality and inequality tests on such a field:
766 either one can be implemented as a test for 0 or 1.
767 Only predicates (see above) have a Boolean level of mea‐
769 surement.
770 This isn’t a standard level of measurement.
772 Prerequisites. Any symbol can have prerequisites, which are
774 additional condition implied by the use of the symbol. For exam‐
775 ple, For example, icmp4.type symbol might have prerequisite
776 icmp4, which would cause an expression icmp4.type == 0 to be
777 interpreted as icmp4.type == 0 && icmp4, which would in turn
778 expand to icmp4.type == 0 && eth.type == 0x800 && ip4.proto == 1
779 (assuming icmp4 is a predicate defined as suggested under Types
780 above).
781 Relational operators
783 All of the standard relational operators ==, !=, <, <=, >, and
785 >= are supported. Nominal fields support only == and !=, and
786 only in a positive sense when outer ! are taken into account,
787 e.g. given string field inport, inport == "eth0" and !(inport !=
788 "eth0") are acceptable, but not inport != "eth0".
789 The implementation of == (or != when it is negated), is more
791 efficient than that of the other relational operators.
792 Constants
794 Integer constants may be expressed in decimal, hexadecimal pre‐
796 fixed by 0x, or as dotted-quad IPv4 addresses, IPv6 addresses in
797 their standard forms, or Ethernet addresses as colon-separated
798 hex digits. A constant in any of these forms may be followed by
799 a slash and a second constant (the mask) in the same form, to
800 form a masked constant. IPv4 and IPv6 masks may be given as
801 integers, to express CIDR prefixes.
802 String constants have the same syntax as quoted strings in JSON
804 (thus, they are Unicode strings).
805 Some operators support sets of constants written inside curly
807 braces { ... }. Commas between elements of a set, and after the
808 last elements, are optional. With ==, ``field == { constant1,
809 constant2, ... }’’ is syntactic sugar for ``field == constant1
810 || field == constant2 || .... Similarly, ``field != { constant1,
811 constant2, ... }’’ is equivalent to ``field != constant1 &&
812 field != constant2 && ...’’.
813 You may refer to a set of IPv4, IPv6, or MAC addresses stored in
815 the Address_Set table by its name. An Address_Set with a name of
816 set1 can be referred to as $set1.
817 You may refer to a group of logical switch ports stored in the
819 Port_Group table by its name. An Port_Group with a name of
820 port_group1 can be referred to as @port_group1.
821 Additionally, you may refer to the set of addresses belonging to
823 a group of logical switch ports stored in the Port_Group table
824 by its name followed by a suffix ’_ip4’/’_ip6’. The IPv4 address
825 set of a Port_Group with a name of port_group1 can be referred
826 to as $port_group1_ip4, and the IPv6 address set of the same
827 Port_Group can be referred to as $port_group1_ip6
828 Miscellaneous
830 Comparisons may name the symbol or the constant first, e.g.
832 tcp.src == 80 and 80 == tcp.src are both acceptable.
833 Tests for a range may be expressed using a syntax like 1024 <=
835 tcp.src <= 49151, which is equivalent to 1024 <= tcp.src &&
836 tcp.src <= 49151.
837 For a one-bit field or predicate, a mention of its name is
839 equivalent to symobl == 1, e.g. vlan.present is equivalent to
840 vlan.present == 1. The same is true for one-bit subfields, e.g.
841 vlan.tci[12]. There is no technical limitation to implementing
842 the same for ordinal fields of all widths, but the implementa‐
843 tion is expensive enough that the syntax parser requires writing
844 an explicit comparison against zero to make mistakes less
845 likely, e.g. in tcp.src != 0 the comparison against 0 is
846 required.
847 Operator precedence is as shown below, from highest to lowest.
849 There are two exceptions where parentheses are required even
850 though the table would suggest that they are not: && and ||
851 require parentheses when used together, and ! requires parenthe‐
852 ses when applied to a relational expression. Thus, in (eth.type
853 == 0x800 || eth.type == 0x86dd) && ip.proto == 6 or !(arp.op ==
854 1), the parentheses are mandatory.
855 · ()
857 · == != < <= > >=
859 · !
861 · && ||
863 Comments may be introduced by //, which extends to the next new-
865 line. Comments within a line may be bracketed by /* and */. Mul‐
866 tiline comments are not supported.
867 Symbols
869 Most of the symbols below have integer type. Only inport and
871 outport have string type. inport names a logical port. Thus, its
872 value is a logical_port name from the Port_Binding table. out‐
873 port may name a logical port, as inport, or a logical multicast
874 group defined in the Multicast_Group table. For both symbols,
875 only names within the flow’s logical datapath may be used.
876 The regX symbols are 32-bit integers. The xxregX symbols are
878 128-bit integers, which overlay four of the 32-bit registers:
879 xxreg0 overlays reg0 through reg3, with reg0 supplying the most-
880 significant bits of xxreg0 and reg3 the least-signficant. xxreg1
881 similarly overlays reg4 through reg7.
882 · reg0...reg9
884 · xxreg0 xxreg1
886 · inport outport
888 · flags.loopback
890 · pkt.mark
892 · eth.src eth.dst eth.type
894 · vlan.tci vlan.vid vlan.pcp vlan.present
896 · ip.proto ip.dscp ip.ecn ip.ttl ip.frag
898 · ip4.src ip4.dst
900 · ip6.src ip6.dst ip6.label
902 · arp.op arp.spa arp.tpa arp.sha arp.tha
904 · tcp.src tcp.dst tcp.flags
906 · udp.src udp.dst
908 · sctp.src sctp.dst
910 · icmp4.type icmp4.code
912 · icmp6.type icmp6.code
914 · nd.target nd.sll nd.tll
916 · ct_mark ct_label
918 · ct_state, which has several Boolean subfields. The
920 ct_next action initializes the following subfields:
921 · ct.trk: Always set to true by ct_next to indicate
923 that connection tracking has taken place. All
924 other ct subfields have ct.trk as a prerequisite.
925 · ct.new: True for a new flow
927 · ct.est: True for an established flow
929 · ct.rel: True for a related flow
931 · ct.rpl: True for a reply flow
933 · ct.inv: True for a connection entry in a bad state
935 The ct_dnat, ct_snat, and ct_lb actions initialize the
937 following subfields:
938 · ct.dnat: True for a packet whose destination IP
940 address has been changed.
941 · ct.snat: True for a packet whose source IP address
943 has been changed.
944 The following predicates are supported:
946 · eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff
948 · eth.mcast expands to eth.dst[40]
950 · vlan.present expands to vlan.tci[12]
952 · ip4 expands to eth.type == 0x800
954 · ip4.src_mcast expands to ip4.src[28..31] == 0xe
956 · ip4.mcast expands to ip4.dst[28..31] == 0xe
958 · ip6 expands to eth.type == 0x86dd
960 · ip expands to ip4 || ip6
962 · icmp4 expands to ip4 && ip.proto == 1
964 · icmp6 expands to ip6 && ip.proto == 58
966 · icmp expands to icmp4 || icmp6
968 · ip.is_frag expands to ip.frag[0]
970 · ip.later_frag expands to ip.frag[1]
972 · ip.first_frag expands to ip.is_frag && !ip.later_frag
974 · arp expands to eth.type == 0x806
976 · nd expands to icmp6.type == {135, 136} && icmp6.code == 0
978 && ip.ttl == 255
979 · nd_ns expands to icmp6.type == 135 && icmp6.code == 0 &&
981 ip.ttl == 255
982 · nd_na expands to icmp6.type == 136 && icmp6.code == 0 &&
984 ip.ttl == 255
985 · nd_rs expands to icmp6.type == 133 && icmp6.code == 0 &&
987 ip.ttl == 255
988 · nd_ra expands to icmp6.type == 134 && icmp6.code == 0 &&
990 ip.ttl == 255
991 · tcp expands to ip.proto == 6
993 · udp expands to ip.proto == 17
995 · sctp expands to ip.proto == 132
997 actions: string
999 Logical datapath actions, to be executed when the logical flow
1000 represented by this row is the highest-priority match.
1001 Actions share lexical syntax with the match column. An empty set
1003 of actions (or one that contains just white space or comments),
1004 or a set of actions that consists of just drop;, causes the
1005 matched packets to be dropped. Otherwise, the column should con‐
1006 tain a sequence of actions, each terminated by a semicolon.
1007 The following actions are defined:
1009 output;
1011 In the ingress pipeline, this action executes the egress
1012 pipeline as a subroutine. If outport names a logical
1013 port, the egress pipeline executes once; if it is a mul‐
1014 ticast group, the egress pipeline runs once for each log‐
1015 ical port in the group.
1016 In the egress pipeline, this action performs the actual
1018 output to the outport logical port. (In the egress pipe‐
1019 line, outport never names a multicast group.)
1020 By default, output to the input port is implicitly
1022 dropped, that is, output becomes a no-op if outport ==
1023 inport. Occasionally it may be useful to override this
1024 behavior, e.g. to send an ARP reply to an ARP request; to
1025 do so, use flags.loopback = 1 to allow the packet to
1026 "hair-pin" back to the input port.
1027 next;
1029 next(table);
1030 next(pipeline=pipeline, table=table);
1031 Executes the given logical datapath table in pipeline as a
1032 subroutine. The default table is just after the current
1033 one. If pipeline is specified, it may be ingress or egress;
1034 the default pipeline is the one currently executing.
1035 Actions in the both ingress and egress pipeline can use
1036 next to jump across the other pipeline. Actions in the
1037 ingress pipeline should use next to jump into the specific
1038 table of egress pipeline only if it is certain that the
1039 packets are local and not tunnelled and wants to skip cer‐
1040 tain stages in the packet processing.
1041 field = constant;
1043 Sets data or metadata field field to constant value con‐
1044 stant, e.g. outport = "vif0"; to set the logical output
1045 port. To set only a subset of bits in a field, specify a
1046 subfield for field or a masked constant, e.g. one may use
1047 vlan.pcp[2] = 1; or vlan.pcp = 4/4; to set the most sigifi‐
1048 cant bit of the VLAN PCP.
1049 Assigning to a field with prerequisites implicitly adds
1051 those prerequisites to match; thus, for example, a flow
1052 that sets tcp.dst applies only to TCP flows, regardless of
1053 whether its match mentions any TCP field.
1054 Not all fields are modifiable (e.g. eth.type and ip.proto
1056 are read-only), and not all modifiable fields may be par‐
1057 tially modified (e.g. ip.ttl must assigned as a whole). The
1058 outport field is modifiable in the ingress pipeline but not
1059 in the egress pipeline.
1060 ovn_field = constant;
1062 Sets OVN field ovn_field to constant value constant.
1063 OVN supports setting the values of certain fields which are
1065 not yet supported in OpenFlow to set or modify them.
1066 Below are the supported OVN fields:
1068 · icmp4.frag_mtu icmp6.frag_mtu
1070 This field sets the low-order 16 bits of the
1072 ICMP{4,6} header field that is labelled "unused" in
1073 the ICMP specification as defined in the RFC 1191
1074 with the value specified in constant.
1075 Eg. icmp4.frag_mtu = 1500;
1077 field1 = field2;
1079 Sets data or metadata field field1 to the value of data or
1080 metadata field field2, e.g. reg0 = ip4.src; copies ip4.src
1081 into reg0. To modify only a subset of a field’s bits, spec‐
1082 ify a subfield for field1 or field2 or both, e.g. vlan.pcp
1083 = reg0[0..2]; copies the least-significant bits of reg0
1084 into the VLAN PCP.
1085 field1 and field2 must be the same type, either both string
1087 or both integer fields. If they are both integer fields,
1088 they must have the same width.
1089 If field1 or field2 has prerequisites, they are added
1091 implicitly to match. It is possible to write an assignment
1092 with contradictory prerequisites, such as ip4.src =
1093 ip6.src[0..31];, but the contradiction means that a logical
1094 flow with such an assignment will never be matched.
1095 field1 <-> field2;
1097 Similar to field1 = field2; except that the two values are
1098 exchanged instead of copied. Both field1 and field2 must
1099 modifiable.
1100 ip.ttl--;
1102 Decrements the IPv4 or IPv6 TTL. If this would make the TTL
1103 zero or negative, then processing of the packet halts; no
1104 further actions are processed. (To properly handle such
1105 cases, a higher-priority flow should match on ip.ttl == {0,
1106 1};.)
1107 Prerequisite: ip
1109 ct_next;
1111 Apply connection tracking to the flow, initializing
1112 ct_state for matching in later tables. Automatically moves
1113 on to the next table, as if followed by next.
1114 As a side effect, IP fragments will be reassembled for
1116 matching. If a fragmented packet is output, then it will be
1117 sent with any overlapping fragments squashed. The connec‐
1118 tion tracking state is scoped by the logical port when the
1119 action is used in a flow for a logical switch, so overlap‐
1120 ping addresses may be used. To allow traffic related to the
1121 matched flow, execute ct_commit . Connection tracking state
1122 is scoped by the logical topology when the action is used
1123 in a flow for a router.
1124 It is possible to have actions follow ct_next, but they
1126 will not have access to any of its side-effects and is not
1127 generally useful.
1128 ct_commit { };
1130 ct_commit { ct_mark=value[/mask]; };
1131 ct_commit { ct_label=value[/mask]; };
1132 ct_commit { ct_mark=value[/mask]; ct_label=value[/mask]; };
1133 Commit the flow to the connection tracking entry associated
1134 with it by a previous call to ct_next. When
1135 ct_mark=value[/mask] and/or ct_label=value[/mask] are sup‐
1136 plied, ct_mark and/or ct_label will be set to the values
1137 indicated by value[/mask] on the connection tracking entry.
1138 ct_mark is a 32-bit field. ct_label is a 128-bit field. The
1139 value[/mask] should be specified in hex string if more than
1140 64bits are to be used. Registers and other named fields can
1141 be used for value. ct_mark and ct_label may be sub-
1142 addressed in order to have specific bits set.
1143 Note that if you want processing to continue in the next
1145 table, you must execute the next action after ct_commit.
1146 You may also leave out next which will commit connection
1147 tracking state, and then drop the packet. This could be
1148 useful for setting ct_mark on a connection tracking entry
1149 before dropping a packet, for example.
1150 ct_dnat;
1152 ct_dnat(IP);
1153 ct_dnat sends the packet through the DNAT zone in connec‐
1154 tion tracking table to unDNAT any packet that was DNATed in
1155 the opposite direction. The packet is then automatically
1156 sent to to the next tables as if followed by next; action.
1157 The next tables will see the changes in the packet caused
1158 by the connection tracker.
1159 ct_dnat(IP) sends the packet through the DNAT zone to
1161 change the destination IP address of the packet to the one
1162 provided inside the parentheses and commits the connection.
1163 The packet is then automatically sent to the next tables as
1164 if followed by next; action. The next tables will see the
1165 changes in the packet caused by the connection tracker.
1166 ct_snat;
1168 ct_snat(IP);
1169 ct_snat sends the packet through the SNAT zone to unSNAT
1170 any packet that was SNATed in the opposite direction. The
1171 packet is automatically sent to the next tables as if fol‐
1172 lowed by the next; action. The next tables will see the
1173 changes in the packet caused by the connection tracker.
1174 ct_snat(IP) sends the packet through the SNAT zone to
1176 change the source IP address of the packet to the one pro‐
1177 vided inside the parenthesis and commits the connection.
1178 The packet is then automatically sent to the next tables as
1179 if followed by next; action. The next tables will see the
1180 changes in the packet caused by the connection tracker.
1181 ct_clear;
1183 Clears connection tracking state.
1184 clone { action; ... };
1186 Makes a copy of the packet being processed and executes
1187 each action on the copy. Actions following the clone
1188 action, if any, apply to the original, unmodified packet.
1189 This can be used as a way to ``save and restore’’ the
1190 packet around a set of actions that may modify it and
1191 should not persist.
1192 arp { action; ... };
1194 Temporarily replaces the IPv4 packet being processed by an
1195 ARP packet and executes each nested action on the ARP
1196 packet. Actions following the arp action, if any, apply to
1197 the original, unmodified packet.
1198 The ARP packet that this action operates on is initialized
1200 based on the IPv4 packet being processed, as follows. These
1201 are default values that the nested actions will probably
1202 want to change:
1203 · eth.src unchanged
1205 · eth.dst unchanged
1207 · eth.type = 0x0806
1209 · arp.op = 1 (ARP request)
1211 · arp.sha copied from eth.src
1213 · arp.spa copied from ip4.src
1215 · arp.tha = 00:00:00:00:00:00
1217 · arp.tpa copied from ip4.dst
1219 The ARP packet has the same VLAN header, if any, as the IP
1221 packet it replaces.
1222 Prerequisite: ip4
1224 get_arp(P, A);
1226 Parameters: logical port string field P, 32-bit IP address
1227 field A.
1228 Looks up A in P’s mac binding table. If an entry is found,
1230 stores its Ethernet address in eth.dst, otherwise stores
1231 00:00:00:00:00:00 in eth.dst.
1232 Example: get_arp(outport, ip4.dst);
1234 put_arp(P, A, E);
1236 Parameters: logical port string field P, 32-bit IP address
1237 field A, 48-bit Ethernet address field E.
1238 Adds or updates the entry for IP address A in logical port
1240 P’s mac binding table, setting its Ethernet address to E.
1241 Example: put_arp(inport, arp.spa, arp.sha);
1243 R = lookup_arp(P, A, M);
1245 Parameters: logical port string field P, 32-bit IP address
1246 field A, 48-bit MAC address field M.
1247 Result: stored to a 1-bit subfield R.
1249 Looks up A and M in P’s mac binding table. If an entry is
1251 found, stores 1 in the 1-bit subfield R, else 0.
1252 Example: reg0[0] = lookup_arp(inport, arp.spa, arp.sha);
1254 R = lookup_arp_ip(P, A);
1256 Parameters: logical port string field P, 32-bit IP address
1257 field A.
1258 Result: stored to a 1-bit subfield R.
1260 Looks up A in P’s mac binding table. If an entry is found,
1262 stores 1 in the 1-bit subfield R, else 0.
1263 Example: reg0[0] = lookup_arp_ip(inport, arp.spa);
1265 nd_ns { action; ... };
1267 Temporarily replaces the IPv6 packet being processed by an
1268 IPv6 Neighbor Solicitation packet and executes each nested
1269 action on the IPv6 NS packet. Actions following the nd_ns
1270 action, if any, apply to the original, unmodified packet.
1271 The IPv6 NS packet that this action operates on is initial‐
1273 ized based on the IPv6 packet being processed, as follows.
1274 These are default values that the nested actions will prob‐
1275 ably want to change:
1276 · eth.src unchanged
1278 · eth.dst set to IPv6 multicast MAC address
1280 · eth.type = 0x86dd
1282 · ip6.src copied from ip6.src
1284 · ip6.dst set to IPv6 Solicited-Node multicast address
1286 · icmp6.type = 135 (Neighbor Solicitation)
1288 · nd.target copied from ip6.dst
1290 The IPv6 NS packet has the same VLAN header, if any, as the
1292 IP packet it replaces.
1293 Prerequisite: ip6
1295 nd_na { action; ... };
1297 Temporarily replaces the IPv6 neighbor solicitation packet
1298 being processed by an IPv6 neighbor advertisement (NA)
1299 packet and executes each nested action on the NA packet.
1300 Actions following the nd_na action, if any, apply to the
1301 original, unmodified packet.
1302 The NA packet that this action operates on is initialized
1304 based on the IPv6 packet being processed, as follows. These
1305 are default values that the nested actions will probably
1306 want to change:
1307 · eth.dst exchanged with eth.src
1309 · eth.type = 0x86dd
1311 · ip6.dst copied from ip6.src
1313 · ip6.src copied from nd.target
1315 · icmp6.type = 136 (Neighbor Advertisement)
1317 · nd.target unchanged
1319 · nd.sll = 00:00:00:00:00:00
1321 · nd.tll copied from eth.dst
1323 The ND packet has the same VLAN header, if any, as the IPv6
1325 packet it replaces.
1326 Prerequisite: nd_ns
1328 nd_na_router { action; ... };
1330 Temporarily replaces the IPv6 neighbor solicitation packet
1331 being processed by an IPv6 neighbor advertisement (NA)
1332 packet, sets ND_NSO_ROUTER in the RSO flags and executes
1333 each nested action on the NA packet. Actions following the
1334 nd_na_router action, if any, apply to the original, unmodi‐
1335 fied packet.
1336 The NA packet that this action operates on is initialized
1338 based on the IPv6 packet being processed, as follows. These
1339 are default values that the nested actions will probably
1340 want to change:
1341 · eth.dst exchanged with eth.src
1343 · eth.type = 0x86dd
1345 · ip6.dst copied from ip6.src
1347 · ip6.src copied from nd.target
1349 · icmp6.type = 136 (Neighbor Advertisement)
1351 · nd.target unchanged
1353 · nd.sll = 00:00:00:00:00:00
1355 · nd.tll copied from eth.dst
1357 The ND packet has the same VLAN header, if any, as the IPv6
1359 packet it replaces.
1360 Prerequisite: nd_ns
1362 get_nd(P, A);
1364 Parameters: logical port string field P, 128-bit IPv6
1365 address field A.
1366 Looks up A in P’s mac binding table. If an entry is found,
1368 stores its Ethernet address in eth.dst, otherwise stores
1369 00:00:00:00:00:00 in eth.dst.
1370 Example: get_nd(outport, ip6.dst);
1372 put_nd(P, A, E);
1374 Parameters: logical port string field P, 128-bit IPv6
1375 address field A, 48-bit Ethernet address field E.
1376 Adds or updates the entry for IPv6 address A in logical
1378 port P’s mac binding table, setting its Ethernet address to
1379 E.
1380 Example: put_nd(inport, nd.target, nd.tll);
1382 R = lookup_nd(P, A, M);
1384 Parameters: logical port string field P, 128-bit IP address
1385 field A, 48-bit MAC address field M.
1386 Result: stored to a 1-bit subfield R.
1388 Looks up A and M in P’s mac binding table. If an entry is
1390 found, stores 1 in the 1-bit subfield R, else 0.
1391 Example: reg0[0] = lookup_nd(inport, ip6.src, eth.src);
1393 R = lookup_nd_ip(P, A);
1395 Parameters: logical port string field P, 128-bit IP address
1396 field A.
1397 Result: stored to a 1-bit subfield R.
1399 Looks up A in P’s mac binding table. If an entry is found,
1401 stores 1 in the 1-bit subfield R, else 0.
1402 Example: reg0[0] = lookup_nd_ip(inport, ip6.src);
1404 R = put_dhcp_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1406 Parameters: one or more DHCP option/value pairs, which must
1407 include an offerip option (with code 0).
1408 Result: stored to a 1-bit subfield R.
1410 Valid only in the ingress pipeline.
1412 When this action is applied to a DHCP request packet
1414 (DHCPDISCOVER or DHCPREQUEST), it changes the packet into a
1415 DHCP reply (DHCPOFFER or DHCPACK, respectively), replaces
1416 the options by those specified as parameters, and stores 1
1417 in R.
1418 When this action is applied to a non-DHCP packet or a DHCP
1420 packet that is not DHCPDISCOVER or DHCPREQUEST, it leaves
1421 the packet unchanged and stores 0 in R.
1422 The contents of the DHCP_Option table control the DHCP
1424 option names and values that this action supports.
1425 Example: reg0[0] = put_dhcp_opts(offerip = 10.0.0.2, router
1427 = 10.0.0.1, netmask = 255.255.255.0, dns_server = {8.8.8.8,
1428 7.7.7.7});
1429 R = put_dhcpv6_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1431 Parameters: one or more DHCPv6 option/value pairs.
1432 Result: stored to a 1-bit subfield R.
1434 Valid only in the ingress pipeline.
1436 When this action is applied to a DHCPv6 request packet, it
1438 changes the packet into a DHCPv6 reply, replaces the
1439 options by those specified as parameters, and stores 1 in
1440 R.
1441 When this action is applied to a non-DHCPv6 packet or an
1443 invalid DHCPv6 request packet , it leaves the packet
1444 unchanged and stores 0 in R.
1445 The contents of the DHCPv6_Options table control the DHCPv6
1447 option names and values that this action supports.
1448 Example: reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4,
1450 server_id = 00:00:00:00:10:02,
1451 dns_server={ae70::1,ae70::2});
1452 set_queue(queue_number);
1454 Parameters: Queue number queue_number, in the range 0 to
1455 61440.
1456 This is a logical equivalent of the OpenFlow set_queue
1458 action. It affects packets that egress a hypervisor through
1459 a physical interface. For nonzero queue_number, it config‐
1460 ures packet queuing to match the settings configured for
1461 the Port_Binding with options:qdisc_queue_id matching
1462 queue_number. When queue_number is zero, it resets queuing
1463 to the default strategy.
1464 Example: set_queue(10);
1466 ct_lb;
1468 ct_lb(ip[:port]...);
1469 With one or more arguments, ct_lb commits the packet to the
1470 connection tracking table and DNATs the packet’s destina‐
1471 tion IP address (and port) to the IP address or addresses
1472 (and optional ports) specified in the string. If multiple
1473 comma-separated IP addresses are specified, each is given
1474 equal weight for picking the DNAT address. Processing auto‐
1475 matically moves on to the next table, as if next; were
1476 specified, and later tables act on the packet as modified
1477 by the connection tracker. Connection tracking state is
1478 scoped by the logical port when the action is used in a
1479 flow for a logical switch, so overlapping addresses may be
1480 used. Connection tracking state is scoped by the logical
1481 topology when the action is used in a flow for a router.
1482 Without arguments, ct_lb sends the packet to the connection
1484 tracking table to NAT the packets. If the packet is part of
1485 an established connection that was previously committed to
1486 the connection tracker via ct_lb(...), it will automati‐
1487 cally get DNATed to the same IP address as the first packet
1488 in that connection.
1489 R = dns_lookup();
1491 Parameters: No parameters.
1492 Result: stored to a 1-bit subfield R.
1494 Valid only in the ingress pipeline.
1496 When this action is applied to a valid DNS request (a UDP
1498 packet typically directed to port 53), it attempts to
1499 resolve the query using the contents of the DNS table. If
1500 it is successful, it changes the packet into a DNS reply
1501 and stores 1 in R. If the action is applied to a non-DNS
1502 packet, an invalid DNS request packet, or a valid DNS
1503 request for which the DNS table does not supply an answer,
1504 it leaves the packet unchanged and stores 0 in R.
1505 Regardless of success, the action does not make any of the
1507 changes to the flow that are necessary to direct the packet
1508 back to the requester. The logical pipeline can implement
1509 this behavior with matches and actions in later tables.
1510 Example: reg0[3] = dns_lookup();
1512 Prerequisite: udp
1514 R = put_nd_ra_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1516 Parameters: The following IPv6 ND Router Advertisement
1517 option/value pairs as defined in RFC 4861.
1518 · addr_mode
1520 Mandatory parameter which specifies the address mode
1522 flag to be set in the RA flag options field. The
1523 value of this option is a string and the following
1524 values can be defined - "slaac", "dhcpv6_stateful"
1525 and "dhcpv6_stateless".
1526 · slla
1528 Mandatory parameter which specifies the link-layer
1530 address of the interface from which the Router
1531 Advertisement is sent.
1532 · mtu
1534 Optional parameter which specifies the MTU.
1536 · prefix
1538 Optional parameter which should be specified if the
1540 addr_mode is "slaac" or "dhcpv6_stateless". The
1541 value should be an IPv6 prefix which will be used
1542 for stateless IPv6 address configuration. This
1543 option can be defined multiple times.
1544 Result: stored to a 1-bit subfield R.
1546 Valid only in the ingress pipeline.
1548 When this action is applied to an IPv6 Router solicitation
1550 request packet, it changes the packet into an IPv6 Router
1551 Advertisement reply and adds the options specified in the
1552 parameters, and stores 1 in R.
1553 When this action is applied to a non-IPv6 Router solicita‐
1555 tion packet or an invalid IPv6 request packet , it leaves
1556 the packet unchanged and stores 0 in R.
1557 Example: reg0[3] = put_nd_ra_opts(addr_mode = "slaac", slla
1559 = 00:00:00:00:10:02, prefix = aef0::/64, mtu = 1450);
1560 set_meter(rate);
1562 set_meter(rate, burst);
1563 Parameters: rate limit int field rate in kbps, burst rate
1564 limits int field burst in kbps.
1565 This action sets the rate limit for a flow.
1567 Example: set_meter(100, 1000);
1569 R = check_pkt_larger(L)
1571 Parameters: packet length L to check for in bytes.
1572 Result: stored to a 1-bit subfield R.
1574 This is a logical equivalent of the OpenFlow
1576 check_pkt_larger action. If the packet is larger than the
1577 length specified in L, it stores 1 in the subfield R.
1578 Example: reg0[6] = check_pkt_larger(1000);
1580 log(key=value, ...);
1582 Causes ovn-controller to log the packet on the chassis
1583 that processes it. Packet logging currently uses the same
1584 logging mechanism as other Open vSwitch and OVN messages,
1585 which means that whether and where log messages appear
1586 depends on the local logging configuration that can be
1587 configured with ovs-appctl, etc.
1588 The log action takes zero or more of the following key-
1590 value pair arguments that control what is logged:
1591 name=string
1593 An optional name for the ACL. The string is cur‐
1594 rently limited to 64 bytes.
1595 severity=level
1597 Indicates the severity of the event. The level is
1598 one of following (from more to less serious):
1599 alert, warning, notice, info, or debug. If a
1600 severity is not provided, the default is info.
1601 verdict=value
1603 The verdict for packets matching the flow. The
1604 value must be one of allow, deny, or reject.
1605 meter=string
1607 An optional rate-limiting meter to be applied to
1608 the logs. The string should reference a name entry
1609 from the Meter table. The only meter action that
1610 is appropriate is drop.
1611 fwd_group(liveness=bool, childports=port, ...);
1613 Parameters: optional liveness, either true or false,
1614 defaulting to false; childports, a comma-delimited list
1615 of strings denoting logical ports to load balance across.
1616 Load balance traffic to one or more child ports in a log‐
1618 ical switch. ovn-controller translates the fwd_group into
1619 an OpenFlow group with one bucket for each child port. If
1620 liveness=true is specified, it also integrates the bucket
1621 selection with BFD status on the tunnel interface corre‐
1622 sponding to child port.
1623 Example: fwd_group(liveness=true, childports="p1", "p2");
1625 icmp4 { action; ... };
1627 icmp4_error { action; ... };
1628 Temporarily replaces the IPv4 packet being processed by an
1629 ICMPv4 packet and executes each nested action on the ICMPv4
1630 packet. Actions following these actions, if any, apply to
1631 the original, unmodified packet.
1632 The ICMPv4 packet that these actions operates on is ini‐
1634 tialized based on the IPv4 packet being processed, as fol‐
1635 lows. These are default values that the nested actions will
1636 probably want to change. Ethernet and IPv4 fields not
1637 listed here are not changed:
1638 · ip.proto = 1 (ICMPv4)
1640 · ip.frag = 0 (not a fragment)
1642 · ip.ttl = 255
1644 · icmp4.type = 3 (destination unreachable)
1646 · icmp4.code = 1 (host unreachable)
1648 icmp4_error action is expected to be used to generate an
1650 ICMPv4 packet in response to an error in original IP
1651 packet. When this action generates the ICMPv4 packet, it
1652 also copies the original IP datagram following the ICMPv4
1653 header as per RFC 1122: 3.2.2.
1654 Prerequisite: ip4
1656 icmp6 { action; ... };
1658 icmp6_error { action; ... };
1659 Temporarily replaces the IPv6 packet being processed by an
1660 ICMPv6 packet and executes each nested action on the ICMPv6
1661 packet. Actions following the icmp6 action, if any, apply
1662 to the original, unmodified packet.
1663 The ICMPv6 packet that this action operates on is initial‐
1665 ized based on the IPv6 packet being processed, as follows.
1666 These are default values that the nested actions will prob‐
1667 ably want to change. Ethernet and IPv6 fields not listed
1668 here are not changed:
1669 · ip.proto = 58 (ICMPv6)
1671 · ip.ttl = 255
1673 · icmp6.type = 1 (destination unreachable)
1675 · icmp6.code = 1 (administratively prohibited)
1677 icmp6_error action is expected to be used to generate an
1679 ICMPv6 packet in response to an error in original IPv6
1680 packet.
1681 Prerequisite: ip6
1683 tcp_reset;
1685 This action transforms the current TCP packet according to
1686 the following pseudocode:
1687 if (tcp.ack) {
1689 tcp.seq = tcp.ack;
1690 } else {
1691 tcp.ack = tcp.seq + length(tcp.payload);
1692 tcp.seq = 0;
1693 }
1694 tcp.flags = RST;
1695 Then, the action drops all TCP options and payload data,
1697 and updates the TCP checksum. IP ttl is set to 255.
1698 Prerequisite: tcp
1700 reject { action; ... };
1702 If the original packet is IPv4 or IPv6 TCP packet, it
1703 replaces it with IPv4 or IPv6 TCP RST packet and executes
1704 the inner actions. Otherwise it replaces it with an ICMPv4
1705 or ICMPv6 packet and executes the inner actions.
1706 The inner actions should not attempt to swap eth source
1708 with eth destination and IP source with IP destination as
1709 this action implicitly does that.
1710 trigger_event;
1712 This action is used to allow ovs-vswitchd to report CMS
1713 related events writing them in Controller_Event table. It
1714 is possible to associate a meter to a each event in order
1715 to not overload pinctrl thread under heavy load; each meter
1716 is identified though a defined naming convention. Supported
1717 events:
1718 · empty_lb_backends. This event is raised if a
1720 received packet is destined for a load balancer VIP
1721 that has no configured backend destinations. For
1722 this event, the event info includes the load bal‐
1723 ancer VIP, the load balancer UUID, and the transport
1724 protocol. Associated meter: event-elb
1725 igmp;
1727 This action sends the packet to ovn-controller for multi‐
1728 cast snooping.
1729 Prerequisite: igmp
1731 bind_vport(V, P);
1733 Parameters: logical port string field V of type virtual,
1734 logical port string field P.
1735 Binds the virtual logical port V and sets the chassis col‐
1737 umn and virtual_parent of the table Port_Binding. vir‐
1738 tual_parent is set to P.
1739 handle_svc_check(P);
1741 Parameters: logical port string field P.
1742 Handles the service monitor reply received from the VIF of
1744 the logical port P. ovn-controller periodically sends out
1745 the service monitor packets for the services configured in
1746 the Service_Monitor table and this action updates the sta‐
1747 tus of those services.
1748 Example: handle_svc_check(inport);
1750 handle_dhcpv6_reply;
1752 Handle DHCPv6 prefix delegation advertisements/replies from
1753 a IPv6 delegation server. ovn-controller will add an entry
1754 ipv6_ra_pd_list in the options table for each prefix
1755 received from the delegation server
1756 R = select(N1[=W1], N2[=W2], ...);
1758 Parameters: Integer N1, N2..., with optional weight W1, W2,
1759 ...
1760 Result: stored to a logical field or subfield R.
1762 Select from a list of integers N1, N2..., each within the
1764 range 0 ~ 65535, and store the selected one in the field R.
1765 There must be 2 or more integers listed, each with an
1766 optional weight, which is an integer within the range 1 ~
1767 65535. If weight is not specified, it defaults to 100. The
1768 selection method is based on the 5-tuple hash of packet
1769 header.
1770 Processing automatically moves on to the next table, as if
1772 next; were specified. The select action must be put as the
1773 last action of the logical flow when there are multiple
1774 actions (actions put after select will not take effect).
1775 Example: reg8[16..31] = select(1=20, 2=30, 3=50);
1777 handle_dhcpv6_reply;
1779 This action is used to parse DHCPv6 replies from IPv6 Dele‐
1780 gation Router and managed IPv6 Prefix delegation state
1781 machine
1782 R = chk_lb_hairpin();
1784 This action checks if the packet under consideration was
1785 destined to a load balancer VIP and it is hairpinned, i.e.,
1786 after load balancing the destination IP matches the source
1787 IP. If it is so, then the 1-bit destination register R is
1788 set to 1.
1789 R = chk_lb_hairpin_reply();
1791 This action checks if the packet under consideration is
1792 from one of the backend IP of a load balancer VIP and the
1793 destination IP is the load balancer VIP. If it is so, then
1794 the 1-bit destination register R is set to 1.
1795 R = ct_snat_to_vip;
1797 This action sends the packet through the SNAT zone to
1798 change the source IP address of the packet to the load bal‐
1799 ancer VIP if the original destination IP was load balancer
1800 VIP and commits the connection. This action applies suc‐
1801 cessfully only for the hairpinned traffic i.e if the action
1802 chk_lb_hairpin returned success. This action doesn’t take
1803 any arguments and it determines the SNAT IP internally. The
1804 packet is not automatically sent to the next table. The
1805 caller has to execute the next; action explicitly after
1806 this action to advance the packet to the next stage.
1807 external_ids : stage-name: optional string
1809 Human-readable name for this flow’s stage in the pipeline.
1810 external_ids : stage-hint: optional string, containing an uuid
1812 UUID of a OVN_Northbound record that caused this logical flow to
1813 be created. Currently used only for attribute of logical flows
1814 to northbound ACL records.
1815 external_ids : source: optional string
1817 Source file and line number of the code that added this flow to
1818 the pipeline.
1819 Common Columns:
1821 The overall purpose of these columns is described under Common Columns
1823 at the beginning of this document.
1824 external_ids: map of string-string pairs
1826
1828 Each row in this table represents a group of logical datapaths refer‐
1829 enced by the logical_dp_group column in the Logical_Flow table.
1830 Summary:
1832 datapaths set of weak reference to Datapath_Bind‐
1833 ings
1834 Details:
1836 datapaths: set of weak reference to Datapath_Bindings
1837 List of Datapath_Binding entries.
1838
1840 The rows in this table define multicast groups of logical ports. Multi‐
1841 cast groups allow a single packet transmitted over a tunnel to a hyper‐
1842 visor to be delivered to multiple VMs on that hypervisor, which uses
1843 bandwidth more efficiently.
1844 Each row in this table defines a logical multicast group numbered tun‐
1846 nel_key within datapath, whose logical ports are listed in the ports
1847 column.
1848 Summary:
1850 datapath Datapath_Binding
1851 tunnel_key integer, in range 32,768 to 65,535
1852 name string
1853 ports set of 1 or more weak reference to
1854 Port_Bindings
1855 Details:
1857 datapath: Datapath_Binding
1858 The logical datapath in which the multicast group resides.
1859 tunnel_key: integer, in range 32,768 to 65,535
1861 The value used to designate this logical egress port in tunnel
1862 encapsulations. An index forces the key to be unique within the
1863 datapath. The unusual range ensures that multicast group IDs do
1864 not overlap with logical port IDs.
1865 name: string
1867 The logical multicast group’s name. An index forces the name to
1868 be unique within the datapath. Logical flows in the ingress
1869 pipeline may output to the group just as for individual logical
1870 ports, by assigning the group’s name to outport and executing an
1871 output action.
1872 Multicast group names and logical port names share a single
1874 namespace and thus should not overlap (but the database schema
1875 cannot enforce this). To try to avoid conflicts, ovn-northd uses
1876 names that begin with _MC_.
1877 ports: set of 1 or more weak reference to Port_Bindings
1879 The logical ports included in the multicast group. All of these
1880 ports must be in the datapath logical datapath (but the database
1881 schema cannot enforce this).
1882
1884 Each row in this table represents a meter that can be used for QoS or
1885 rate-limiting.
1886 Summary:
1888 name string (must be unique within table)
1889 unit string, either kbps or pktps
1890 bands set of 1 or more Meter_Bands
1891 Details:
1893 name: string (must be unique within table)
1894 A name for this meter.
1895 Names that begin with "__" (two underscores) are reserved for
1897 OVN internal use and should not be added manually.
1898 unit: string, either kbps or pktps
1900 The unit for rate and burst_rate parameters in the bands entry.
1901 kbps specifies kilobits per second, and pktps specifies packets
1902 per second.
1903 bands: set of 1 or more Meter_Bands
1905 The bands associated with this meter. Each band specifies a rate
1906 above which the band is to take the action action. If multiple
1907 bands’ rates are exceeded, then the band with the highest rate
1908 among the exceeded bands is selected.
1909
1911 Each row in this table represents a meter band which specifies the rate
1912 above which the configured action should be applied. These bands are
1913 referenced by the bands column in the Meter table.
1914 Summary:
1916 action string, must be drop
1917 rate integer, in range 1 to 4,294,967,295
1918 burst_size integer, in range 0 to 4,294,967,295
1919 Details:
1921 action: string, must be drop
1922 The action to execute when this band matches. The only supported
1923 action is drop.
1924 rate: integer, in range 1 to 4,294,967,295
1926 The rate limit for this band, in kilobits per second or bits per
1927 second, depending on whether the parent Meter entry’s unit col‐
1928 umn specified kbps or pktps.
1929 burst_size: integer, in range 0 to 4,294,967,295
1931 The maximum burst allowed for the band in kilobits or packets,
1932 depending on whether kbps or pktps was selected in the parent
1933 Meter entry’s unit column. If the size is zero, the switch is
1934 free to select some reasonable value depending on its configura‐
1935 tion.
1936
1938 Each row in this table represents a logical datapath, which implements
1939 a logical pipeline among the ports in the Port_Binding table associated
1940 with it. In practice, the pipeline in a given logical datapath imple‐
1941 ments either a logical switch or a logical router.
1942 The main purpose of a row in this table is provide a physical binding
1944 for a logical datapath. A logical datapath does not have a physical
1945 location, so its physical binding information is limited: just tun‐
1946 nel_key. The rest of the data in this table does not affect packet for‐
1947 warding.
1948 Summary:
1950 tunnel_key integer, in range 1 to 16,777,215 (must
1951 be unique within table)
1952 load_balancers set of weak reference to Load_Balancers
1953 OVN_Northbound Relationship:
1954 external_ids : logical-switch
1955 optional string, containing an uuid
1956 external_ids : logical-router
1957 optional string, containing an uuid
1958 external_ids : interconn-ts
1959 optional string
1960 Naming:
1961 external_ids : name optional string
1962 external_ids : name2 optional string
1963 Common Columns:
1964 external_ids map of string-string pairs
1965 Details:
1967 tunnel_key: integer, in range 1 to 16,777,215 (must be unique within
1968 table)
1969 The tunnel key value to which the logical datapath is bound. The
1970 Tunnel Encapsulation section in ovn-architecture(7) describes
1971 how tunnel keys are constructed for each supported encapsula‐
1972 tion.
1973 load_balancers: set of weak reference to Load_Balancers
1975 Load balancers associated with the datapath.
1976 OVN_Northbound Relationship:
1978 Each row in Datapath_Binding is associated with some logical datapath.
1980 ovn-northd uses these keys to track the association of a logical data‐
1981 path with concepts in the OVN_Northbound database.
1982 external_ids : logical-switch: optional string, containing an uuid
1984 For a logical datapath that represents a logical switch,
1985 ovn-northd stores in this key the UUID of the corresponding Log‐
1986 ical_Switch row in the OVN_Northbound database.
1987 external_ids : logical-router: optional string, containing an uuid
1989 For a logical datapath that represents a logical router,
1990 ovn-northd stores in this key the UUID of the corresponding Log‐
1991 ical_Router row in the OVN_Northbound database.
1992 external_ids : interconn-ts: optional string
1994 For a logical datapath that represents a logical switch that
1995 represents a transit switch for interconnection, ovn-northd
1996 stores in this key the value of the same interconn-ts key of the
1997 external_ids column of the corresponding Logical_Switch row in
1998 the OVN_Northbound database.
1999 Naming:
2001 ovn-northd copies these from the name fields in the OVN_Northbound
2003 database, either from name and external_ids:neutron:router_name in the
2004 Logical_Router table or from name and external_ids:neutron:network_name
2005 in the Logical_Switch table.
2006 external_ids : name: optional string
2008 A name for the logical datapath.
2009 external_ids : name2: optional string
2011 Another name for the logical datapath.
2012 Common Columns:
2014 The overall purpose of these columns is described under Common Columns
2016 at the beginning of this document.
2017 external_ids: map of string-string pairs
2019
2021 Each row in this table binds a logical port to a realization. For most
2022 logical ports, this means binding to some physical location, for exam‐
2023 ple by binding a logical port to a VIF that belongs to a VM running on
2024 a particular hypervisor. Other logical ports, such as logical patch
2025 ports, can be realized without a specific physical location, but their
2026 bindings are still expressed through rows in this table.
2027 For every Logical_Switch_Port record in OVN_Northbound database,
2029 ovn-northd creates a record in this table. ovn-northd populates and
2030 maintains every column except the chassis and virtual_parent columns,
2031 which it leaves empty in new records.
2032 ovn-controller/ovn-controller-vtep populates the chassis column for the
2034 records that identify the logical ports that are located on its hyper‐
2035 visor/gateway, which ovn-controller/ovn-controller-vtep in turn finds
2036 out by monitoring the local hypervisor’s Open_vSwitch database, which
2037 identifies logical ports via the conventions described in Integra‐
2038 tionGuide.rst. (The exceptions are for Port_Binding records with type
2039 of l3gateway, whose locations are identified by ovn-northd via the
2040 options:l3gateway-chassis column in this table. ovn-controller is still
2041 responsible to populate the chassis column.)
2042 ovn-controller also populates the virtual_parent column of records
2044 whose type is virtual.
2045 When a chassis shuts down gracefully, it should clean up the chassis
2047 column that it previously had populated. (This is not critical because
2048 resources hosted on the chassis are equally unreachable regardless of
2049 whether their rows are present.) To handle the case where a VM is shut
2050 down abruptly on one chassis, then brought up again on a different one,
2051 ovn-controller/ovn-controller-vtep must overwrite the chassis column
2052 with new information.
2053 Summary:
2055 Core Features:
2056 datapath Datapath_Binding
2057 logical_port string (must be unique within table)
2058 encap optional weak reference to Encap
2059 chassis optional weak reference to Chassis
2060 gateway_chassis set of Gateway_Chassises
2061 ha_chassis_group optional HA_Chassis_Group
2062 up optional boolean
2063 tunnel_key integer, in range 1 to 32,767
2064 mac set of strings
2065 type string
2066 Patch Options:
2067 options : peer optional string
2068 nat_addresses set of strings
2069 L3 Gateway Options:
2070 options : peer optional string
2071 options : l3gateway-chassis
2072 optional string
2073 options : nat-addresses optional string
2074 nat_addresses set of strings
2075 Localnet Options:
2076 options : network_name optional string
2077 tag optional integer, in range 1 to 4,095
2078 L2 Gateway Options:
2079 options : network_name optional string
2080 options : l2gateway-chassis
2081 optional string
2082 tag optional integer, in range 1 to 4,095
2083 VTEP Options:
2084 options : vtep-physical-switch
2085 optional string
2086 options : vtep-logical-switch
2087 optional string
2088 VMI (or VIF) Options:
2089 options : requested-chassis
2090 optional string
2091 options : qos_max_rate optional string
2092 options : qos_burst optional string
2093 options : qdisc_queue_id optional string, containing an integer,
2094 in range 1 to 61,440
2095 Chassis Redirect Options:
2096 options : distributed-port optional string
2097 Nested Containers:
2098 parent_port optional string
2099 tag optional integer, in range 1 to 4,095
2100 Virtual ports:
2101 virtual_parent optional string
2102 Naming:
2103 external_ids : name optional string
2104 Common Columns:
2105 external_ids map of string-string pairs
2106 Details:
2108 Core Features:
2109 datapath: Datapath_Binding
2111 The logical datapath to which the logical port belongs.
2112 logical_port: string (must be unique within table)
2114 A logical port. For a logical switch port, this is taken from
2115 name in the OVN_Northbound database’s Logical_Switch_Port table.
2116 For a logical router port, this is taken from name in the
2117 OVN_Northbound database’s Logical_Router_port table. (This means
2118 that logical switch ports and router port names must share names
2119 in an OVN deployment.) OVN does not prescribe a particular for‐
2120 mat for the logical port ID.
2121 encap: optional weak reference to Encap
2123 Points to supported encapsulation configurations to transmit
2124 logical dataplane packets to this chassis. Each entry is a Encap
2125 record that describes the configuration.
2126 chassis: optional weak reference to Chassis
2128 The meaning of this column depends on the value of the type col‐
2129 umn. This is the meaning for each type
2130 (empty string)
2132 The physical location of the logical port. To success‐
2133 fully identify a chassis, this column must be a Chassis
2134 record. This is populated by ovn-controller.
2135 vtep The physical location of the hardware_vtep gateway. To
2137 successfully identify a chassis, this column must be a
2138 Chassis record. This is populated by ovn-controller-vtep.
2139 localnet
2141 Always empty. A localnet port is realized on every chas‐
2142 sis that has connectivity to the corresponding physical
2143 network.
2144 localport
2146 Always empty. A localport port is present on every chas‐
2147 sis.
2148 l3gateway
2150 The physical location of the L3 gateway. To successfully
2151 identify a chassis, this column must be a Chassis record.
2152 This is populated by ovn-controller based on the value of
2153 the options:l3gateway-chassis column in this table.
2154 l2gateway
2156 The physical location of this L2 gateway. To successfully
2157 identify a chassis, this column must be a Chassis record.
2158 This is populated by ovn-controller based on the value of
2159 the options:l2gateway-chassis column in this table.
2160 gateway_chassis: set of Gateway_Chassises
2162 A list of Gateway_Chassis.
2163 This should only be populated for ports with type set to chas‐
2165 sisredirect. This column defines the list of chassis used as
2166 gateways where traffic will be redirected through.
2167 ha_chassis_group: optional HA_Chassis_Group
2169 This should only be populated for ports with type set to chas‐
2170 sisredirect. This column defines the HA chassis group with a
2171 list of HA chassis used as gateways where traffic will be redi‐
2172 rected through.
2173 up: optional boolean
2175 This is set to true whenever all OVS flows required by this
2176 Port_Binding have been installed. This is populated by ovn-con‐
2177 troller.
2178 tunnel_key: integer, in range 1 to 32,767
2180 A number that represents the logical port in the key (e.g. STT
2181 key or Geneve TLV) field carried within tunnel protocol packets.
2182 The tunnel ID must be unique within the scope of a logical data‐
2184 path.
2185 mac: set of strings
2187 The Ethernet address or addresses used as a source address on
2188 the logical port, each in the form xx:xx:xx:xx:xx:xx. The string
2189 unknown is also allowed to indicate that the logical port has an
2190 unknown set of (additional) source addresses.
2191 A VM interface would ordinarily have a single Ethernet address.
2193 A gateway port might initially only have unknown, and then add
2194 MAC addresses to the set as it learns new source addresses.
2195 type: string
2197 A type for this logical port. Logical ports can be used to model
2198 other types of connectivity into an OVN logical switch. The fol‐
2199 lowing types are defined:
2200 (empty string)
2202 VM (or VIF) interface.
2203 patch One of a pair of logical ports that act as if connected
2205 by a patch cable. Useful for connecting two logical data‐
2206 paths, e.g. to connect a logical router to a logical
2207 switch or to another logical router.
2208 l3gateway
2210 One of a pair of logical ports that act as if connected
2211 by a patch cable across multiple chassis. Useful for con‐
2212 necting a logical switch with a Gateway router (which is
2213 only resident on a particular chassis).
2214 localnet
2216 A connection to a locally accessible network from
2217 ovn-controller instances that have a corresponding bridge
2218 mapping. A logical switch can have multiple localnet
2219 ports attached. This type is used to model direct connec‐
2220 tivity to existing networks. In this case, each chassis
2221 should have a mapping for one of the physical networks
2222 only. Note: nothing said above implies that a chassis
2223 cannot be plugged to multiple physical networks as long
2224 as they belong to different switches.
2225 localport
2227 A connection to a local VIF. Traffic that arrives on a
2228 localport is never forwarded over a tunnel to another
2229 chassis. These ports are present on every chassis and
2230 have the same address in all of them. This is used to
2231 model connectivity to local services that run on every
2232 hypervisor.
2233 l2gateway
2235 An L2 connection to a physical network. The chassis this
2236 Port_Binding is bound to will serve as an L2 gateway to
2237 the network named by options:network_name.
2238 vtep A port to a logical switch on a VTEP gateway chassis. In
2240 order to get this port correctly recognized by the OVN
2241 controller, the options:vtep-physical-switch and
2242 options:vtep-logical-switch must also be defined.
2243 chassisredirect
2245 A logical port that represents a particular instance,
2246 bound to a specific chassis, of an otherwise distributed
2247 parent port (e.g. of type patch). A chassisredirect port
2248 should never be used as an inport. When an ingress pipe‐
2249 line sets the outport, it may set the value to a logical
2250 port of type chassisredirect. This will cause the packet
2251 to be directed to a specific chassis to carry out the
2252 egress pipeline. At the beginning of the egress pipeline,
2253 the outport will be reset to the value of the distributed
2254 port.
2255 virtual
2257 Represents a logical port with an virtual ip. This vir‐
2258 tual ip can be configured on a logical port (which is
2259 refered as virtual parent).
2260 Patch Options:
2262 These options apply to logical ports with type of patch.
2264 options : peer: optional string
2266 The logical_port in the Port_Binding record for the other side
2267 of the patch. The named logical_port must specify this logi‐
2268 cal_port in its own peer option. That is, the two patch logical
2269 ports must have reversed logical_port and peer values.
2270 nat_addresses: set of strings
2272 MAC address followed by a list of SNAT and DNAT external IP
2273 addresses, followed by is_chassis_resident("lport"), where lport
2274 is the name of a logical port on the same chassis where the cor‐
2275 responding NAT rules are applied. This is used to send gratu‐
2276 itous ARPs for SNAT and DNAT external IP addresses via localnet,
2277 from the chassis where lport resides. Example: 80:fa:5b:06:72:b7
2278 158.36.44.22 158.36.44.24 is_chassis_resident("foo1"). This
2279 would result in generation of gratuitous ARPs for IP addresses
2280 158.36.44.22 and 158.36.44.24 with a MAC address of
2281 80:fa:5b:06:72:b7 from the chassis where the logical port "foo1"
2282 resides.
2283 L3 Gateway Options:
2285 These options apply to logical ports with type of l3gateway.
2287 options : peer: optional string
2289 The logical_port in the Port_Binding record for the other side
2290 of the ’l3gateway’ port. The named logical_port must specify
2291 this logical_port in its own peer option. That is, the two
2292 ’l3gateway’ logical ports must have reversed logical_port and
2293 peer values.
2294 options : l3gateway-chassis: optional string
2296 The chassis in which the port resides.
2297 options : nat-addresses: optional string
2299 MAC address of the l3gateway port followed by a list of SNAT and
2300 DNAT external IP addresses. This is used to send gratuitous ARPs
2301 for SNAT and DNAT external IP addresses via localnet. Example:
2302 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
2303 in generation of gratuitous ARPs for IP addresses 158.36.44.22
2304 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
2305 is used in OVS versions prior to 2.8.
2306 nat_addresses: set of strings
2308 MAC address of the l3gateway port followed by a list of SNAT and
2309 DNAT external IP addresses. This is used to send gratuitous ARPs
2310 for SNAT and DNAT external IP addresses via localnet. Example:
2311 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
2312 in generation of gratuitous ARPs for IP addresses 158.36.44.22
2313 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
2314 is used in OVS version 2.8 and later versions.
2315 Localnet Options:
2317 These options apply to logical ports with type of localnet.
2319 options : network_name: optional string
2321 Required. ovn-controller uses the configuration entry
2322 ovn-bridge-mappings to determine how to connect to this network.
2323 ovn-bridge-mappings is a list of network names mapped to a local
2324 OVS bridge that provides access to that network. An example of
2325 configuring ovn-bridge-mappings would be: .IP
2326 $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
2327 When a logical switch has a localnet port attached, every chas‐
2329 sis that may have a local vif attached to that logical switch
2330 must have a bridge mapping configured to reach that localnet.
2331 Traffic that arrives on a localnet port is never forwarded over
2332 a tunnel to another chassis. If there are multiple localnet
2333 ports in a logical switch, each chassis should only have a sin‐
2334 gle bridge mapping for one of the physical networks. Note: In
2335 case of multiple localnet ports, to provide interconnectivity
2336 between all VIFs located on different chassis with different
2337 fabric connectivity, the fabric should implement some form of
2338 routing between the segments.
2339 tag: optional integer, in range 1 to 4,095
2341 If set, indicates that the port represents a connection to a
2342 specific VLAN on a locally accessible network. The VLAN ID is
2343 used to match incoming traffic and is also added to outgoing
2344 traffic.
2345 L2 Gateway Options:
2347 These options apply to logical ports with type of l2gateway.
2349 options : network_name: optional string
2351 Required. ovn-controller uses the configuration entry
2352 ovn-bridge-mappings to determine how to connect to this network.
2353 ovn-bridge-mappings is a list of network names mapped to a local
2354 OVS bridge that provides access to that network. An example of
2355 configuring ovn-bridge-mappings would be: .IP
2356 $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
2357 When a logical switch has a l2gateway port attached, the chassis
2359 that the l2gateway port is bound to must have a bridge mapping
2360 configured to reach the network identified by network_name.
2361 options : l2gateway-chassis: optional string
2363 Required. The chassis in which the port resides.
2364 tag: optional integer, in range 1 to 4,095
2366 If set, indicates that the gateway is connected to a specific
2367 VLAN on the physical network. The VLAN ID is used to match
2368 incoming traffic and is also added to outgoing traffic.
2369 VTEP Options:
2371 These options apply to logical ports with type of vtep.
2373 options : vtep-physical-switch: optional string
2375 Required. The name of the VTEP gateway.
2376 options : vtep-logical-switch: optional string
2378 Required. A logical switch name connected by the VTEP gateway.
2379 Must be set when type is vtep.
2380 VMI (or VIF) Options:
2382 These options apply to logical ports with type having (empty string)
2384 options : requested-chassis: optional string
2386 If set, identifies a specific chassis (by name or hostname) that
2387 is allowed to bind this port. Using this option will prevent
2388 thrashing between two chassis trying to bind the same port dur‐
2389 ing a live migration. It can also prevent similar thrashing due
2390 to a mis-configuration, if a port is accidentally created on
2391 more than one chassis.
2392 options : qos_max_rate: optional string
2394 If set, indicates the maximum rate for data sent from this
2395 interface, in bit/s. The traffic will be shaped according to
2396 this limit.
2397 options : qos_burst: optional string
2399 If set, indicates the maximum burst size for data sent from this
2400 interface, in bits.
2401 options : qdisc_queue_id: optional string, containing an integer, in
2403 range 1 to 61,440
2404 Indicates the queue number on the physical device. This is same
2405 as the queue_id used in OpenFlow in struct ofp_action_enqueue.
2406 Chassis Redirect Options:
2408 These options apply to logical ports with type of chassisredirect.
2410 options : distributed-port: optional string
2412 The name of the distributed port for which this chassisredirect
2413 port represents a particular instance.
2414 Nested Containers:
2416 These columns support containers nested within a VM. Specifically, they
2418 are used when type is empty and logical_port identifies the interface
2419 of a container spawned inside a VM. They are empty for containers or
2420 VMs that run directly on a hypervisor.
2421 parent_port: optional string
2423 This is taken from parent_name in the OVN_Northbound database’s
2424 Logical_Switch_Port table.
2425 tag: optional integer, in range 1 to 4,095
2427 Identifies the VLAN tag in the network traffic associated with
2428 that container’s network interface.
2429 This column is used for a different purpose when type is local‐
2431 net (see Localnet Options, above) or l2gateway (see L2 Gateway
2432 Options, above).
2433 Virtual ports:
2435 virtual_parent: optional string
2437 This column is set by ovn-controller with one of the value from
2438 the options:virtual-parents in the OVN_Northbound database’s
2439 Logical_Switch_Port table when the OVN action bind_vport is exe‐
2440 cuted. ovn-controller also sets the chassis column when it exe‐
2441 cutes this action with its chassis id.
2442 ovn-controller sets this column only if the type is "virtual".
2444 Naming:
2446 external_ids : name: optional string
2448 For a logical switch port, ovn-northd copies this from exter‐
2449 nal_ids:neutron:port_name in the Logical_Switch_Port table in
2450 the OVN_Northbound database, if it is a nonempty string.
2451 For a logical switch port, ovn-northd does not currently set
2453 this key.
2454 Common Columns:
2456 external_ids: map of string-string pairs
2458 See External IDs at the beginning of this document.
2459 The ovn-northd program populates this column with all entries
2461 into the external_ids column of the Logical_Switch_Port table of
2462 the OVN_Northbound database.
2463
2465 Each row in this table specifies a binding from an IP address to an
2466 Ethernet address that has been discovered through ARP (for IPv4) or
2467 neighbor discovery (for IPv6). This table is primarily used to discover
2468 bindings on physical networks, because IP-to-MAC bindings for virtual
2469 machines are usually populated statically into the Port_Binding table.
2470 This table expresses a functional relationship: MAC_Binding(logi‐
2472 cal_port, ip) = mac.
2473 In outline, the lifetime of a logical router’s MAC binding looks like
2475 this:
2476 1. On hypervisor 1, a logical router determines that a packet
2478 should be forwarded to IP address A on one of its router
2479 ports. It uses its logical flow table to determine that A
2480 lacks a static IP-to-MAC binding and the get_arp action to
2481 determine that it lacks a dynamic IP-to-MAC binding.
2482 2. Using an OVN logical arp action, the logical router gener‐
2484 ates and sends a broadcast ARP request to the router port.
2485 It drops the IP packet.
2486 3. The logical switch attached to the router port delivers the
2488 ARP request to all of its ports. (It might make sense to
2489 deliver it only to ports that have no static IP-to-MAC bind‐
2490 ings, but this could also be surprising behavior.)
2491 4. A host or VM on hypervisor 2 (which might be the same as
2493 hypervisor 1) attached to the logical switch owns the IP
2494 address in question. It composes an ARP reply and unicasts
2495 it to the logical router port’s Ethernet address.
2496 5. The logical switch delivers the ARP reply to the logical
2498 router port.
2499 6. The logical router flow table executes a put_arp action. To
2501 record the IP-to-MAC binding, ovn-controller adds a row to
2502 the MAC_Binding table.
2503 7. On hypervisor 1, ovn-controller receives the updated
2505 MAC_Binding table from the OVN southbound database. The next
2506 packet destined to A through the logical router is sent
2507 directly to the bound Ethernet address.
2508 Summary:
2510 logical_port string
2511 ip string
2512 mac string
2513 datapath Datapath_Binding
2514 Details:
2516 logical_port: string
2517 The logical port on which the binding was discovered.
2518 ip: string
2520 The bound IP address.
2521 mac: string
2523 The Ethernet address to which the IP is bound.
2524 datapath: Datapath_Binding
2526 The logical datapath to which the logical port belongs.
2527
2529 Each row in this table stores the DHCP Options supported by native OVN
2530 DHCP. ovn-northd populates this table with the supported DHCP options.
2531 ovn-controller looks up this table to get the DHCP codes of the DHCP
2532 options defined in the "put_dhcp_opts" action. Please refer to the RFC
2533 2132 "https://tools.ietf.org/html/rfc2132" for the possible list of
2534 DHCP options that can be defined here.
2535 Summary:
2537 name string
2538 code integer, in range 0 to 254
2539 type string, one of bool, domains, host_id,
2540 ipv4, static_routes, str, uint16, uint32,
2541 or uint8
2542 Details:
2544 name: string
2545 Name of the DHCP option.
2546 Example. name="router"
2548 code: integer, in range 0 to 254
2550 DHCP option code for the DHCP option as defined in the RFC 2132.
2551 Example. code=3
2553 type: string, one of bool, domains, host_id, ipv4, static_routes, str,
2555 uint16, uint32, or uint8
2556 Data type of the DHCP option code.
2557 value: bool
2559 This indicates that the value of the DHCP option is a
2560 bool.
2561 Example. "name=ip_forward_enable", "code=19",
2563 "type=bool".
2564 put_dhcp_opts(..., ip_forward_enable = 1,...)
2566 value: uint8
2568 This indicates that the value of the DHCP option is an
2569 unsigned int8 (8 bits)
2570 Example. "name=default_ttl", "code=23", "type=uint8".
2572 put_dhcp_opts(..., default_ttl = 50,...)
2574 value: uint16
2576 This indicates that the value of the DHCP option is an
2577 unsigned int16 (16 bits).
2578 Example. "name=mtu", "code=26", "type=uint16".
2580 put_dhcp_opts(..., mtu = 1450,...)
2582 value: uint32
2584 This indicates that the value of the DHCP option is an
2585 unsigned int32 (32 bits).
2586 Example. "name=lease_time", "code=51", "type=uint32".
2588 put_dhcp_opts(..., lease_time = 86400,...)
2590 value: ipv4
2592 This indicates that the value of the DHCP option is an
2593 IPv4 address or addresses.
2594 Example. "name=router", "code=3", "type=ipv4".
2596 put_dhcp_opts(..., router = 10.0.0.1,...)
2598 Example. "name=dns_server", "code=6", "type=ipv4".
2600 put_dhcp_opts(..., dns_server = {8.8.8.8 7.7.7.7},...)
2602 value: static_routes
2604 This indicates that the value of the DHCP option contains
2605 a pair of IPv4 route and next hop addresses.
2606 Example. "name=classless_static_route", "code=121",
2608 "type=static_routes".
2609 put_dhcp_opts(..., classless_static_route =
2611 {30.0.0.0/24,10.0.0.4,0.0.0.0/0,10.0.0.1}...)
2612 value: str
2614 This indicates that the value of the DHCP option is a
2615 string.
2616 Example. "name=host_name", "code=12", "type=str".
2618 value: host_id
2620 This indicates that the value of the DHCP option is a
2621 host_id. It can either be a host_name or an IP address.
2622 Example. "name=tftp_server", "code=66", "type=host_id".
2624 value: domains
2626 This indicates that the value of the DHCP option is a
2627 domain name or a comma separated list of domain names.
2628 Example. "name=domain_search_list", "code=119",
2630 "type=domains".
2631
2633 Each row in this table stores the DHCPv6 Options supported by native
2634 OVN DHCPv6. ovn-northd populates this table with the supported DHCPv6
2635 options. ovn-controller looks up this table to get the DHCPv6 codes of
2636 the DHCPv6 options defined in the put_dhcpv6_opts action. Please refer
2637 to RFC 3315 and RFC 3646 for the list of DHCPv6 options that can be
2638 defined here.
2639 Summary:
2641 name string
2642 code integer, in range 0 to 254
2643 type string, one of ipv6, mac, or str
2644 Details:
2646 name: string
2647 Name of the DHCPv6 option.
2648 Example. name="ia_addr"
2650 code: integer, in range 0 to 254
2652 DHCPv6 option code for the DHCPv6 option as defined in the
2653 appropriate RFC.
2654 Example. code=3
2656 type: string, one of ipv6, mac, or str
2658 Data type of the DHCPv6 option code.
2659 value: ipv6
2661 This indicates that the value of the DHCPv6 option is an
2662 IPv6 address(es).
2663 Example. "name=ia_addr", "code=5", "type=ipv6".
2665 put_dhcpv6_opts(..., ia_addr = ae70::4,...)
2667 value: str
2669 This indicates that the value of the DHCPv6 option is a
2670 string.
2671 Example. "name=domain_search", "code=24", "type=str".
2673 put_dhcpv6_opts(..., domain_search = ovn.domain,...)
2675 value: mac
2677 This indicates that the value of the DHCPv6 option is a
2678 MAC address.
2679 Example. "name=server_id", "code=2", "type=mac".
2681 put_dhcpv6_opts(..., server_id = 01:02:03:04L05:06,...)
2683
2685 Configuration for a database connection to an Open vSwitch database
2686 (OVSDB) client.
2687 This table primarily configures the Open vSwitch database server
2689 (ovsdb-server).
2690 The Open vSwitch database server can initiate and maintain active con‐
2692 nections to remote clients. It can also listen for database connec‐
2693 tions.
2694 Summary:
2696 Core Features:
2697 target string (must be unique within table)
2698 read_only boolean
2699 role string
2700 Client Failure Detection and Handling:
2701 max_backoff optional integer, at least 1,000
2702 inactivity_probe optional integer
2703 Status:
2704 is_connected boolean
2705 status : last_error optional string
2706 status : state optional string, one of ACTIVE, BACKOFF,
2707 CONNECTING, IDLE, or VOID
2708 status : sec_since_connect optional string, containing an integer,
2709 at least 0
2710 status : sec_since_disconnect
2711 optional string, containing an integer,
2712 at least 0
2713 status : locks_held optional string
2714 status : locks_waiting optional string
2715 status : locks_lost optional string
2716 status : n_connections optional string, containing an integer,
2717 at least 2
2718 status : bound_port optional string, containing an integer
2719 Common Columns:
2720 external_ids map of string-string pairs
2721 other_config map of string-string pairs
2722 Details:
2724 Core Features:
2725 target: string (must be unique within table)
2727 Connection methods for clients.
2728 The following connection methods are currently supported:
2730 ssl:host[:port]
2732 The specified SSL port on the given host, which can
2733 either be a DNS name (if built with unbound library) or
2734 an IP address. A valid SSL configuration must be provided
2735 when this form is used, this configuration can be speci‐
2736 fied via command-line options or the SSL table.
2737 If port is not specified, it defaults to 6640.
2739 SSL support is an optional feature that is not always
2741 built as part of Open vSwitch.
2742 tcp:host[:port]
2744 The specified TCP port on the given host, which can
2745 either be a DNS name (if built with unbound library) or
2746 an IP address (IPv4 or IPv6). If host is an IPv6 address,
2747 wrap it in square brackets, e.g. tcp:[::1]:6640.
2748 If port is not specified, it defaults to 6640.
2750 pssl:[port][:host]
2752 Listens for SSL connections on the specified TCP port.
2753 Specify 0 for port to have the kernel automatically
2754 choose an available port. If host, which can either be a
2755 DNS name (if built with unbound library) or an IP
2756 address, is specified, then connections are restricted to
2757 the resolved or specified local IP address (either IPv4
2758 or IPv6 address). If host is an IPv6 address, wrap in
2759 square brackets, e.g. pssl:6640:[::1]. If host is not
2760 specified then it listens only on IPv4 (but not IPv6)
2761 addresses. A valid SSL configuration must be provided
2762 when this form is used, this can be specified either via
2763 command-line options or the SSL table.
2764 If port is not specified, it defaults to 6640.
2766 SSL support is an optional feature that is not always
2768 built as part of Open vSwitch.
2769 ptcp:[port][:host]
2771 Listens for connections on the specified TCP port. Spec‐
2772 ify 0 for port to have the kernel automatically choose an
2773 available port. If host, which can either be a DNS name
2774 (if built with unbound library) or an IP address, is
2775 specified, then connections are restricted to the
2776 resolved or specified local IP address (either IPv4 or
2777 IPv6 address). If host is an IPv6 address, wrap it in
2778 square brackets, e.g. ptcp:6640:[::1]. If host is not
2779 specified then it listens only on IPv4 addresses.
2780 If port is not specified, it defaults to 6640.
2782 When multiple clients are configured, the target values must be
2784 unique. Duplicate target values yield unspecified results.
2785 read_only: boolean
2787 true to restrict these connections to read-only transactions,
2788 false to allow them to modify the database.
2789 role: string
2791 String containing role name for this connection entry.
2792 Client Failure Detection and Handling:
2794 max_backoff: optional integer, at least 1,000
2796 Maximum number of milliseconds to wait between connection
2797 attempts. Default is implementation-specific.
2798 inactivity_probe: optional integer
2800 Maximum number of milliseconds of idle time on connection to the
2801 client before sending an inactivity probe message. If Open
2802 vSwitch does not communicate with the client for the specified
2803 number of seconds, it will send a probe. If a response is not
2804 received for the same additional amount of time, Open vSwitch
2805 assumes the connection has been broken and attempts to recon‐
2806 nect. Default is implementation-specific. A value of 0 disables
2807 inactivity probes.
2808 Status:
2810 Key-value pair of is_connected is always updated. Other key-value pairs
2812 in the status columns may be updated depends on the target type.
2813 When target specifies a connection method that listens for inbound con‐
2815 nections (e.g. ptcp: or punix:), both n_connections and is_connected
2816 may also be updated while the remaining key-value pairs are omitted.
2817 On the other hand, when target specifies an outbound connection, all
2819 key-value pairs may be updated, except the above-mentioned two key-
2820 value pairs associated with inbound connection targets. They are omit‐
2821 ted.
2822 is_connected: boolean
2824 true if currently connected to this client, false otherwise.
2825 status : last_error: optional string
2827 A human-readable description of the last error on the connection
2828 to the manager; i.e. strerror(errno). This key will exist only
2829 if an error has occurred.
2830 status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
2832 IDLE, or VOID
2833 The state of the connection to the manager:
2834 VOID Connection is disabled.
2836 BACKOFF
2838 Attempting to reconnect at an increasing period.
2839 CONNECTING
2841 Attempting to connect.
2842 ACTIVE Connected, remote host responsive.
2844 IDLE Connection is idle. Waiting for response to keep-alive.
2846 These values may change in the future. They are provided only
2848 for human consumption.
2849 status : sec_since_connect: optional string, containing an integer, at
2851 least 0
2852 The amount of time since this client last successfully connected
2853 to the database (in seconds). Value is empty if client has never
2854 successfully been connected.
2855 status : sec_since_disconnect: optional string, containing an integer,
2857 at least 0
2858 The amount of time since this client last disconnected from the
2859 database (in seconds). Value is empty if client has never dis‐
2860 connected.
2861 status : locks_held: optional string
2863 Space-separated list of the names of OVSDB locks that the con‐
2864 nection holds. Omitted if the connection does not hold any
2865 locks.
2866 status : locks_waiting: optional string
2868 Space-separated list of the names of OVSDB locks that the con‐
2869 nection is currently waiting to acquire. Omitted if the connec‐
2870 tion is not waiting for any locks.
2871 status : locks_lost: optional string
2873 Space-separated list of the names of OVSDB locks that the con‐
2874 nection has had stolen by another OVSDB client. Omitted if no
2875 locks have been stolen from this connection.
2876 status : n_connections: optional string, containing an integer, at
2878 least 2
2879 When target specifies a connection method that listens for
2880 inbound connections (e.g. ptcp: or pssl:) and more than one con‐
2881 nection is actually active, the value is the number of active
2882 connections. Otherwise, this key-value pair is omitted.
2883 status : bound_port: optional string, containing an integer
2885 When target is ptcp: or pssl:, this is the TCP port on which the
2886 OVSDB server is listening. (This is particularly useful when
2887 target specifies a port of 0, allowing the kernel to choose any
2888 available port.)
2889 Common Columns:
2891 The overall purpose of these columns is described under Common Columns
2893 at the beginning of this document.
2894 external_ids: map of string-string pairs
2896 other_config: map of string-string pairs
2898
2900 SSL configuration for ovn-sb database access.
2901 Summary:
2903 private_key string
2904 certificate string
2905 ca_cert string
2906 bootstrap_ca_cert boolean
2907 ssl_protocols string
2908 ssl_ciphers string
2909 Common Columns:
2910 external_ids map of string-string pairs
2911 Details:
2913 private_key: string
2914 Name of a PEM file containing the private key used as the
2915 switch’s identity for SSL connections to the controller.
2916 certificate: string
2918 Name of a PEM file containing a certificate, signed by the cer‐
2919 tificate authority (CA) used by the controller and manager, that
2920 certifies the switch’s private key, identifying a trustworthy
2921 switch.
2922 ca_cert: string
2924 Name of a PEM file containing the CA certificate used to verify
2925 that the switch is connected to a trustworthy controller.
2926 bootstrap_ca_cert: boolean
2928 If set to true, then Open vSwitch will attempt to obtain the CA
2929 certificate from the controller on its first SSL connection and
2930 save it to the named PEM file. If it is successful, it will
2931 immediately drop the connection and reconnect, and from then on
2932 all SSL connections must be authenticated by a certificate
2933 signed by the CA certificate thus obtained. This option exposes
2934 the SSL connection to a man-in-the-middle attack obtaining the
2935 initial CA certificate. It may still be useful for bootstrap‐
2936 ping.
2937 ssl_protocols: string
2939 List of SSL protocols to be enabled for SSL connections. The
2940 default when this option is omitted is TLSv1,TLSv1.1,TLSv1.2.
2941 ssl_ciphers: string
2943 List of ciphers (in OpenSSL cipher string format) to be sup‐
2944 ported for SSL connections. The default when this option is
2945 omitted is HIGH:!aNULL:!MD5.
2946 Common Columns:
2948 The overall purpose of these columns is described under Common Columns
2950 at the beginning of this document.
2951 external_ids: map of string-string pairs
2953
2955 Each row in this table stores the DNS records. The OVN action
2956 dns_lookup uses this table for DNS resolution.
2957 Summary:
2959 records map of string-string pairs
2960 datapaths set of 1 or more Datapath_Bindings
2961 Common Columns:
2962 external_ids map of string-string pairs
2963 Details:
2965 records: map of string-string pairs
2966 Key-value pair of DNS records with DNS query name as the key and
2967 a string of IP address(es) separated by comma or space as the
2968 value. ovn-northd stores the DNS query name in all lowercase in
2969 order to facilitate case-insensitive lookups.
2970 Example: "vm1.ovn.org" = "10.0.0.4 aef0::4"
2972 datapaths: set of 1 or more Datapath_Bindings
2974 The DNS records defined in the column records will be applied
2975 only to the DNS queries originating from the datapaths defined
2976 in this column.
2977 Common Columns:
2979 external_ids: map of string-string pairs
2981 See External IDs at the beginning of this document.
2982
2984 Role table for role-based access controls.
2985 Summary:
2987 name string
2988 permissions map of string-weak reference to RBAC_Per‐
2989 mission pairs
2990 Details:
2992 name: string
2993 The role name, corresponding to the role column in the Connec‐
2994 tion table.
2995 permissions: map of string-weak reference to RBAC_Permission pairs
2997 A mapping of table names to rows in the RBAC_Permission table.
2998
3000 Permissions table for role-based access controls.
3001 Summary:
3003 table string
3004 authorization set of strings
3005 insert_delete boolean
3006 update set of strings
3007 Details:
3009 table: string
3010 Name of table to which this row applies.
3011 authorization: set of strings
3013 Set of strings identifying columns and column:key pairs to be
3014 compared with client ID. At least one match is required in order
3015 to be authorized. A zero-length string is treated as a special
3016 value indicating all clients should be considered authorized.
3017 insert_delete: boolean
3019 When "true", row insertions and authorized row deletions are
3020 permitted.
3021 update: set of strings
3023 Set of strings identifying columns and column:key pairs that
3024 authorized clients are allowed to modify.
3025
3027 Association of Port_Binding rows of type chassisredirect to a Chassis.
3028 The traffic going out through a specific chassisredirect port will be
3029 redirected to a chassis, or a set of them in high availability configu‐
3030 rations.
3031 Summary:
3033 name string (must be unique within table)
3034 chassis optional weak reference to Chassis
3035 priority integer, in range 0 to 32,767
3036 options map of string-string pairs
3037 Common Columns:
3038 external_ids map of string-string pairs
3039 Details:
3041 name: string (must be unique within table)
3042 Name of the Gateway_Chassis.
3043 A suggested, but not required naming convention is
3045 ${port_name}_${chassis_name}.
3046 chassis: optional weak reference to Chassis
3048 The Chassis to which we send the traffic.
3049 priority: integer, in range 0 to 32,767
3051 This is the priority the specific Chassis among all Gate‐
3052 way_Chassis belonging to the same Port_Binding.
3053 options: map of string-string pairs
3055 Reserved for future use.
3056 Common Columns:
3058 The overall purpose of these columns is described under Common Columns
3060 at the beginning of this document.
3061 external_ids: map of string-string pairs
3063
3065 Summary:
3066 chassis optional weak reference to Chassis
3067 priority integer, in range 0 to 32,767
3068 Common Columns:
3069 external_ids map of string-string pairs
3070 Details:
3072 chassis: optional weak reference to Chassis
3073 The Chassis which provides the HA functionality.
3074 priority: integer, in range 0 to 32,767
3076 Priority of the HA chassis. Chassis with highest priority will
3077 be the master in the HA chassis group.
3078 Common Columns:
3080 external_ids: map of string-string pairs
3082 See External IDs at the beginning of this document.
3083
3085 Table representing a group of chassis which can provide High availabil‐
3086 ity services. Each chassis in the group is represented by the table
3087 HA_Chassis. The HA chassis with highest priority will be the master of
3088 this group. If the master chassis failover is detected, the HA chassis
3089 with the next higher priority takes over the responsibility of provid‐
3090 ing the HA. If ha_chassis_group column of the table Port_Binding refer‐
3091 ences this table, then this HA chassis group provides the gateway func‐
3092 tionality and redirects the gateway traffic to the master of this
3093 group.
3094 Summary:
3096 name string (must be unique within table)
3097 ha_chassis set of HA_Chassises
3098 ref_chassis set of weak reference to Chassis
3099 Common Columns:
3100 external_ids map of string-string pairs
3101 Details:
3103 name: string (must be unique within table)
3104 Name of the HA_Chassis_Group. Name should be unique.
3105 ha_chassis: set of HA_Chassises
3107 A list of HA_Chassis which belongs to this group.
3108 ref_chassis: set of weak reference to Chassis
3110 The set of Chassis that reference this HA chassis group. To
3111 determine the correct Chassis, find the chassisredirect type
3112 Port_Binding that references this HA_Chassis_Group. This
3113 Port_Binding is derived from some particular logical router.
3114 Starting from that LR, find the set of all logical switches and
3115 routers connected to it, directly or indirectly, across router
3116 ports that link one LRP to another or to a LSP. For each LSP in
3117 these logical switches, find the corresponding Port_Binding and
3118 add its bound Chassis (if any) to ref_chassis.
3119 Common Columns:
3121 external_ids: map of string-string pairs
3123 See External IDs at the beginning of this document.
3124
3126 Database table used by ovn-controller to report CMS related events.
3127 Please note there is no guarantee a given event is written exactly once
3128 in the db. It is CMS responsibility to squash duplicated lines or to
3129 filter out duplicated events
3130 Summary:
3132 event_type string, must be empty_lb_backends
3133 event_info map of string-string pairs
3134 chassis optional weak reference to Chassis
3135 seq_num integer
3136 Details:
3138 event_type: string, must be empty_lb_backends
3139 Event type occurred
3140 event_info: map of string-string pairs
3142 Key-value pairs used to specify event info to the CMS. Possible
3143 values are:
3144 · vip: VIP reported for the empty_lb_backends event
3146 · protocol: Transport protocol reported for the
3148 empty_lb_backends event
3149 · load_balancer: UUID of the load balancer reported for the
3151 empty_lb_backends event
3152 chassis: optional weak reference to Chassis
3154 This column is a Chassis record to identify the chassis that has
3155 managed a given event.
3156 seq_num: integer
3158 Event sequence number. Global counter for controller generated
3159 events. It can be used by the CMS to detect possible duplication
3160 of the same event.
3161
3163 IP Multicast configuration options. For now only applicable to IGMP.
3164 Summary:
3166 datapath weak reference to Datapath_Binding (must
3167 be unique within table)
3168 enabled optional boolean
3169 querier optional boolean
3170 table_size optional integer
3171 idle_timeout optional integer
3172 query_interval optional integer
3173 seq_no integer
3174 Querier configuration options:
3175 eth_src string
3176 ip4_src string
3177 ip6_src string
3178 query_max_resp optional integer
3179 Details:
3181 datapath: weak reference to Datapath_Binding (must be unique within ta‐
3182 ble)
3183 Datapath_Binding entry for which these configuration options are
3184 defined.
3185 enabled: optional boolean
3187 Enables/disables multicast snooping. Default: disabled.
3188 querier: optional boolean
3190 Enables/disables multicast querying. If enabled then multicast
3191 querying is enabled by default.
3192 table_size: optional integer
3194 Limits the number of multicast groups that can be learned.
3195 Default: 2048 groups per datapath.
3196 idle_timeout: optional integer
3198 Configures the idle timeout (in seconds) for IP multicast groups
3199 if multicast snooping is enabled. Default: 300 seconds.
3200 query_interval: optional integer
3202 Configures the interval (in seconds) for sending multicast
3203 queries if snooping and querier are enabled. Default: idle_time‐
3204 out/2 seconds.
3205 seq_no: integer
3207 ovn-controller reads this value and flushes all learned multi‐
3208 cast groups when it detects that seq_no was changed.
3209 Querier configuration options:
3211 The ovn-controller process that runs on OVN hypervisor nodes uses the
3213 following columns to determine field values in IGMP/MLD queries that it
3214 originates:
3215 eth_src: string
3217 Source Ethernet address.
3218 ip4_src: string
3220 Source IPv4 address.
3221 ip6_src: string
3223 Source IPv6 address.
3224 query_max_resp: optional integer
3226 Value (in seconds) to be used as "max-response" field in multi‐
3227 cast queries. Default: 1 second.
3228
3230 Contains learned IGMP groups indexed by address/datapath/chassis.
3231 Summary:
3233 address string
3234 datapath optional weak reference to Datapath_Bind‐
3235 ing
3236 chassis optional weak reference to Chassis
3237 ports set of weak reference to Port_Bindings
3238 Details:
3240 address: string
3241 Destination IPv4 address for the IGMP group.
3242 datapath: optional weak reference to Datapath_Binding
3244 Datapath to which this IGMP group belongs.
3245 chassis: optional weak reference to Chassis
3247 Chassis to which this IGMP group belongs.
3248 ports: set of weak reference to Port_Bindings
3250 The destination port bindings for this IGMP group.
3251
3253 Each row in this table configures monitoring a service for its live‐
3254 ness. The service can be an IPv4 TCP or UDP service. ovn-controller
3255 periodically sends out service monitor packets and updates the status
3256 of the service. Service monitoring for IPv6 services is not supported.
3257 ovn-northd uses this feature to implement the load balancer health
3259 check feature offered to the CMS through the northbound database.
3260 Summary:
3262 Configuration:
3263 ip string
3264 protocol optional string, either tcp or udp
3265 port integer, in range 0 to 32,767
3266 logical_port string
3267 src_mac string
3268 src_ip string
3269 options : interval optional string, containing an integer
3270 options : timeout optional string, containing an integer
3271 options : success_count optional string, containing an integer
3272 options : failure_count optional string, containing an integer
3273 Status Reporting:
3274 status optional string, one of error, offline,
3275 or online
3276 Common Columns:
3277 external_ids map of string-string pairs
3278 Details:
3280 Configuration:
3281 ovn-northd sets these columns and values to configure the service moni‐
3283 tor.
3284 ip: string
3286 IP of the service to be monitored. Only IPv4 is supported.
3287 protocol: optional string, either tcp or udp
3289 The protocol of the service.
3290 port: integer, in range 0 to 32,767
3292 The TCP or UDP port of the service.
3293 logical_port: string
3295 The VIF of the logical port on which the service is running. The
3296 ovn-controller that binds this logical_port monitors the service
3297 by sending periodic monitor packets.
3298 src_mac: string
3300 Source Ethernet address to use in the service monitor packet.
3301 src_ip: string
3303 Source IPv4 address to use in the service monitor packet.
3304 options : interval: optional string, containing an integer
3306 The interval, in seconds, between service monitor checks.
3307 options : timeout: optional string, containing an integer
3309 The time, in seconds, after which the service monitor check
3310 times out.
3311 options : success_count: optional string, containing an integer
3313 The number of successful checks after which the service is con‐
3314 sidered online.
3315 options : failure_count: optional string, containing an integer
3317 The number of failure checks after which the service is consid‐
3318 ered offline.
3319 Status Reporting:
3321 The ovn-controller on the chassis that hosts the logical_port updates
3323 this column to report the service’s status.
3324 status: optional string, one of error, offline, or online
3326 For TCP service, ovn-controller sends a SYN to the service and
3327 expects an ACK response to consider the service to be online.
3328 For UDP service, ovn-controller sends a UDP packet to the ser‐
3330 vice and doesn’t expect any reply. If it receives an ICMP reply,
3331 then it considers the service to be offline.
3332 Common Columns:
3334 external_ids: map of string-string pairs
3336 See External IDs at the beginning of this document.
3337
3339 Each row represents a load balancer.
3340 Summary:
3342 name string
3343 vips map of string-string pairs
3344 protocol optional string, one of sctp, tcp, or udp
3345 datapaths set of Datapath_Bindings
3346 Load_Balancer options:
3347 options : hairpin_snat_ip optional string
3348 Common Columns:
3349 external_ids map of string-string pairs
3350 Details:
3352 name: string
3353 A name for the load balancer. This name has no special meaning
3354 or purpose other than to provide convenience for human interac‐
3355 tion with the ovn-nb database.
3356 vips: map of string-string pairs
3358 A map of virtual IP addresses (and an optional port number with
3359 : as a separator) associated with this load balancer and their
3360 corresponding endpoint IP addresses (and optional port numbers
3361 with : as separators) separated by commas.
3362 protocol: optional string, one of sctp, tcp, or udp
3364 Valid protocols are tcp, udp, or sctp. This column is useful
3365 when a port number is provided as part of the vips column. If
3366 this column is empty and a port number is provided as part of
3367 vips column, OVN assumes the protocol to be tcp.
3368 datapaths: set of Datapath_Bindings
3370 Datapaths to which this load balancer applies to.
3371 Load_Balancer options:
3373 options : hairpin_snat_ip: optional string
3375 IP to be used as source IP for packets that have been hair-
3376 pinned after load balancing. This value is automatically popu‐
3377 lated by ovn-northd.
3378 Common Columns:
3380 external_ids: map of string-string pairs
3382 See External IDs at the beginning of this document.
3383
3385 Contains BFD parameter for ovn-controller bfd configuration.
3386 Summary:
3388 Configuration:
3389 src_port integer, in range 49,152 to 65,535
3390 disc integer
3391 logical_port string
3392 dst_ip string
3393 min_tx integer
3394 min_rx integer
3395 detect_mult integer
3396 options map of string-string pairs
3397 external_ids map of string-string pairs
3398 Status Reporting:
3399 status string, one of admin_down, down, init, or
3400 up
3401 Details:
3403 Configuration:
3404 src_port: integer, in range 49,152 to 65,535
3406 udp source port used in bfd control packets. The source port
3407 MUST be in the range 49152 through 65535 (RFC5881 section 4).
3408 disc: integer
3410 A unique, nonzero discriminator value generated by the transmit‐
3411 ting system, used to demultiplex multiple BFD sessions between
3412 the same pair of systems.
3413 logical_port: string
3415 OVN logical port when BFD engine is running.
3416 dst_ip: string
3418 BFD peer IP address.
3419 min_tx: integer
3421 This is the minimum interval, in milliseconds, that the local
3422 system would like to use when transmitting BFD Control packets,
3423 less any jitter applied. The value zero is reserved.
3424 min_rx: integer
3426 This is the minimum interval, in milliseconds, between received
3427 BFD Control packets that this system is capable of supporting,
3428 less any jitter applied by the sender. If this value is zero,
3429 the transmitting system does not want the remote system to send
3430 any periodic BFD Control packets.
3431 detect_mult: integer
3433 Detection time multiplier. The negotiated transmit interval,
3434 multiplied by this value, provides the Detection Time for the
3435 receiving system in Asynchronous mode.
3436 options: map of string-string pairs
3438 Reserved for future use.
3439 external_ids: map of string-string pairs
3441 See External IDs at the beginning of this document.
3442 Status Reporting:
3444 status: string, one of admin_down, down, init, or up
3446 BFD port logical states. Possible values are:
3447 · admin_down
3449 · down
3451 · init
3453 · up
3455Open vSwitch 20.12.0 DB Schema 20.15.0 ovn-sb(5)