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 Encap Encapsulation Types
114 Address_Set
115 Address Sets
116 Port_Group
117 Port Groups
118 Logical_Flow
119 Logical Network Flows
120 Multicast_Group
121 Logical Port Multicast Groups
122 Meter Meter entry
123 Meter_Band
124 Band for meter entries
125 Datapath_Binding
126 Physical-Logical Datapath Bindings
127 Port_Binding
128 Physical-Logical Port Bindings
129 MAC_Binding
130 IP to MAC bindings
131 DHCP_Options
132 DHCP Options supported by native OVN DHCP
133 DHCPv6_Options
134 DHCPv6 Options supported by native OVN DHCPv6
135 Connection
136 OVSDB client connections.
137 SSL SSL configuration.
138 DNS Native DNS resolution
139 RBAC_Role RBAC_Role configuration.
140 RBAC_Permission
141 RBAC_Permission configuration.
142 Gateway_Chassis
143 Gateway_Chassis configuration.
144 HA_Chassis
145 HA_Chassis configuration.
146 HA_Chassis_Group
147 HA_Chassis_Group configuration.
148 Controller_Event
149 Controller Event table
150 IP_Multicast
151 IP_Multicast configuration.
152 IGMP_Group
153 IGMP_Group configuration.
154 Service_Monitor
155 Service_Monitor configuration.
156
158 Southbound configuration for an OVN system. This table must have
159 exactly one row.
160 Summary:
162 Status:
163 nb_cfg integer
164 Common Columns:
165 external_ids map of string-string pairs
166 options map of string-string pairs
167 Common options:
168 options map of string-string pairs
169 Options for configuring BFD:
170 options : bfd-min-rx optional string
171 options : bfd-decay-min-rx
172 optional string
173 options : bfd-min-tx optional string
174 options : bfd-mult optional string
175 Connection Options:
176 connections set of Connections
177 ssl optional SSL
178 Security Configurations:
179 ipsec boolean
180 Details:
182 Status:
183 This column allow a client to track the overall configuration state of
185 the system.
186 nb_cfg: integer
188 Sequence number for the configuration. When a CMS or ovn-nbctl
189 updates the northbound database, it increments the nb_cfg column
190 in the NB_Global table in the northbound database. In turn, when
191 ovn-northd updates the southbound database to bring it up to
192 date with these changes, it updates this column to the same
193 value.
194 Common Columns:
196 external_ids: map of string-string pairs
198 See External IDs at the beginning of this document.
199 options: map of string-string pairs
201 Common options:
203 options: map of string-string pairs
205 This column provides general key/value settings. The supported
206 options are described individually below.
207 Options for configuring BFD:
209 These options apply when ovn-controller configures BFD on tunnels
211 interfaces.
212 options : bfd-min-rx: optional string
214 BFD option min-rx value to use when configuring BFD on tunnel
215 interfaces.
216 options : bfd-decay-min-rx: optional string
218 BFD option decay-min-rx value to use when configuring BFD on
219 tunnel interfaces.
220 options : bfd-min-tx: optional string
222 BFD option min-tx value to use when configuring BFD on tunnel
223 interfaces.
224 options : bfd-mult: optional string
226 BFD option mult value to use when configuring BFD on tunnel
227 interfaces.
228 Connection Options:
230 connections: set of Connections
232 Database clients to which the Open vSwitch database server
233 should connect or on which it should listen, along with options
234 for how these connections should be configured. See the Connec‐
235 tion table for more information.
236 ssl: optional SSL
238 Global SSL configuration.
239 Security Configurations:
241 ipsec: boolean
243 Tunnel encryption configuration. If this column is set to be
244 true, all OVN tunnels will be encrypted with IPsec.
246 Each row in this table represents a hypervisor or gateway (a chassis)
247 in the physical network. Each chassis, via ovn-controller/ovn-con‐
248 troller-vtep, adds and updates its own row, and keeps a copy of the
249 remaining rows to determine how to reach other hypervisors.
250 When a chassis shuts down gracefully, it should remove its own row.
252 (This is not critical because resources hosted on the chassis are
253 equally unreachable regardless of whether the row is present.) If a
254 chassis shuts down permanently without removing its row, some kind of
255 manual or automatic cleanup is eventually needed; we can devise a
256 process for that as necessary.
257 Summary:
259 name string (must be unique within table)
260 hostname string
261 nb_cfg integer
262 external_ids : ovn-bridge-mappings
263 optional string
264 external_ids : datapath-type optional string
265 external_ids : iface-types optional string
266 external_ids : ovn-cms-options
267 optional string
268 external_ids : is-interconn optional string
269 external_ids : is-remote optional string
270 transport_zones set of strings
271 external_ids : ovn-chassis-mac-mappings
272 optional string
273 Common Columns:
274 external_ids map of string-string pairs
275 Encapsulation Configuration:
276 encaps set of 1 or more Encaps
277 Gateway Configuration:
278 vtep_logical_switches set of strings
279 Details:
281 name: string (must be unique within table)
282 OVN does not prescribe a particular format for chassis names.
283 ovn-controller populates this column using external_ids:system-
284 id in the Open_vSwitch database’s Open_vSwitch table. ovn-con‐
285 troller-vtep populates this column with name in the hard‐
286 ware_vtep database’s Physical_Switch table.
287 hostname: string
289 The hostname of the chassis, if applicable. ovn-controller will
290 populate this column with the hostname of the host it is running
291 on. ovn-controller-vtep will leave this column empty.
292 nb_cfg: integer
294 Sequence number for the configuration. When ovn-controller
295 updates the configuration of a chassis from the contents of the
296 southbound database, it copies nb_cfg from the SB_Global table
297 into this column.
298 external_ids : ovn-bridge-mappings: optional string
300 ovn-controller populates this key with the set of bridge map‐
301 pings it has been configured to use. Other applications should
302 treat this key as read-only. See ovn-controller(8) for more
303 information.
304 external_ids : datapath-type: optional string
306 ovn-controller populates this key with the datapath type config‐
307 ured in the datapath_type column of the Open_vSwitch database’s
308 Bridge table. Other applications should treat this key as read-
309 only. See ovn-controller(8) for more information.
310 external_ids : iface-types: optional string
312 ovn-controller populates this key with the interface types con‐
313 figured in the iface_types column of the Open_vSwitch database’s
314 Open_vSwitch table. Other applications should treat this key as
315 read-only. See ovn-controller(8) for more information.
316 external_ids : ovn-cms-options: optional string
318 ovn-controller populates this key with the set of options con‐
319 figured in the external_ids:ovn-cms-options column of the
320 Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
321 troller(8) for more information.
322 external_ids : is-interconn: optional string
324 ovn-controller populates this key with the setting configured in
325 the external_ids:ovn-is-interconn column of the Open_vSwitch
326 database’s Open_vSwitch table. If set to true, the chassis is
327 used as an interconnection gateway. See ovn-controller(8) for
328 more information.
329 external_ids : is-remote: optional string
331 ovn-ic set this key to true for remote interconnection gateway
332 chassises learned from the interconnection southbound database.
333 See ovn-ic(8) for more information.
334 transport_zones: set of strings
336 ovn-controller populates this key with the transport zones con‐
337 figured in the external_ids:ovn-transport-zones column of the
338 Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
339 troller(8) for more information.
340 external_ids : ovn-chassis-mac-mappings: optional string
342 ovn-controller populates this key with the set of options con‐
343 figured in the external_ids:ovn-chassis-mac-mappings column of
344 the Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
345 troller(8) for more information.
346 Common Columns:
348 The overall purpose of these columns is described under Common Columns
350 at the beginning of this document.
351 external_ids: map of string-string pairs
353 Encapsulation Configuration:
355 OVN uses encapsulation to transmit logical dataplane packets between
357 chassis.
358 encaps: set of 1 or more Encaps
360 Points to supported encapsulation configurations to transmit
361 logical dataplane packets to this chassis. Each entry is a Encap
362 record that describes the configuration.
363 Gateway Configuration:
365 A gateway is a chassis that forwards traffic between the OVN-managed
367 part of a logical network and a physical VLAN, extending a tunnel-based
368 logical network into a physical network. Gateways are typically dedi‐
369 cated nodes that do not host VMs and will be controlled by ovn-con‐
370 troller-vtep.
371 vtep_logical_switches: set of strings
373 Stores all VTEP logical switch names connected by this gateway
374 chassis. The Port_Binding table entry with options:vtep-physi‐
375 cal-switch equal Chassis name, and options:vtep-logical-switch
376 value in Chassis vtep_logical_switches, will be associated with
377 this Chassis.
378
380 The encaps column in the Chassis table refers to rows in this table to
381 identify how OVN may transmit logical dataplane packets to this chas‐
382 sis. Each chassis, via ovn-controller(8) or ovn-controller-vtep(8),
383 adds and updates its own rows and keeps a copy of the remaining rows to
384 determine how to reach other chassis.
385 Summary:
387 type string, one of geneve, stt, or vxlan
388 options map of string-string pairs
389 options : csum optional string, either true or false
390 options : dst_port optional string, containing an integer
391 ip string
392 chassis_name string
393 Details:
395 type: string, one of geneve, stt, or vxlan
396 The encapsulation to use to transmit packets to this chassis.
397 Hypervisors must use either geneve or stt. Gateways may use
398 vxlan, geneve, or stt.
399 options: map of string-string pairs
401 Options for configuring the encapsulation, which may be type
402 specific.
403 options : csum: optional string, either true or false
405 csum indicates whether this chassis can transmit and receive
406 packets that include checksums with reasonable performance. It
407 hints to senders transmitting data to this chassis that they
408 should use checksums to protect OVN metadata. ovn-controller
409 populates this key with the value defined in external_ids:ovn-
410 encap-csum column of the Open_vSwitch database’s Open_vSwitch
411 table. Other applications should treat this key as read-only.
412 See ovn-controller(8) for more information.
413 In terms of performance, checksumming actually significantly
415 increases throughput in most common cases when running on Linux
416 based hosts without NICs supporting encapsulation hardware off‐
417 load (around 60% for bulk traffic). The reason is that generally
418 all NICs are capable of offloading transmitted and received
419 TCP/UDP checksums (viewed as ordinary data packets and not as
420 tunnels). The benefit comes on the receive side where the vali‐
421 dated outer checksum can be used to additionally validate an
422 inner checksum (such as TCP), which in turn allows aggregation
423 of packets to be more efficiently handled by the rest of the
424 stack.
425 Not all devices see such a benefit. The most notable exception
427 is hardware VTEPs. These devices are designed to not buffer
428 entire packets in their switching engines and are therefore
429 unable to efficiently compute or validate full packet checksums.
430 In addition certain versions of the Linux kernel are not able to
431 fully take advantage of encapsulation NIC offloads in the pres‐
432 ence of checksums. (This is actually a pretty narrow corner case
433 though: earlier versions of Linux don’t support encapsulation
434 offloads at all and later versions support both offloads and
435 checksums well.)
436 csum defaults to false for hardware VTEPs and true for all other
438 cases.
439 This option applies to geneve and vxlan encapsulations.
441 options : dst_port: optional string, containing an integer
443 If set, overrides the UDP (for geneve and vxlan) or TCP (for
444 stt) destination port.
445 ip: string
447 The IPv4 address of the encapsulation tunnel endpoint.
448 chassis_name: string
450 The name of the chassis that created this encap.
451
453 This table contains address sets synced from the Address_Set table in
454 the OVN_Northbound database and address sets generated from the
455 Port_Group table in the OVN_Northbound database.
456 See the documentation for the Address_Set table and Port_Group table in
458 the OVN_Northbound database for details.
459 Summary:
461 name string (must be unique within table)
462 addresses set of strings
463 Details:
465 name: string (must be unique within table)
466 addresses: set of strings
468
470 This table contains names for the logical switch ports in the
471 OVN_Northbound database that belongs to the same group that is defined
472 in Port_Group in the OVN_Northbound database.
473 Summary:
475 name string (must be unique within table)
476 ports set of strings
477 Details:
479 name: string (must be unique within table)
480 ports: set of strings
482
484 Each row in this table represents one logical flow. ovn-northd popu‐
485 lates this table with logical flows that implement the L2 and L3
486 topologies specified in the OVN_Northbound database. Each hypervisor,
487 via ovn-controller, translates the logical flows into OpenFlow flows
488 specific to its hypervisor and installs them into Open vSwitch.
489 Logical flows are expressed in an OVN-specific format, described here.
491 A logical datapath flow is much like an OpenFlow flow, except that the
492 flows are written in terms of logical ports and logical datapaths
493 instead of physical ports and physical datapaths. Translation between
494 logical and physical flows helps to ensure isolation between logical
495 datapaths. (The logical flow abstraction also allows the OVN central‐
496 ized components to do less work, since they do not have to separately
497 compute and push out physical flows to each chassis.)
498 The default action when no flow matches is to drop packets.
500 Architectural Logical Life Cycle of a Packet
502 This following description focuses on the life cycle of a packet
504 through a logical datapath, ignoring physical details of the implemen‐
505 tation. Please refer to Architectural Physical Life Cycle of a Packet
506 in ovn-architecture(7) for the physical information.
507 The description here is written as if OVN itself executes these steps,
509 but in fact OVN (that is, ovn-controller) programs Open vSwitch, via
510 OpenFlow and OVSDB, to execute them on its behalf.
511 At a high level, OVN passes each packet through the logical datapath’s
513 logical ingress pipeline, which may output the packet to one or more
514 logical port or logical multicast groups. For each such logical output
515 port, OVN passes the packet through the datapath’s logical egress pipe‐
516 line, which may either drop the packet or deliver it to the destina‐
517 tion. Between the two pipelines, outputs to logical multicast groups
518 are expanded into logical ports, so that the egress pipeline only pro‐
519 cesses a single logical output port at a time. Between the two pipe‐
520 lines is also where, when necessary, OVN encapsulates a packet in a
521 tunnel (or tunnels) to transmit to remote hypervisors.
522 In more detail, to start, OVN searches the Logical_Flow table for a row
524 with correct logical_datapath, a pipeline of ingress, a table_id of 0,
525 and a match that is true for the packet. If none is found, OVN drops
526 the packet. If OVN finds more than one, it chooses the match with the
527 highest priority. Then OVN executes each of the actions specified in
528 the row’s actions column, in the order specified. Some actions, such as
529 those to modify packet headers, require no further details. The next
530 and output actions are special.
531 The next action causes the above process to be repeated recursively,
533 except that OVN searches for table_id of 1 instead of 0. Similarly, any
534 next action in a row found in that table would cause a further search
535 for a table_id of 2, and so on. When recursive processing completes,
536 flow control returns to the action following next.
537 The output action also introduces recursion. Its effect depends on the
539 current value of the outport field. Suppose outport designates a logi‐
540 cal port. First, OVN compares inport to outport; if they are equal, it
541 treats the output as a no-op by default. In the common case, where they
542 are different, the packet enters the egress pipeline. This transition
543 to the egress pipeline discards register data, e.g. reg0 ... reg9 and
544 connection tracking state, to achieve uniform behavior regardless of
545 whether the egress pipeline is on a different hypervisor (because reg‐
546 isters aren’t preserve across tunnel encapsulation).
547 To execute the egress pipeline, OVN again searches the Logical_Flow ta‐
549 ble for a row with correct logical_datapath, a table_id of 0, a match
550 that is true for the packet, but now looking for a pipeline of egress.
551 If no matching row is found, the output becomes a no-op. Otherwise, OVN
552 executes the actions for the matching flow (which is chosen from multi‐
553 ple, if necessary, as already described).
554 In the egress pipeline, the next action acts as already described,
556 except that it, of course, searches for egress flows. The output
557 action, however, now directly outputs the packet to the output port
558 (which is now fixed, because outport is read-only within the egress
559 pipeline).
560 The description earlier assumed that outport referred to a logical
562 port. If it instead designates a logical multicast group, then the
563 description above still applies, with the addition of fan-out from the
564 logical multicast group to each logical port in the group. For each
565 member of the group, OVN executes the logical pipeline as described,
566 with the logical output port replaced by the group member.
567 Pipeline Stages
569 ovn-northd populates the Logical_Flow table with the logical flows
571 described in detail in ovn-northd(8).
572 Summary:
574 logical_datapath Datapath_Binding
575 pipeline string, either egress or ingress
576 table_id integer, in range 0 to 23
577 priority integer, in range 0 to 65,535
578 match string
579 actions string
580 external_ids : stage-name optional string
581 external_ids : stage-hint optional string, containing an uuid
582 external_ids : source optional string
583 Common Columns:
584 external_ids map of string-string pairs
585 Details:
587 logical_datapath: Datapath_Binding
588 The logical datapath to which the logical flow belongs.
589 pipeline: string, either egress or ingress
591 The primary flows used for deciding on a packet’s destination
592 are the ingress flows. The egress flows implement ACLs. See Log‐
593 ical Life Cycle of a Packet, above, for details.
594 table_id: integer, in range 0 to 23
596 The stage in the logical pipeline, analogous to an OpenFlow ta‐
597 ble number.
598 priority: integer, in range 0 to 65,535
600 The flow’s priority. Flows with numerically higher priority take
601 precedence over those with lower. If two logical datapath flows
602 with the same priority both match, then the one actually applied
603 to the packet is undefined.
604 match: string
606 A matching expression. OVN provides a superset of OpenFlow
607 matching capabilities, using a syntax similar to Boolean expres‐
608 sions in a programming language.
609 The most important components of match expression are compar‐
611 isons between symbols and constants, e.g. ip4.dst ==
612 192.168.0.1, ip.proto == 6, arp.op == 1, eth.type == 0x800. The
613 logical AND operator && and logical OR operator || can combine
614 comparisons into a larger expression.
615 Matching expressions also support parentheses for grouping, the
617 logical NOT prefix operator !, and literals 0 and 1 to express
618 ``false’’ or ``true,’’ respectively. The latter is useful by
619 itself as a catch-all expression that matches every packet.
620 Match expressions also support a kind of function syntax. The
622 following functions are supported:
623 is_chassis_resident(lport)
625 Evaluates to true on a chassis on which logical port
626 lport (a quoted string) resides, and to false elsewhere.
627 This function was introduced in OVN 2.7.
628 Symbols
630 Type. Symbols have integer or string type. Integer symbols have
632 a width in bits.
633 Kinds. There are three kinds of symbols:
635 · Fields. A field symbol represents a packet header or
637 metadata field. For example, a field named vlan.tci might
638 represent the VLAN TCI field in a packet.
639 A field symbol can have integer or string type. Integer
641 fields can be nominal or ordinal (see Level of Measure‐
642 ment, below).
643 · Subfields. A subfield represents a subset of bits from a
645 larger field. For example, a field vlan.vid might be
646 defined as an alias for vlan.tci[0..11]. Subfields are
647 provided for syntactic convenience, because it is always
648 possible to instead refer to a subset of bits from a
649 field directly.
650 Only ordinal fields (see Level of Measurement, below) may
652 have subfields. Subfields are always ordinal.
653 · Predicates. A predicate is shorthand for a Boolean
655 expression. Predicates may be used much like 1-bit
656 fields. For example, ip4 might expand to eth.type ==
657 0x800. Predicates are provided for syntactic convenience,
658 because it is always possible to instead specify the
659 underlying expression directly.
660 A predicate whose expansion refers to any nominal field
662 or predicate (see Level of Measurement, below) is nomi‐
663 nal; other predicates have Boolean level of measurement.
664 Level of Measurement. See
666 http://en.wikipedia.org/wiki/Level_of_measurement for the sta‐
667 tistical concept on which this classification is based. There
668 are three levels:
669 · Ordinal. In statistics, ordinal values can be ordered on
671 a scale. OVN considers a field (or subfield) to be ordi‐
672 nal if its bits can be examined individually. This is
673 true for the OpenFlow fields that OpenFlow or Open
674 vSwitch makes ``maskable.’’
675 Any use of a ordinal field may specify a single bit or a
677 range of bits, e.g. vlan.tci[13..15] refers to the PCP
678 field within the VLAN TCI, and eth.dst[40] refers to the
679 multicast bit in the Ethernet destination address.
680 OVN supports all the usual arithmetic relations (==, !=,
682 <, <=, >, and >=) on ordinal fields and their subfields,
683 because OVN can implement these in OpenFlow and Open
684 vSwitch as collections of bitwise tests.
685 · Nominal. In statistics, nominal values cannot be usefully
687 compared except for equality. This is true of OpenFlow
688 port numbers, Ethernet types, and IP protocols are exam‐
689 ples: all of these are just identifiers assigned arbi‐
690 trarily with no deeper meaning. In OpenFlow and Open
691 vSwitch, bits in these fields generally aren’t individu‐
692 ally addressable.
693 OVN only supports arithmetic tests for equality on nomi‐
695 nal fields, because OpenFlow and Open vSwitch provide no
696 way for a flow to efficiently implement other comparisons
697 on them. (A test for inequality can be sort of built out
698 of two flows with different priorities, but OVN matching
699 expressions always generate flows with a single prior‐
700 ity.)
701 String fields are always nominal.
703 · Boolean. A nominal field that has only two values, 0 and
705 1, is somewhat exceptional, since it is easy to support
706 both equality and inequality tests on such a field:
707 either one can be implemented as a test for 0 or 1.
708 Only predicates (see above) have a Boolean level of mea‐
710 surement.
711 This isn’t a standard level of measurement.
713 Prerequisites. Any symbol can have prerequisites, which are
715 additional condition implied by the use of the symbol. For exam‐
716 ple, For example, icmp4.type symbol might have prerequisite
717 icmp4, which would cause an expression icmp4.type == 0 to be
718 interpreted as icmp4.type == 0 && icmp4, which would in turn
719 expand to icmp4.type == 0 && eth.type == 0x800 && ip4.proto == 1
720 (assuming icmp4 is a predicate defined as suggested under Types
721 above).
722 Relational operators
724 All of the standard relational operators ==, !=, <, <=, >, and
726 >= are supported. Nominal fields support only == and !=, and
727 only in a positive sense when outer ! are taken into account,
728 e.g. given string field inport, inport == "eth0" and !(inport !=
729 "eth0") are acceptable, but not inport != "eth0".
730 The implementation of == (or != when it is negated), is more
732 efficient than that of the other relational operators.
733 Constants
735 Integer constants may be expressed in decimal, hexadecimal pre‐
737 fixed by 0x, or as dotted-quad IPv4 addresses, IPv6 addresses in
738 their standard forms, or Ethernet addresses as colon-separated
739 hex digits. A constant in any of these forms may be followed by
740 a slash and a second constant (the mask) in the same form, to
741 form a masked constant. IPv4 and IPv6 masks may be given as
742 integers, to express CIDR prefixes.
743 String constants have the same syntax as quoted strings in JSON
745 (thus, they are Unicode strings).
746 Some operators support sets of constants written inside curly
748 braces { ... }. Commas between elements of a set, and after the
749 last elements, are optional. With ==, ``field == { constant1,
750 constant2, ... }’’ is syntactic sugar for ``field == constant1
751 || field == constant2 || .... Similarly, ``field != { constant1,
752 constant2, ... }’’ is equivalent to ``field != constant1 &&
753 field != constant2 && ...’’.
754 You may refer to a set of IPv4, IPv6, or MAC addresses stored in
756 the Address_Set table by its name. An Address_Set with a name of
757 set1 can be referred to as $set1.
758 You may refer to a group of logical switch ports stored in the
760 Port_Group table by its name. An Port_Group with a name of
761 port_group1 can be referred to as @port_group1.
762 Additionally, you may refer to the set of addresses belonging to
764 a group of logical switch ports stored in the Port_Group table
765 by its name followed by a suffix ’_ip4’/’_ip6’. The IPv4 address
766 set of a Port_Group with a name of port_group1 can be referred
767 to as $port_group1_ip4, and the IPv6 address set of the same
768 Port_Group can be referred to as $port_group1_ip6
769 Miscellaneous
771 Comparisons may name the symbol or the constant first, e.g.
773 tcp.src == 80 and 80 == tcp.src are both acceptable.
774 Tests for a range may be expressed using a syntax like 1024 <=
776 tcp.src <= 49151, which is equivalent to 1024 <= tcp.src &&
777 tcp.src <= 49151.
778 For a one-bit field or predicate, a mention of its name is
780 equivalent to symobl == 1, e.g. vlan.present is equivalent to
781 vlan.present == 1. The same is true for one-bit subfields, e.g.
782 vlan.tci[12]. There is no technical limitation to implementing
783 the same for ordinal fields of all widths, but the implementa‐
784 tion is expensive enough that the syntax parser requires writing
785 an explicit comparison against zero to make mistakes less
786 likely, e.g. in tcp.src != 0 the comparison against 0 is
787 required.
788 Operator precedence is as shown below, from highest to lowest.
790 There are two exceptions where parentheses are required even
791 though the table would suggest that they are not: && and ||
792 require parentheses when used together, and ! requires parenthe‐
793 ses when applied to a relational expression. Thus, in (eth.type
794 == 0x800 || eth.type == 0x86dd) && ip.proto == 6 or !(arp.op ==
795 1), the parentheses are mandatory.
796 · ()
798 · == != < <= > >=
800 · !
802 · && ||
804 Comments may be introduced by //, which extends to the next new-
806 line. Comments within a line may be bracketed by /* and */. Mul‐
807 tiline comments are not supported.
808 Symbols
810 Most of the symbols below have integer type. Only inport and
812 outport have string type. inport names a logical port. Thus, its
813 value is a logical_port name from the Port_Binding table. out‐
814 port may name a logical port, as inport, or a logical multicast
815 group defined in the Multicast_Group table. For both symbols,
816 only names within the flow’s logical datapath may be used.
817 The regX symbols are 32-bit integers. The xxregX symbols are
819 128-bit integers, which overlay four of the 32-bit registers:
820 xxreg0 overlays reg0 through reg3, with reg0 supplying the most-
821 significant bits of xxreg0 and reg3 the least-signficant. xxreg1
822 similarly overlays reg4 through reg7.
823 · reg0...reg9
825 · xxreg0 xxreg1
827 · inport outport
829 · flags.loopback
831 · eth.src eth.dst eth.type
833 · vlan.tci vlan.vid vlan.pcp vlan.present
835 · ip.proto ip.dscp ip.ecn ip.ttl ip.frag
837 · ip4.src ip4.dst
839 · ip6.src ip6.dst ip6.label
841 · arp.op arp.spa arp.tpa arp.sha arp.tha
843 · tcp.src tcp.dst tcp.flags
845 · udp.src udp.dst
847 · sctp.src sctp.dst
849 · icmp4.type icmp4.code
851 · icmp6.type icmp6.code
853 · nd.target nd.sll nd.tll
855 · ct_mark ct_label
857 · ct_state, which has several Boolean subfields. The
859 ct_next action initializes the following subfields:
860 · ct.trk: Always set to true by ct_next to indicate
862 that connection tracking has taken place. All
863 other ct subfields have ct.trk as a prerequisite.
864 · ct.new: True for a new flow
866 · ct.est: True for an established flow
868 · ct.rel: True for a related flow
870 · ct.rpl: True for a reply flow
872 · ct.inv: True for a connection entry in a bad state
874 The ct_dnat, ct_snat, and ct_lb actions initialize the
876 following subfields:
877 · ct.dnat: True for a packet whose destination IP
879 address has been changed.
880 · ct.snat: True for a packet whose source IP address
882 has been changed.
883 The following predicates are supported:
885 · eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff
887 · eth.mcast expands to eth.dst[40]
889 · vlan.present expands to vlan.tci[12]
891 · ip4 expands to eth.type == 0x800
893 · ip4.src_mcast expands to ip4.src[28..31] == 0xe
895 · ip4.mcast expands to ip4.dst[28..31] == 0xe
897 · ip6 expands to eth.type == 0x86dd
899 · ip expands to ip4 || ip6
901 · icmp4 expands to ip4 && ip.proto == 1
903 · icmp6 expands to ip6 && ip.proto == 58
905 · icmp expands to icmp4 || icmp6
907 · ip.is_frag expands to ip.frag[0]
909 · ip.later_frag expands to ip.frag[1]
911 · ip.first_frag expands to ip.is_frag && !ip.later_frag
913 · arp expands to eth.type == 0x806
915 · nd expands to icmp6.type == {135, 136} && icmp6.code == 0
917 && ip.ttl == 255
918 · nd_ns expands to icmp6.type == 135 && icmp6.code == 0 &&
920 ip.ttl == 255
921 · nd_na expands to icmp6.type == 136 && icmp6.code == 0 &&
923 ip.ttl == 255
924 · nd_rs expands to icmp6.type == 133 && icmp6.code == 0 &&
926 ip.ttl == 255
927 · nd_ra expands to icmp6.type == 134 && icmp6.code == 0 &&
929 ip.ttl == 255
930 · tcp expands to ip.proto == 6
932 · udp expands to ip.proto == 17
934 · sctp expands to ip.proto == 132
936 actions: string
938 Logical datapath actions, to be executed when the logical flow
939 represented by this row is the highest-priority match.
940 Actions share lexical syntax with the match column. An empty set
942 of actions (or one that contains just white space or comments),
943 or a set of actions that consists of just drop;, causes the
944 matched packets to be dropped. Otherwise, the column should con‐
945 tain a sequence of actions, each terminated by a semicolon.
946 The following actions are defined:
948 output;
950 In the ingress pipeline, this action executes the egress
951 pipeline as a subroutine. If outport names a logical
952 port, the egress pipeline executes once; if it is a mul‐
953 ticast group, the egress pipeline runs once for each log‐
954 ical port in the group.
955 In the egress pipeline, this action performs the actual
957 output to the outport logical port. (In the egress pipe‐
958 line, outport never names a multicast group.)
959 By default, output to the input port is implicitly
961 dropped, that is, output becomes a no-op if outport ==
962 inport. Occasionally it may be useful to override this
963 behavior, e.g. to send an ARP reply to an ARP request; to
964 do so, use flags.loopback = 1 to allow the packet to
965 "hair-pin" back to the input port.
966 next;
968 next(table);
969 next(pipeline=pipeline, table=table);
970 Executes the given logical datapath table in pipeline as a
971 subroutine. The default table is just after the current
972 one. If pipeline is specified, it may be ingress or egress;
973 the default pipeline is the one currently executing.
974 Actions in the both ingress and egress pipeline can use
975 next to jump across the other pipeline. Actions in the
976 ingress pipeline should use next to jump into the specific
977 table of egress pipeline only if it is certain that the
978 packets are local and not tunnelled and wants to skip cer‐
979 tain stages in the packet processing.
980 field = constant;
982 Sets data or metadata field field to constant value con‐
983 stant, e.g. outport = "vif0"; to set the logical output
984 port. To set only a subset of bits in a field, specify a
985 subfield for field or a masked constant, e.g. one may use
986 vlan.pcp[2] = 1; or vlan.pcp = 4/4; to set the most sigifi‐
987 cant bit of the VLAN PCP.
988 Assigning to a field with prerequisites implicitly adds
990 those prerequisites to match; thus, for example, a flow
991 that sets tcp.dst applies only to TCP flows, regardless of
992 whether its match mentions any TCP field.
993 Not all fields are modifiable (e.g. eth.type and ip.proto
995 are read-only), and not all modifiable fields may be par‐
996 tially modified (e.g. ip.ttl must assigned as a whole). The
997 outport field is modifiable in the ingress pipeline but not
998 in the egress pipeline.
999 ovn_field = constant;
1001 Sets OVN field ovn_field to constant value constant.
1002 OVN supports setting the values of certain fields which are
1004 not yet supported in OpenFlow to set or modify them.
1005 Below are the supported OVN fields:
1007 · icmp4.frag_mtu
1009 This field sets the low-order 16 bits of the ICMP4
1011 header field that is labelled "unused" in the ICMP
1012 specification as defined in the RFC 1191 with the
1013 value specified in constant.
1014 Eg. icmp4.frag_mtu = 1500;
1016 field1 = field2;
1018 Sets data or metadata field field1 to the value of data or
1019 metadata field field2, e.g. reg0 = ip4.src; copies ip4.src
1020 into reg0. To modify only a subset of a field’s bits, spec‐
1021 ify a subfield for field1 or field2 or both, e.g. vlan.pcp
1022 = reg0[0..2]; copies the least-significant bits of reg0
1023 into the VLAN PCP.
1024 field1 and field2 must be the same type, either both string
1026 or both integer fields. If they are both integer fields,
1027 they must have the same width.
1028 If field1 or field2 has prerequisites, they are added
1030 implicitly to match. It is possible to write an assignment
1031 with contradictory prerequisites, such as ip4.src =
1032 ip6.src[0..31];, but the contradiction means that a logical
1033 flow with such an assignment will never be matched.
1034 field1 <-> field2;
1036 Similar to field1 = field2; except that the two values are
1037 exchanged instead of copied. Both field1 and field2 must
1038 modifiable.
1039 ip.ttl--;
1041 Decrements the IPv4 or IPv6 TTL. If this would make the TTL
1042 zero or negative, then processing of the packet halts; no
1043 further actions are processed. (To properly handle such
1044 cases, a higher-priority flow should match on ip.ttl == {0,
1045 1};.)
1046 Prerequisite: ip
1048 ct_next;
1050 Apply connection tracking to the flow, initializing
1051 ct_state for matching in later tables. Automatically moves
1052 on to the next table, as if followed by next.
1053 As a side effect, IP fragments will be reassembled for
1055 matching. If a fragmented packet is output, then it will be
1056 sent with any overlapping fragments squashed. The connec‐
1057 tion tracking state is scoped by the logical port when the
1058 action is used in a flow for a logical switch, so overlap‐
1059 ping addresses may be used. To allow traffic related to the
1060 matched flow, execute ct_commit . Connection tracking state
1061 is scoped by the logical topology when the action is used
1062 in a flow for a router.
1063 It is possible to have actions follow ct_next, but they
1065 will not have access to any of its side-effects and is not
1066 generally useful.
1067 ct_commit;
1069 ct_commit(ct_mark=value[/mask]);
1070 ct_commit(ct_label=value[/mask]);
1071 ct_commit(ct_mark=value[/mask], ct_label=value[/mask]);
1072 Commit the flow to the connection tracking entry associated
1073 with it by a previous call to ct_next. When
1074 ct_mark=value[/mask] and/or ct_label=value[/mask] are sup‐
1075 plied, ct_mark and/or ct_label will be set to the values
1076 indicated by value[/mask] on the connection tracking entry.
1077 ct_mark is a 32-bit field. ct_label is a 128-bit field. The
1078 value[/mask] should be specified in hex string if more than
1079 64bits are to be used.
1080 Note that if you want processing to continue in the next
1082 table, you must execute the next action after ct_commit.
1083 You may also leave out next which will commit connection
1084 tracking state, and then drop the packet. This could be
1085 useful for setting ct_mark on a connection tracking entry
1086 before dropping a packet, for example.
1087 ct_dnat;
1089 ct_dnat(IP);
1090 ct_dnat sends the packet through the DNAT zone in connec‐
1091 tion tracking table to unDNAT any packet that was DNATed in
1092 the opposite direction. The packet is then automatically
1093 sent to to the next tables as if followed by next; action.
1094 The next tables will see the changes in the packet caused
1095 by the connection tracker.
1096 ct_dnat(IP) sends the packet through the DNAT zone to
1098 change the destination IP address of the packet to the one
1099 provided inside the parentheses and commits the connection.
1100 The packet is then automatically sent to the next tables as
1101 if followed by next; action. The next tables will see the
1102 changes in the packet caused by the connection tracker.
1103 ct_snat;
1105 ct_snat(IP);
1106 ct_snat sends the packet through the SNAT zone to unSNAT
1107 any packet that was SNATed in the opposite direction. The
1108 packet is automatically sent to the next tables as if fol‐
1109 lowed by the next; action. The next tables will see the
1110 changes in the packet caused by the connection tracker.
1111 ct_snat(IP) sends the packet through the SNAT zone to
1113 change the source IP address of the packet to the one pro‐
1114 vided inside the parenthesis and commits the connection.
1115 The packet is then automatically sent to the next tables as
1116 if followed by next; action. The next tables will see the
1117 changes in the packet caused by the connection tracker.
1118 ct_clear;
1120 Clears connection tracking state.
1121 clone { action; ... };
1123 Makes a copy of the packet being processed and executes
1124 each action on the copy. Actions following the clone
1125 action, if any, apply to the original, unmodified packet.
1126 This can be used as a way to ``save and restore’’ the
1127 packet around a set of actions that may modify it and
1128 should not persist.
1129 arp { action; ... };
1131 Temporarily replaces the IPv4 packet being processed by an
1132 ARP packet and executes each nested action on the ARP
1133 packet. Actions following the arp action, if any, apply to
1134 the original, unmodified packet.
1135 The ARP packet that this action operates on is initialized
1137 based on the IPv4 packet being processed, as follows. These
1138 are default values that the nested actions will probably
1139 want to change:
1140 · eth.src unchanged
1142 · eth.dst unchanged
1144 · eth.type = 0x0806
1146 · arp.op = 1 (ARP request)
1148 · arp.sha copied from eth.src
1150 · arp.spa copied from ip4.src
1152 · arp.tha = 00:00:00:00:00:00
1154 · arp.tpa copied from ip4.dst
1156 The ARP packet has the same VLAN header, if any, as the IP
1158 packet it replaces.
1159 Prerequisite: ip4
1161 get_arp(P, A);
1163 Parameters: logical port string field P, 32-bit IP address
1164 field A.
1165 Looks up A in P’s mac binding table. If an entry is found,
1167 stores its Ethernet address in eth.dst, otherwise stores
1168 00:00:00:00:00:00 in eth.dst.
1169 Example: get_arp(outport, ip4.dst);
1171 put_arp(P, A, E);
1173 Parameters: logical port string field P, 32-bit IP address
1174 field A, 48-bit Ethernet address field E.
1175 Adds or updates the entry for IP address A in logical port
1177 P’s mac binding table, setting its Ethernet address to E.
1178 Example: put_arp(inport, arp.spa, arp.sha);
1180 R = lookup_arp(P, A, M);
1182 Parameters: logical port string field P, 32-bit IP address
1183 field A, 48-bit MAC address field M.
1184 Result: stored to a 1-bit subfield R.
1186 Looks up A and M in P’s mac binding table. If an entry is
1188 found, stores 1 in the 1-bit subfield R, else 0.
1189 Example: reg0[0] = lookup_arp(inport, arp.spa, arp.sha);
1191 nd_ns { action; ... };
1193 Temporarily replaces the IPv6 packet being processed by an
1194 IPv6 Neighbor Solicitation packet and executes each nested
1195 action on the IPv6 NS packet. Actions following the nd_ns
1196 action, if any, apply to the original, unmodified packet.
1197 The IPv6 NS packet that this action operates on is initial‐
1199 ized based on the IPv6 packet being processed, as follows.
1200 These are default values that the nested actions will prob‐
1201 ably want to change:
1202 · eth.src unchanged
1204 · eth.dst set to IPv6 multicast MAC address
1206 · eth.type = 0x86dd
1208 · ip6.src copied from ip6.src
1210 · ip6.dst set to IPv6 Solicited-Node multicast address
1212 · icmp6.type = 135 (Neighbor Solicitation)
1214 · nd.target copied from ip6.dst
1216 The IPv6 NS packet has the same VLAN header, if any, as the
1218 IP packet it replaces.
1219 Prerequisite: ip6
1221 nd_na { action; ... };
1223 Temporarily replaces the IPv6 neighbor solicitation packet
1224 being processed by an IPv6 neighbor advertisement (NA)
1225 packet and executes each nested action on the NA packet.
1226 Actions following the nd_na action, if any, apply to the
1227 original, unmodified packet.
1228 The NA packet that this action operates on is initialized
1230 based on the IPv6 packet being processed, as follows. These
1231 are default values that the nested actions will probably
1232 want to change:
1233 · eth.dst exchanged with eth.src
1235 · eth.type = 0x86dd
1237 · ip6.dst copied from ip6.src
1239 · ip6.src copied from nd.target
1241 · icmp6.type = 136 (Neighbor Advertisement)
1243 · nd.target unchanged
1245 · nd.sll = 00:00:00:00:00:00
1247 · nd.tll copied from eth.dst
1249 The ND packet has the same VLAN header, if any, as the IPv6
1251 packet it replaces.
1252 Prerequisite: nd_ns
1254 nd_na_router { action; ... };
1256 Temporarily replaces the IPv6 neighbor solicitation packet
1257 being processed by an IPv6 neighbor advertisement (NA)
1258 packet, sets ND_NSO_ROUTER in the RSO flags and executes
1259 each nested action on the NA packet. Actions following the
1260 nd_na_router action, if any, apply to the original, unmodi‐
1261 fied packet.
1262 The NA packet that this action operates on is initialized
1264 based on the IPv6 packet being processed, as follows. These
1265 are default values that the nested actions will probably
1266 want to change:
1267 · eth.dst exchanged with eth.src
1269 · eth.type = 0x86dd
1271 · ip6.dst copied from ip6.src
1273 · ip6.src copied from nd.target
1275 · icmp6.type = 136 (Neighbor Advertisement)
1277 · nd.target unchanged
1279 · nd.sll = 00:00:00:00:00:00
1281 · nd.tll copied from eth.dst
1283 The ND packet has the same VLAN header, if any, as the IPv6
1285 packet it replaces.
1286 Prerequisite: nd_ns
1288 get_nd(P, A);
1290 Parameters: logical port string field P, 128-bit IPv6
1291 address field A.
1292 Looks up A in P’s mac binding table. If an entry is found,
1294 stores its Ethernet address in eth.dst, otherwise stores
1295 00:00:00:00:00:00 in eth.dst.
1296 Example: get_nd(outport, ip6.dst);
1298 put_nd(P, A, E);
1300 Parameters: logical port string field P, 128-bit IPv6
1301 address field A, 48-bit Ethernet address field E.
1302 Adds or updates the entry for IPv6 address A in logical
1304 port P’s mac binding table, setting its Ethernet address to
1305 E.
1306 Example: put_nd(inport, nd.target, nd.tll);
1308 R = lookup_nd(P, A, M);
1310 Parameters: logical port string field P, 128-bit IP address
1311 field A, 48-bit MAC address field M.
1312 Result: stored to a 1-bit subfield R.
1314 Looks up A and M in P’s mac binding table. If an entry is
1316 found, stores 1 in the 1-bit subfield R, else 0.
1317 Example: reg0[0] = lookup_nd(inport, ip6.src, eth.src);
1319 R = put_dhcp_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1321 Parameters: one or more DHCP option/value pairs, which must
1322 include an offerip option (with code 0).
1323 Result: stored to a 1-bit subfield R.
1325 Valid only in the ingress pipeline.
1327 When this action is applied to a DHCP request packet
1329 (DHCPDISCOVER or DHCPREQUEST), it changes the packet into a
1330 DHCP reply (DHCPOFFER or DHCPACK, respectively), replaces
1331 the options by those specified as parameters, and stores 1
1332 in R.
1333 When this action is applied to a non-DHCP packet or a DHCP
1335 packet that is not DHCPDISCOVER or DHCPREQUEST, it leaves
1336 the packet unchanged and stores 0 in R.
1337 The contents of the DHCP_Option table control the DHCP
1339 option names and values that this action supports.
1340 Example: reg0[0] = put_dhcp_opts(offerip = 10.0.0.2, router
1342 = 10.0.0.1, netmask = 255.255.255.0, dns_server = {8.8.8.8,
1343 7.7.7.7});
1344 R = put_dhcpv6_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1346 Parameters: one or more DHCPv6 option/value pairs.
1347 Result: stored to a 1-bit subfield R.
1349 Valid only in the ingress pipeline.
1351 When this action is applied to a DHCPv6 request packet, it
1353 changes the packet into a DHCPv6 reply, replaces the
1354 options by those specified as parameters, and stores 1 in
1355 R.
1356 When this action is applied to a non-DHCPv6 packet or an
1358 invalid DHCPv6 request packet , it leaves the packet
1359 unchanged and stores 0 in R.
1360 The contents of the DHCPv6_Options table control the DHCPv6
1362 option names and values that this action supports.
1363 Example: reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4,
1365 server_id = 00:00:00:00:10:02,
1366 dns_server={ae70::1,ae70::2});
1367 set_queue(queue_number);
1369 Parameters: Queue number queue_number, in the range 0 to
1370 61440.
1371 This is a logical equivalent of the OpenFlow set_queue
1373 action. It affects packets that egress a hypervisor through
1374 a physical interface. For nonzero queue_number, it config‐
1375 ures packet queuing to match the settings configured for
1376 the Port_Binding with options:qdisc_queue_id matching
1377 queue_number. When queue_number is zero, it resets queuing
1378 to the default strategy.
1379 Example: set_queue(10);
1381 ct_lb;
1383 ct_lb(ip[:port]...);
1384 With one or more arguments, ct_lb commits the packet to the
1385 connection tracking table and DNATs the packet’s destina‐
1386 tion IP address (and port) to the IP address or addresses
1387 (and optional ports) specified in the string. If multiple
1388 comma-separated IP addresses are specified, each is given
1389 equal weight for picking the DNAT address. Processing auto‐
1390 matically moves on to the next table, as if next; were
1391 specified, and later tables act on the packet as modified
1392 by the connection tracker. Connection tracking state is
1393 scoped by the logical port when the action is used in a
1394 flow for a logical switch, so overlapping addresses may be
1395 used. Connection tracking state is scoped by the logical
1396 topology when the action is used in a flow for a router.
1397 Without arguments, ct_lb sends the packet to the connection
1399 tracking table to NAT the packets. If the packet is part of
1400 an established connection that was previously committed to
1401 the connection tracker via ct_lb(...), it will automati‐
1402 cally get DNATed to the same IP address as the first packet
1403 in that connection.
1404 R = dns_lookup();
1406 Parameters: No parameters.
1407 Result: stored to a 1-bit subfield R.
1409 Valid only in the ingress pipeline.
1411 When this action is applied to a valid DNS request (a UDP
1413 packet typically directed to port 53), it attempts to
1414 resolve the query using the contents of the DNS table. If
1415 it is successful, it changes the packet into a DNS reply
1416 and stores 1 in R. If the action is applied to a non-DNS
1417 packet, an invalid DNS request packet, or a valid DNS
1418 request for which the DNS table does not supply an answer,
1419 it leaves the packet unchanged and stores 0 in R.
1420 Regardless of success, the action does not make any of the
1422 changes to the flow that are necessary to direct the packet
1423 back to the requester. The logical pipeline can implement
1424 this behavior with matches and actions in later tables.
1425 Example: reg0[3] = dns_lookup();
1427 Prerequisite: udp
1429 R = put_nd_ra_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1431 Parameters: The following IPv6 ND Router Advertisement
1432 option/value pairs as defined in RFC 4861.
1433 · addr_mode
1435 Mandatory parameter which specifies the address mode
1437 flag to be set in the RA flag options field. The
1438 value of this option is a string and the following
1439 values can be defined - "slaac", "dhcpv6_stateful"
1440 and "dhcpv6_stateless".
1441 · slla
1443 Mandatory parameter which specifies the link-layer
1445 address of the interface from which the Router
1446 Advertisement is sent.
1447 · mtu
1449 Optional parameter which specifies the MTU.
1451 · prefix
1453 Optional parameter which should be specified if the
1455 addr_mode is "slaac" or "dhcpv6_stateless". The
1456 value should be an IPv6 prefix which will be used
1457 for stateless IPv6 address configuration. This
1458 option can be defined multiple times.
1459 Result: stored to a 1-bit subfield R.
1461 Valid only in the ingress pipeline.
1463 When this action is applied to an IPv6 Router solicitation
1465 request packet, it changes the packet into an IPv6 Router
1466 Advertisement reply and adds the options specified in the
1467 parameters, and stores 1 in R.
1468 When this action is applied to a non-IPv6 Router solicita‐
1470 tion packet or an invalid IPv6 request packet , it leaves
1471 the packet unchanged and stores 0 in R.
1472 Example: reg0[3] = put_nd_ra_opts(addr_mode = "slaac", slla
1474 = 00:00:00:00:10:02, prefix = aef0::/64, mtu = 1450);
1475 set_meter(rate);
1477 set_meter(rate, burst);
1478 Parameters: rate limit int field rate in kbps, burst rate
1479 limits int field burst in kbps.
1480 This action sets the rate limit for a flow.
1482 Example: set_meter(100, 1000);
1484 R = check_pkt_larger(L)
1486 Parameters: packet length L to check for in bytes.
1487 Result: stored to a 1-bit subfield R.
1489 This is a logical equivalent of the OpenFlow
1491 check_pkt_larger action. If the packet is larger than the
1492 length specified in L, it stores 1 in the subfield R.
1493 Example: reg0[6] = check_pkt_larger(1000);
1495 log(key=value, ...);
1497 Causes ovn-controller to log the packet on the chassis
1498 that processes it. Packet logging currently uses the same
1499 logging mechanism as other Open vSwitch and OVN messages,
1500 which means that whether and where log messages appear
1501 depends on the local logging configuration that can be
1502 configured with ovs-appctl, etc.
1503 The log action takes zero or more of the following key-
1505 value pair arguments that control what is logged:
1506 name=string
1508 An optional name for the ACL. The string is cur‐
1509 rently limited to 64 bytes.
1510 severity=level
1512 Indicates the severity of the event. The level is
1513 one of following (from more to less serious):
1514 alert, warning, notice, info, or debug. If a
1515 severity is not provided, the default is info.
1516 verdict=value
1518 The verdict for packets matching the flow. The
1519 value must be one of allow, deny, or reject.
1520 meter=string
1522 An optional rate-limiting meter to be applied to
1523 the logs. The string should reference a name entry
1524 from the Meter table. The only meter action that
1525 is appriopriate is drop.
1526 fwd_group(P);
1528 Parameters: liveness, list of child ports P.
1529 It load balances traffic to one or more child ports in a
1531 logical switch. ovn-controller translates the fwd_group
1532 into openflow group with one bucket for each child port.
1533 If liveness is set to true, it also integrates the bucket
1534 selection with BFD status on the tunnel interface corre‐
1535 sponding to child port.
1536 Example: fwd_group(liveness=true, childports=p1,p2
1538 icmp4 { action; ... };
1540 icmp4_error { action; ... };
1541 Temporarily replaces the IPv4 packet being processed by an
1542 ICMPv4 packet and executes each nested action on the ICMPv4
1543 packet. Actions following these actions, if any, apply to
1544 the original, unmodified packet.
1545 The ICMPv4 packet that these actions operates on is ini‐
1547 tialized based on the IPv4 packet being processed, as fol‐
1548 lows. These are default values that the nested actions will
1549 probably want to change. Ethernet and IPv4 fields not
1550 listed here are not changed:
1551 · ip.proto = 1 (ICMPv4)
1553 · ip.frag = 0 (not a fragment)
1555 · ip.ttl = 255
1557 · icmp4.type = 3 (destination unreachable)
1559 · icmp4.code = 1 (host unreachable)
1561 icmp4_error action is expected to be used to generate an
1563 ICMPv4 packet in response to an error in original IP
1564 packet. When this action generates the ICMPv4 packet, it
1565 also copies the original IP datagram following the ICMPv4
1566 header as per RFC 1122: 3.2.2.
1567 Prerequisite: ip4
1569 icmp6 { action; ... };
1571 Temporarily replaces the IPv6 packet being processed by an
1572 ICMPv6 packet and executes each nested action on the ICMPv6
1573 packet. Actions following the icmp6 action, if any, apply
1574 to the original, unmodified packet.
1575 The ICMPv6 packet that this action operates on is initial‐
1577 ized based on the IPv6 packet being processed, as follows.
1578 These are default values that the nested actions will prob‐
1579 ably want to change. Ethernet and IPv6 fields not listed
1580 here are not changed:
1581 · ip.proto = 58 (ICMPv6)
1583 · ip.ttl = 255
1585 · icmp6.type = 1 (destination unreachable)
1587 · icmp6.code = 1 (administratively prohibited)
1589 Prerequisite: ip6
1591 tcp_reset;
1593 This action transforms the current TCP packet according to
1594 the following pseudocode:
1595 if (tcp.ack) {
1597 tcp.seq = tcp.ack;
1598 } else {
1599 tcp.ack = tcp.seq + length(tcp.payload);
1600 tcp.seq = 0;
1601 }
1602 tcp.flags = RST;
1603 Then, the action drops all TCP options and payload data,
1605 and updates the TCP checksum. IP ttl is set to 255.
1606 Prerequisite: tcp
1608 trigger_event;
1610 This action is used to allow ovs-vswitchd to report CMS
1611 related events writing them in Controller_Event table. It
1612 is possible to associate a meter to a each event in order
1613 to not overload pinctrl thread under heavy load; each meter
1614 is identified though a defined naming convention. Supported
1615 events:
1616 · empty_lb_backends. This event is raised if a
1618 received packet is destined for a load balancer VIP
1619 that has no configured backend destinations. For
1620 this event, the event info includes the load bal‐
1621 ancer VIP, the load balancer UUID, and the transport
1622 protocol. Associated meter: event-elb
1623 igmp;
1625 This action sends the packet to ovn-controller for multi‐
1626 cast snooping.
1627 Prerequisite: igmp
1629 bind_vport(V, P);
1631 Parameters: logical port string field V of type virtual,
1632 logical port string field P.
1633 Binds the virtual logical port V and sets the chassis col‐
1635 umn and virtual_parent of the table Port_Binding. vir‐
1636 tual_parent is set to P.
1637 handle_svc_check(P);
1639 Parameters: logical port string field P.
1640 Handles the service monitor reply received from the VIF of
1642 the logical port P. ovn-controller periodically sends out
1643 the service monitor packets for the services configured in
1644 the Service_Monitor table and this action updates the sta‐
1645 tus of those services.
1646 Example: handle_svc_check(inport);
1648 handle_dhcpv6_reply;
1650 Handle DHCPv6 prefix delegation advertisements/replies from
1651 a IPv6 delegation server. ovn-controller will add an entry
1652 ipv6_ra_pd_list in the options table for each prefix
1653 received from the delegation server
1654 R = select(N1[=W1], N2[=W2], ...);
1656 Parameters: Integer N1, N2..., with optional weight W1, W2,
1657 ...
1658 Result: stored to a logical field or subfield R.
1660 Select from a list of integers N1, N2..., each within the
1662 range 0 ~ 65535, and store the selected one in the field R.
1663 There must be 2 or more integers listed, each with an
1664 optional weight, which is an integer within the range 1 ~
1665 65535. If weight is not specified, it defaults to 100. The
1666 selection method is based on the 5-tuple hash of packet
1667 header.
1668 Processing automatically moves on to the next table, as if
1670 next; were specified. The select action must be put as the
1671 last action of the logical flow when there are multiple
1672 actions (actions put after select will not take effect).
1673 Example: reg8[16..31] = select(1=20, 2=30, 3=50);
1675 handle_dhcpv6_reply;
1677 This action is used to parse DHCPv6 replies from IPv6 Dele‐
1678 gation Router and managed IPv6 Prefix delegation state
1679 machine
1680 external_ids : stage-name: optional string
1682 Human-readable name for this flow’s stage in the pipeline.
1683 external_ids : stage-hint: optional string, containing an uuid
1685 UUID of a OVN_Northbound record that caused this logical flow to
1686 be created. Currently used only for attribute of logical flows
1687 to northbound ACL records.
1688 external_ids : source: optional string
1690 Source file and line number of the code that added this flow to
1691 the pipeline.
1692 Common Columns:
1694 The overall purpose of these columns is described under Common Columns
1696 at the beginning of this document.
1697 external_ids: map of string-string pairs
1699
1701 The rows in this table define multicast groups of logical ports. Multi‐
1702 cast groups allow a single packet transmitted over a tunnel to a hyper‐
1703 visor to be delivered to multiple VMs on that hypervisor, which uses
1704 bandwidth more efficiently.
1705 Each row in this table defines a logical multicast group numbered tun‐
1707 nel_key within datapath, whose logical ports are listed in the ports
1708 column.
1709 Summary:
1711 datapath Datapath_Binding
1712 tunnel_key integer, in range 32,768 to 65,535
1713 name string
1714 ports set of 1 or more weak reference to
1715 Port_Bindings
1716 Details:
1718 datapath: Datapath_Binding
1719 The logical datapath in which the multicast group resides.
1720 tunnel_key: integer, in range 32,768 to 65,535
1722 The value used to designate this logical egress port in tunnel
1723 encapsulations. An index forces the key to be unique within the
1724 datapath. The unusual range ensures that multicast group IDs do
1725 not overlap with logical port IDs.
1726 name: string
1728 The logical multicast group’s name. An index forces the name to
1729 be unique within the datapath. Logical flows in the ingress
1730 pipeline may output to the group just as for individual logical
1731 ports, by assigning the group’s name to outport and executing an
1732 output action.
1733 Multicast group names and logical port names share a single
1735 namespace and thus should not overlap (but the database schema
1736 cannot enforce this). To try to avoid conflicts, ovn-northd uses
1737 names that begin with _MC_.
1738 ports: set of 1 or more weak reference to Port_Bindings
1740 The logical ports included in the multicast group. All of these
1741 ports must be in the datapath logical datapath (but the database
1742 schema cannot enforce this).
1743
1745 Each row in this table represents a meter that can be used for QoS or
1746 rate-limiting.
1747 Summary:
1749 name string (must be unique within table)
1750 unit string, either kbps or pktps
1751 bands set of 1 or more Meter_Bands
1752 Details:
1754 name: string (must be unique within table)
1755 A name for this meter.
1756 Names that begin with "__" (two underscores) are reserved for
1758 OVN internal use and should not be added manually.
1759 unit: string, either kbps or pktps
1761 The unit for rate and burst_rate parameters in the bands entry.
1762 kbps specifies kilobits per second, and pktps specifies packets
1763 per second.
1764 bands: set of 1 or more Meter_Bands
1766 The bands associated with this meter. Each band specifies a rate
1767 above which the band is to take the action action. If multiple
1768 bands’ rates are exceeded, then the band with the highest rate
1769 among the exceeded bands is selected.
1770
1772 Each row in this table represents a meter band which specifies the rate
1773 above which the configured action should be applied. These bands are
1774 referenced by the bands column in the Meter table.
1775 Summary:
1777 action string, must be drop
1778 rate integer, in range 1 to 4,294,967,295
1779 burst_size integer, in range 0 to 4,294,967,295
1780 Details:
1782 action: string, must be drop
1783 The action to execute when this band matches. The only supported
1784 action is drop.
1785 rate: integer, in range 1 to 4,294,967,295
1787 The rate limit for this band, in kilobits per second or bits per
1788 second, depending on whether the parent Meter entry’s unit col‐
1789 umn specified kbps or pktps.
1790 burst_size: integer, in range 0 to 4,294,967,295
1792 The maximum burst allowed for the band in kilobits or packets,
1793 depending on whether kbps or pktps was selected in the parent
1794 Meter entry’s unit column. If the size is zero, the switch is
1795 free to select some reasonable value depending on its configura‐
1796 tion.
1797
1799 Each row in this table represents a logical datapath, which implements
1800 a logical pipeline among the ports in the Port_Binding table associated
1801 with it. In practice, the pipeline in a given logical datapath imple‐
1802 ments either a logical switch or a logical router.
1803 The main purpose of a row in this table is provide a physical binding
1805 for a logical datapath. A logical datapath does not have a physical
1806 location, so its physical binding information is limited: just tun‐
1807 nel_key. The rest of the data in this table does not affect packet for‐
1808 warding.
1809 Summary:
1811 tunnel_key integer, in range 1 to 16,777,215 (must
1812 be unique within table)
1813 OVN_Northbound Relationship:
1814 external_ids : logical-switch
1815 optional string, containing an uuid
1816 external_ids : logical-router
1817 optional string, containing an uuid
1818 external_ids : interconn-ts
1819 optional string
1820 Naming:
1821 external_ids : name optional string
1822 external_ids : name2 optional string
1823 Common Columns:
1824 external_ids map of string-string pairs
1825 Details:
1827 tunnel_key: integer, in range 1 to 16,777,215 (must be unique within
1828 table)
1829 The tunnel key value to which the logical datapath is bound. The
1830 Tunnel Encapsulation section in ovn-architecture(7) describes
1831 how tunnel keys are constructed for each supported encapsula‐
1832 tion.
1833 OVN_Northbound Relationship:
1835 Each row in Datapath_Binding is associated with some logical datapath.
1837 ovn-northd uses these keys to track the association of a logical data‐
1838 path with concepts in the OVN_Northbound database.
1839 external_ids : logical-switch: optional string, containing an uuid
1841 For a logical datapath that represents a logical switch,
1842 ovn-northd stores in this key the UUID of the corresponding Log‐
1843 ical_Switch row in the OVN_Northbound database.
1844 external_ids : logical-router: optional string, containing an uuid
1846 For a logical datapath that represents a logical router,
1847 ovn-northd stores in this key the UUID of the corresponding Log‐
1848 ical_Router row in the OVN_Northbound database.
1849 external_ids : interconn-ts: optional string
1851 For a logical datapath that represents a logical switch that
1852 represents a transit switch for interconnection, ovn-northd
1853 stores in this key the value of the same interconn-ts key of the
1854 external_ids column of the corresponding Logical_Switch row in
1855 the OVN_Northbound database.
1856 Naming:
1858 ovn-northd copies these from the name fields in the OVN_Northbound
1860 database, either from name and external_ids:neutron:router_name in the
1861 Logical_Router table or from name and external_ids:neutron:network_name
1862 in the Logical_Switch table.
1863 external_ids : name: optional string
1865 A name for the logical datapath.
1866 external_ids : name2: optional string
1868 Another name for the logical datapath.
1869 Common Columns:
1871 The overall purpose of these columns is described under Common Columns
1873 at the beginning of this document.
1874 external_ids: map of string-string pairs
1876
1878 Each row in this table binds a logical port to a realization. For most
1879 logical ports, this means binding to some physical location, for exam‐
1880 ple by binding a logical port to a VIF that belongs to a VM running on
1881 a particular hypervisor. Other logical ports, such as logical patch
1882 ports, can be realized without a specific physical location, but their
1883 bindings are still expressed through rows in this table.
1884 For every Logical_Switch_Port record in OVN_Northbound database,
1886 ovn-northd creates a record in this table. ovn-northd populates and
1887 maintains every column except the chassis column, which it leaves empty
1888 in new records.
1889 ovn-controller/ovn-controller-vtep populates the chassis column for the
1891 records that identify the logical ports that are located on its hyper‐
1892 visor/gateway, which ovn-controller/ovn-controller-vtep in turn finds
1893 out by monitoring the local hypervisor’s Open_vSwitch database, which
1894 identifies logical ports via the conventions described in Integra‐
1895 tionGuide.rst. (The exceptions are for Port_Binding records with type
1896 of l3gateway, whose locations are identified by ovn-northd via the
1897 options:l3gateway-chassis column in this table. ovn-controller is still
1898 responsible to populate the chassis column.)
1899 When a chassis shuts down gracefully, it should clean up the chassis
1901 column that it previously had populated. (This is not critical because
1902 resources hosted on the chassis are equally unreachable regardless of
1903 whether their rows are present.) To handle the case where a VM is shut
1904 down abruptly on one chassis, then brought up again on a different one,
1905 ovn-controller/ovn-controller-vtep must overwrite the chassis column
1906 with new information.
1907 Summary:
1909 Core Features:
1910 datapath Datapath_Binding
1911 logical_port string (must be unique within table)
1912 encap optional weak reference to Encap
1913 chassis optional weak reference to Chassis
1914 gateway_chassis set of Gateway_Chassiss
1915 ha_chassis_group optional HA_Chassis_Group
1916 tunnel_key integer, in range 1 to 32,767
1917 mac set of strings
1918 type string
1919 Patch Options:
1920 options : peer optional string
1921 nat_addresses set of strings
1922 L3 Gateway Options:
1923 options : peer optional string
1924 options : l3gateway-chassis
1925 optional string
1926 options : nat-addresses optional string
1927 nat_addresses set of strings
1928 Localnet Options:
1929 options : network_name optional string
1930 tag optional integer, in range 1 to 4,095
1931 L2 Gateway Options:
1932 options : network_name optional string
1933 options : l2gateway-chassis
1934 optional string
1935 tag optional integer, in range 1 to 4,095
1936 VTEP Options:
1937 options : vtep-physical-switch
1938 optional string
1939 options : vtep-logical-switch
1940 optional string
1941 VMI (or VIF) Options:
1942 options : requested-chassis
1943 optional string
1944 options : qos_max_rate optional string
1945 options : qos_burst optional string
1946 options : qdisc_queue_id optional string, containing an integer,
1947 in range 1 to 61,440
1948 Chassis Redirect Options:
1949 options : distributed-port optional string
1950 options : redirect-chassis optional string
1951 Nested Containers:
1952 parent_port optional string
1953 tag optional integer, in range 1 to 4,095
1954 Virtual ports:
1955 virtual_parent optional string
1956 Naming:
1957 external_ids : name optional string
1958 Common Columns:
1959 external_ids map of string-string pairs
1960 Details:
1962 Core Features:
1963 datapath: Datapath_Binding
1965 The logical datapath to which the logical port belongs.
1966 logical_port: string (must be unique within table)
1968 A logical port, taken from name in the OVN_Northbound database’s
1969 Logical_Switch_Port table. OVN does not prescribe a particular
1970 format for the logical port ID.
1971 encap: optional weak reference to Encap
1973 Points to supported encapsulation configurations to transmit
1974 logical dataplane packets to this chassis. Each entry is a Encap
1975 record that describes the configuration.
1976 chassis: optional weak reference to Chassis
1978 The meaning of this column depends on the value of the type col‐
1979 umn. This is the meaning for each type
1980 (empty string)
1982 The physical location of the logical port. To success‐
1983 fully identify a chassis, this column must be a Chassis
1984 record. This is populated by ovn-controller.
1985 vtep The physical location of the hardware_vtep gateway. To
1987 successfully identify a chassis, this column must be a
1988 Chassis record. This is populated by ovn-controller-vtep.
1989 localnet
1991 Always empty. A localnet port is realized on every chas‐
1992 sis that has connectivity to the corresponding physical
1993 network.
1994 localport
1996 Always empty. A localport port is present on every chas‐
1997 sis.
1998 l3gateway
2000 The physical location of the L3 gateway. To successfully
2001 identify a chassis, this column must be a Chassis record.
2002 This is populated by ovn-controller based on the value of
2003 the options:l3gateway-chassis column in this table.
2004 l2gateway
2006 The physical location of this L2 gateway. To successfully
2007 identify a chassis, this column must be a Chassis record.
2008 This is populated by ovn-controller based on the value of
2009 the options:l2gateway-chassis column in this table.
2010 gateway_chassis: set of Gateway_Chassiss
2012 A list of Gateway_Chassis.
2013 This should only be populated for ports with type set to chas‐
2015 sisredirect. This column defines the list of chassis used as
2016 gateways where traffic will be redirected through.
2017 ha_chassis_group: optional HA_Chassis_Group
2019 This should only be populated for ports with type set to chas‐
2020 sisredirect. This column defines the HA chassis group with a
2021 list of HA chassis used as gateways where traffic will be redi‐
2022 rected through.
2023 tunnel_key: integer, in range 1 to 32,767
2025 A number that represents the logical port in the key (e.g. STT
2026 key or Geneve TLV) field carried within tunnel protocol packets.
2027 The tunnel ID must be unique within the scope of a logical data‐
2029 path.
2030 mac: set of strings
2032 The Ethernet address or addresses used as a source address on
2033 the logical port, each in the form xx:xx:xx:xx:xx:xx. The string
2034 unknown is also allowed to indicate that the logical port has an
2035 unknown set of (additional) source addresses.
2036 A VM interface would ordinarily have a single Ethernet address.
2038 A gateway port might initially only have unknown, and then add
2039 MAC addresses to the set as it learns new source addresses.
2040 type: string
2042 A type for this logical port. Logical ports can be used to model
2043 other types of connectivity into an OVN logical switch. The fol‐
2044 lowing types are defined:
2045 (empty string)
2047 VM (or VIF) interface.
2048 patch One of a pair of logical ports that act as if connected
2050 by a patch cable. Useful for connecting two logical data‐
2051 paths, e.g. to connect a logical router to a logical
2052 switch or to another logical router.
2053 l3gateway
2055 One of a pair of logical ports that act as if connected
2056 by a patch cable across multiple chassis. Useful for con‐
2057 necting a logical switch with a Gateway router (which is
2058 only resident on a particular chassis).
2059 localnet
2061 A connection to a locally accessible network from each
2062 ovn-controller instance. A logical switch can only have a
2063 single localnet port attached. This is used to model
2064 direct connectivity to an existing network.
2065 localport
2067 A connection to a local VIF. Traffic that arrives on a
2068 localport is never forwarded over a tunnel to another
2069 chassis. These ports are present on every chassis and
2070 have the same address in all of them. This is used to
2071 model connectivity to local services that run on every
2072 hypervisor.
2073 l2gateway
2075 An L2 connection to a physical network. The chassis this
2076 Port_Binding is bound to will serve as an L2 gateway to
2077 the network named by options:network_name.
2078 vtep A port to a logical switch on a VTEP gateway chassis. In
2080 order to get this port correctly recognized by the OVN
2081 controller, the options:vtep-physical-switch and
2082 options:vtep-logical-switch must also be defined.
2083 chassisredirect
2085 A logical port that represents a particular instance,
2086 bound to a specific chassis, of an otherwise distributed
2087 parent port (e.g. of type patch). A chassisredirect port
2088 should never be used as an inport. When an ingress pipe‐
2089 line sets the outport, it may set the value to a logical
2090 port of type chassisredirect. This will cause the packet
2091 to be directed to a specific chassis to carry out the
2092 egress pipeline. At the beginning of the egress pipeline,
2093 the outport will be reset to the value of the distributed
2094 port.
2095 virtual
2097 Represents a logical port with an virtual ip. This vir‐
2098 tual ip can be configured on a logical port (which is
2099 refered as virtual parent).
2100 Patch Options:
2102 These options apply to logical ports with type of patch.
2104 options : peer: optional string
2106 The logical_port in the Port_Binding record for the other side
2107 of the patch. The named logical_port must specify this logi‐
2108 cal_port in its own peer option. That is, the two patch logical
2109 ports must have reversed logical_port and peer values.
2110 nat_addresses: set of strings
2112 MAC address followed by a list of SNAT and DNAT external IP
2113 addresses, followed by is_chassis_resident("lport"), where lport
2114 is the name of a logical port on the same chassis where the cor‐
2115 responding NAT rules are applied. This is used to send gratu‐
2116 itous ARPs for SNAT and DNAT external IP addresses via localnet,
2117 from the chassis where lport resides. Example: 80:fa:5b:06:72:b7
2118 158.36.44.22 158.36.44.24 is_chassis_resident("foo1"). This
2119 would result in generation of gratuitous ARPs for IP addresses
2120 158.36.44.22 and 158.36.44.24 with a MAC address of
2121 80:fa:5b:06:72:b7 from the chassis where the logical port "foo1"
2122 resides.
2123 L3 Gateway Options:
2125 These options apply to logical ports with type of l3gateway.
2127 options : peer: optional string
2129 The logical_port in the Port_Binding record for the other side
2130 of the ’l3gateway’ port. The named logical_port must specify
2131 this logical_port in its own peer option. That is, the two
2132 ’l3gateway’ logical ports must have reversed logical_port and
2133 peer values.
2134 options : l3gateway-chassis: optional string
2136 The chassis in which the port resides.
2137 options : nat-addresses: optional string
2139 MAC address of the l3gateway port followed by a list of SNAT and
2140 DNAT external IP addresses. This is used to send gratuitous ARPs
2141 for SNAT and DNAT external IP addresses via localnet. Example:
2142 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
2143 in generation of gratuitous ARPs for IP addresses 158.36.44.22
2144 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
2145 is used in OVS versions prior to 2.8.
2146 nat_addresses: set of strings
2148 MAC address of the l3gateway port followed by a list of SNAT and
2149 DNAT external IP addresses. This is used to send gratuitous ARPs
2150 for SNAT and DNAT external IP addresses via localnet. Example:
2151 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
2152 in generation of gratuitous ARPs for IP addresses 158.36.44.22
2153 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
2154 is used in OVS version 2.8 and later versions.
2155 Localnet Options:
2157 These options apply to logical ports with type of localnet.
2159 options : network_name: optional string
2161 Required. ovn-controller uses the configuration entry
2162 ovn-bridge-mappings to determine how to connect to this network.
2163 ovn-bridge-mappings is a list of network names mapped to a local
2164 OVS bridge that provides access to that network. An example of
2165 configuring ovn-bridge-mappings would be: .IP
2166 $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
2167 When a logical switch has a localnet port attached, every chas‐
2169 sis that may have a local vif attached to that logical switch
2170 must have a bridge mapping configured to reach that localnet.
2171 Traffic that arrives on a localnet port is never forwarded over
2172 a tunnel to another chassis.
2173 tag: optional integer, in range 1 to 4,095
2175 If set, indicates that the port represents a connection to a
2176 specific VLAN on a locally accessible network. The VLAN ID is
2177 used to match incoming traffic and is also added to outgoing
2178 traffic.
2179 L2 Gateway Options:
2181 These options apply to logical ports with type of l2gateway.
2183 options : network_name: optional string
2185 Required. ovn-controller uses the configuration entry
2186 ovn-bridge-mappings to determine how to connect to this network.
2187 ovn-bridge-mappings is a list of network names mapped to a local
2188 OVS bridge that provides access to that network. An example of
2189 configuring ovn-bridge-mappings would be: .IP
2190 $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
2191 When a logical switch has a l2gateway port attached, the chassis
2193 that the l2gateway port is bound to must have a bridge mapping
2194 configured to reach the network identified by network_name.
2195 options : l2gateway-chassis: optional string
2197 Required. The chassis in which the port resides.
2198 tag: optional integer, in range 1 to 4,095
2200 If set, indicates that the gateway is connected to a specific
2201 VLAN on the physical network. The VLAN ID is used to match
2202 incoming traffic and is also added to outgoing traffic.
2203 VTEP Options:
2205 These options apply to logical ports with type of vtep.
2207 options : vtep-physical-switch: optional string
2209 Required. The name of the VTEP gateway.
2210 options : vtep-logical-switch: optional string
2212 Required. A logical switch name connected by the VTEP gateway.
2213 Must be set when type is vtep.
2214 VMI (or VIF) Options:
2216 These options apply to logical ports with type having (empty string)
2218 options : requested-chassis: optional string
2220 If set, identifies a specific chassis (by name or hostname) that
2221 is allowed to bind this port. Using this option will prevent
2222 thrashing between two chassis trying to bind the same port dur‐
2223 ing a live migration. It can also prevent similar thrashing due
2224 to a mis-configuration, if a port is accidentally created on
2225 more than one chassis.
2226 options : qos_max_rate: optional string
2228 If set, indicates the maximum rate for data sent from this
2229 interface, in bit/s. The traffic will be shaped according to
2230 this limit.
2231 options : qos_burst: optional string
2233 If set, indicates the maximum burst size for data sent from this
2234 interface, in bits.
2235 options : qdisc_queue_id: optional string, containing an integer, in
2237 range 1 to 61,440
2238 Indicates the queue number on the physical device. This is same
2239 as the queue_id used in OpenFlow in struct ofp_action_enqueue.
2240 Chassis Redirect Options:
2242 These options apply to logical ports with type of chassisredirect.
2244 options : distributed-port: optional string
2246 The name of the distributed port for which this chassisredirect
2247 port represents a particular instance.
2248 options : redirect-chassis: optional string
2250 The chassis that this chassisredirect port is bound to. This is
2251 taken from options:redirect-chassis in the OVN_Northbound data‐
2252 base’s Logical_Router_Port table.
2253 Nested Containers:
2255 These columns support containers nested within a VM. Specifically, they
2257 are used when type is empty and logical_port identifies the interface
2258 of a container spawned inside a VM. They are empty for containers or
2259 VMs that run directly on a hypervisor.
2260 parent_port: optional string
2262 This is taken from parent_name in the OVN_Northbound database’s
2263 Logical_Switch_Port table.
2264 tag: optional integer, in range 1 to 4,095
2266 Identifies the VLAN tag in the network traffic associated with
2267 that container’s network interface.
2268 This column is used for a different purpose when type is local‐
2270 net (see Localnet Options, above) or l2gateway (see L2 Gateway
2271 Options, above).
2272 Virtual ports:
2274 virtual_parent: optional string
2276 This column is set by ovn-controller with one of the value from
2277 the options:virtual-parents in the OVN_Northbound database’s
2278 Logical_Switch_Port table when the OVN action bind_vport is exe‐
2279 cuted. ovn-controller also sets the chassis column when it exe‐
2280 cutes this action with its chassis id.
2281 ovn-controller sets this column only if the type is "virtual".
2283 Naming:
2285 external_ids : name: optional string
2287 For a logical switch port, ovn-northd copies this from exter‐
2288 nal_ids:neutron:port_name in the Logical_Switch_Port table in
2289 the OVN_Northbound database, if it is a nonempty string.
2290 For a logical switch port, ovn-northd does not currently set
2292 this key.
2293 Common Columns:
2295 external_ids: map of string-string pairs
2297 See External IDs at the beginning of this document.
2298 The ovn-northd program populates this column with all entries
2300 into the external_ids column of the Logical_Switch_Port table of
2301 the OVN_Northbound database.
2302
2304 Each row in this table specifies a binding from an IP address to an
2305 Ethernet address that has been discovered through ARP (for IPv4) or
2306 neighbor discovery (for IPv6). This table is primarily used to discover
2307 bindings on physical networks, because IP-to-MAC bindings for virtual
2308 machines are usually populated statically into the Port_Binding table.
2309 This table expresses a functional relationship: MAC_Binding(logi‐
2311 cal_port, ip) = mac.
2312 In outline, the lifetime of a logical router’s MAC binding looks like
2314 this:
2315 1. On hypervisor 1, a logical router determines that a packet
2317 should be forwarded to IP address A on one of its router
2318 ports. It uses its logical flow table to determine that A
2319 lacks a static IP-to-MAC binding and the get_arp action to
2320 determine that it lacks a dynamic IP-to-MAC binding.
2321 2. Using an OVN logical arp action, the logical router gener‐
2323 ates and sends a broadcast ARP request to the router port.
2324 It drops the IP packet.
2325 3. The logical switch attached to the router port delivers the
2327 ARP request to all of its ports. (It might make sense to
2328 deliver it only to ports that have no static IP-to-MAC bind‐
2329 ings, but this could also be surprising behavior.)
2330 4. A host or VM on hypervisor 2 (which might be the same as
2332 hypervisor 1) attached to the logical switch owns the IP
2333 address in question. It composes an ARP reply and unicasts
2334 it to the logical router port’s Ethernet address.
2335 5. The logical switch delivers the ARP reply to the logical
2337 router port.
2338 6. The logical router flow table executes a put_arp action. To
2340 record the IP-to-MAC binding, ovn-controller adds a row to
2341 the MAC_Binding table.
2342 7. On hypervisor 1, ovn-controller receives the updated
2344 MAC_Binding table from the OVN southbound database. The next
2345 packet destined to A through the logical router is sent
2346 directly to the bound Ethernet address.
2347 Summary:
2349 logical_port string
2350 ip string
2351 mac string
2352 datapath Datapath_Binding
2353 Details:
2355 logical_port: string
2356 The logical port on which the binding was discovered.
2357 ip: string
2359 The bound IP address.
2360 mac: string
2362 The Ethernet address to which the IP is bound.
2363 datapath: Datapath_Binding
2365 The logical datapath to which the logical port belongs.
2366
2368 Each row in this table stores the DHCP Options supported by native OVN
2369 DHCP. ovn-northd populates this table with the supported DHCP options.
2370 ovn-controller looks up this table to get the DHCP codes of the DHCP
2371 options defined in the "put_dhcp_opts" action. Please refer to the RFC
2372 2132 "https://tools.ietf.org/html/rfc2132" for the possible list of
2373 DHCP options that can be defined here.
2374 Summary:
2376 name string
2377 code integer, in range 0 to 254
2378 type string, one of bool, ipv4, static_routes,
2379 str, uint16, uint32, or uint8
2380 Details:
2382 name: string
2383 Name of the DHCP option.
2384 Example. name="router"
2386 code: integer, in range 0 to 254
2388 DHCP option code for the DHCP option as defined in the RFC 2132.
2389 Example. code=3
2391 type: string, one of bool, ipv4, static_routes, str, uint16, uint32, or
2393 uint8
2394 Data type of the DHCP option code.
2395 value: bool
2397 This indicates that the value of the DHCP option is a
2398 bool.
2399 Example. "name=ip_forward_enable", "code=19",
2401 "type=bool".
2402 put_dhcp_opts(..., ip_forward_enable = 1,...)
2404 value: uint8
2406 This indicates that the value of the DHCP option is an
2407 unsigned int8 (8 bits)
2408 Example. "name=default_ttl", "code=23", "type=uint8".
2410 put_dhcp_opts(..., default_ttl = 50,...)
2412 value: uint16
2414 This indicates that the value of the DHCP option is an
2415 unsigned int16 (16 bits).
2416 Example. "name=mtu", "code=26", "type=uint16".
2418 put_dhcp_opts(..., mtu = 1450,...)
2420 value: uint32
2422 This indicates that the value of the DHCP option is an
2423 unsigned int32 (32 bits).
2424 Example. "name=lease_time", "code=51", "type=uint32".
2426 put_dhcp_opts(..., lease_time = 86400,...)
2428 value: ipv4
2430 This indicates that the value of the DHCP option is an
2431 IPv4 address or addresses.
2432 Example. "name=router", "code=3", "type=ipv4".
2434 put_dhcp_opts(..., router = 10.0.0.1,...)
2436 Example. "name=dns_server", "code=6", "type=ipv4".
2438 put_dhcp_opts(..., dns_server = {8.8.8.8 7.7.7.7},...)
2440 value: static_routes
2442 This indicates that the value of the DHCP option contains
2443 a pair of IPv4 route and next hop addresses.
2444 Example. "name=classless_static_route", "code=121",
2446 "type=static_routes".
2447 put_dhcp_opts(..., classless_static_route =
2449 {30.0.0.0/24,10.0.0.4,0.0.0.0/0,10.0.0.1}...)
2450 value: str
2452 This indicates that the value of the DHCP option is a
2453 string.
2454 Example. "name=host_name", "code=12", "type=str".
2456
2458 Each row in this table stores the DHCPv6 Options supported by native
2459 OVN DHCPv6. ovn-northd populates this table with the supported DHCPv6
2460 options. ovn-controller looks up this table to get the DHCPv6 codes of
2461 the DHCPv6 options defined in the put_dhcpv6_opts action. Please refer
2462 to RFC 3315 and RFC 3646 for the list of DHCPv6 options that can be
2463 defined here.
2464 Summary:
2466 name string
2467 code integer, in range 0 to 254
2468 type string, one of ipv6, mac, or str
2469 Details:
2471 name: string
2472 Name of the DHCPv6 option.
2473 Example. name="ia_addr"
2475 code: integer, in range 0 to 254
2477 DHCPv6 option code for the DHCPv6 option as defined in the
2478 appropriate RFC.
2479 Example. code=3
2481 type: string, one of ipv6, mac, or str
2483 Data type of the DHCPv6 option code.
2484 value: ipv6
2486 This indicates that the value of the DHCPv6 option is an
2487 IPv6 address(es).
2488 Example. "name=ia_addr", "code=5", "type=ipv6".
2490 put_dhcpv6_opts(..., ia_addr = ae70::4,...)
2492 value: str
2494 This indicates that the value of the DHCPv6 option is a
2495 string.
2496 Example. "name=domain_search", "code=24", "type=str".
2498 put_dhcpv6_opts(..., domain_search = ovn.domain,...)
2500 value: mac
2502 This indicates that the value of the DHCPv6 option is a
2503 MAC address.
2504 Example. "name=server_id", "code=2", "type=mac".
2506 put_dhcpv6_opts(..., server_id = 01:02:03:04L05:06,...)
2508
2510 Configuration for a database connection to an Open vSwitch database
2511 (OVSDB) client.
2512 This table primarily configures the Open vSwitch database server
2514 (ovsdb-server).
2515 The Open vSwitch database server can initiate and maintain active con‐
2517 nections to remote clients. It can also listen for database connec‐
2518 tions.
2519 Summary:
2521 Core Features:
2522 target string (must be unique within table)
2523 read_only boolean
2524 role string
2525 Client Failure Detection and Handling:
2526 max_backoff optional integer, at least 1,000
2527 inactivity_probe optional integer
2528 Status:
2529 is_connected boolean
2530 status : last_error optional string
2531 status : state optional string, one of ACTIVE, BACKOFF,
2532 CONNECTING, IDLE, or VOID
2533 status : sec_since_connect optional string, containing an integer,
2534 at least 0
2535 status : sec_since_disconnect
2536 optional string, containing an integer,
2537 at least 0
2538 status : locks_held optional string
2539 status : locks_waiting optional string
2540 status : locks_lost optional string
2541 status : n_connections optional string, containing an integer,
2542 at least 2
2543 status : bound_port optional string, containing an integer
2544 Common Columns:
2545 external_ids map of string-string pairs
2546 other_config map of string-string pairs
2547 Details:
2549 Core Features:
2550 target: string (must be unique within table)
2552 Connection methods for clients.
2553 The following connection methods are currently supported:
2555 ssl:host[:port]
2557 The specified SSL port on the given host, which can
2558 either be a DNS name (if built with unbound library) or
2559 an IP address. A valid SSL configuration must be provided
2560 when this form is used, this configuration can be speci‐
2561 fied via command-line options or the SSL table.
2562 If port is not specified, it defaults to 6640.
2564 SSL support is an optional feature that is not always
2566 built as part of Open vSwitch.
2567 tcp:host[:port]
2569 The specified TCP port on the given host, which can
2570 either be a DNS name (if built with unbound library) or
2571 an IP address (IPv4 or IPv6). If host is an IPv6 address,
2572 wrap it in square brackets, e.g. tcp:[::1]:6640.
2573 If port is not specified, it defaults to 6640.
2575 pssl:[port][:host]
2577 Listens for SSL connections on the specified TCP port.
2578 Specify 0 for port to have the kernel automatically
2579 choose an available port. If host, which can either be a
2580 DNS name (if built with unbound library) or an IP
2581 address, is specified, then connections are restricted to
2582 the resolved or specified local IP address (either IPv4
2583 or IPv6 address). If host is an IPv6 address, wrap in
2584 square brackets, e.g. pssl:6640:[::1]. If host is not
2585 specified then it listens only on IPv4 (but not IPv6)
2586 addresses. A valid SSL configuration must be provided
2587 when this form is used, this can be specified either via
2588 command-line options or the SSL table.
2589 If port is not specified, it defaults to 6640.
2591 SSL support is an optional feature that is not always
2593 built as part of Open vSwitch.
2594 ptcp:[port][:host]
2596 Listens for connections on the specified TCP port. Spec‐
2597 ify 0 for port to have the kernel automatically choose an
2598 available port. If host, which can either be a DNS name
2599 (if built with unbound library) or an IP address, is
2600 specified, then connections are restricted to the
2601 resolved or specified local IP address (either IPv4 or
2602 IPv6 address). If host is an IPv6 address, wrap it in
2603 square brackets, e.g. ptcp:6640:[::1]. If host is not
2604 specified then it listens only on IPv4 addresses.
2605 If port is not specified, it defaults to 6640.
2607 When multiple clients are configured, the target values must be
2609 unique. Duplicate target values yield unspecified results.
2610 read_only: boolean
2612 true to restrict these connections to read-only transactions,
2613 false to allow them to modify the database.
2614 role: string
2616 String containing role name for this connection entry.
2617 Client Failure Detection and Handling:
2619 max_backoff: optional integer, at least 1,000
2621 Maximum number of milliseconds to wait between connection
2622 attempts. Default is implementation-specific.
2623 inactivity_probe: optional integer
2625 Maximum number of milliseconds of idle time on connection to the
2626 client before sending an inactivity probe message. If Open
2627 vSwitch does not communicate with the client for the specified
2628 number of seconds, it will send a probe. If a response is not
2629 received for the same additional amount of time, Open vSwitch
2630 assumes the connection has been broken and attempts to recon‐
2631 nect. Default is implementation-specific. A value of 0 disables
2632 inactivity probes.
2633 Status:
2635 Key-value pair of is_connected is always updated. Other key-value pairs
2637 in the status columns may be updated depends on the target type.
2638 When target specifies a connection method that listens for inbound con‐
2640 nections (e.g. ptcp: or punix:), both n_connections and is_connected
2641 may also be updated while the remaining key-value pairs are omitted.
2642 On the other hand, when target specifies an outbound connection, all
2644 key-value pairs may be updated, except the above-mentioned two key-
2645 value pairs associated with inbound connection targets. They are omit‐
2646 ted.
2647 is_connected: boolean
2649 true if currently connected to this client, false otherwise.
2650 status : last_error: optional string
2652 A human-readable description of the last error on the connection
2653 to the manager; i.e. strerror(errno). This key will exist only
2654 if an error has occurred.
2655 status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
2657 IDLE, or VOID
2658 The state of the connection to the manager:
2659 VOID Connection is disabled.
2661 BACKOFF
2663 Attempting to reconnect at an increasing period.
2664 CONNECTING
2666 Attempting to connect.
2667 ACTIVE Connected, remote host responsive.
2669 IDLE Connection is idle. Waiting for response to keep-alive.
2671 These values may change in the future. They are provided only
2673 for human consumption.
2674 status : sec_since_connect: optional string, containing an integer, at
2676 least 0
2677 The amount of time since this client last successfully connected
2678 to the database (in seconds). Value is empty if client has never
2679 successfully been connected.
2680 status : sec_since_disconnect: optional string, containing an integer,
2682 at least 0
2683 The amount of time since this client last disconnected from the
2684 database (in seconds). Value is empty if client has never dis‐
2685 connected.
2686 status : locks_held: optional string
2688 Space-separated list of the names of OVSDB locks that the con‐
2689 nection holds. Omitted if the connection does not hold any
2690 locks.
2691 status : locks_waiting: optional string
2693 Space-separated list of the names of OVSDB locks that the con‐
2694 nection is currently waiting to acquire. Omitted if the connec‐
2695 tion is not waiting for any locks.
2696 status : locks_lost: optional string
2698 Space-separated list of the names of OVSDB locks that the con‐
2699 nection has had stolen by another OVSDB client. Omitted if no
2700 locks have been stolen from this connection.
2701 status : n_connections: optional string, containing an integer, at
2703 least 2
2704 When target specifies a connection method that listens for
2705 inbound connections (e.g. ptcp: or pssl:) and more than one con‐
2706 nection is actually active, the value is the number of active
2707 connections. Otherwise, this key-value pair is omitted.
2708 status : bound_port: optional string, containing an integer
2710 When target is ptcp: or pssl:, this is the TCP port on which the
2711 OVSDB server is listening. (This is particularly useful when
2712 target specifies a port of 0, allowing the kernel to choose any
2713 available port.)
2714 Common Columns:
2716 The overall purpose of these columns is described under Common Columns
2718 at the beginning of this document.
2719 external_ids: map of string-string pairs
2721 other_config: map of string-string pairs
2723
2725 SSL configuration for ovn-sb database access.
2726 Summary:
2728 private_key string
2729 certificate string
2730 ca_cert string
2731 bootstrap_ca_cert boolean
2732 ssl_protocols string
2733 ssl_ciphers string
2734 Common Columns:
2735 external_ids map of string-string pairs
2736 Details:
2738 private_key: string
2739 Name of a PEM file containing the private key used as the
2740 switch’s identity for SSL connections to the controller.
2741 certificate: string
2743 Name of a PEM file containing a certificate, signed by the cer‐
2744 tificate authority (CA) used by the controller and manager, that
2745 certifies the switch’s private key, identifying a trustworthy
2746 switch.
2747 ca_cert: string
2749 Name of a PEM file containing the CA certificate used to verify
2750 that the switch is connected to a trustworthy controller.
2751 bootstrap_ca_cert: boolean
2753 If set to true, then Open vSwitch will attempt to obtain the CA
2754 certificate from the controller on its first SSL connection and
2755 save it to the named PEM file. If it is successful, it will
2756 immediately drop the connection and reconnect, and from then on
2757 all SSL connections must be authenticated by a certificate
2758 signed by the CA certificate thus obtained. This option exposes
2759 the SSL connection to a man-in-the-middle attack obtaining the
2760 initial CA certificate. It may still be useful for bootstrap‐
2761 ping.
2762 ssl_protocols: string
2764 List of SSL protocols to be enabled for SSL connections. The
2765 default when this option is omitted is TLSv1,TLSv1.1,TLSv1.2.
2766 ssl_ciphers: string
2768 List of ciphers (in OpenSSL cipher string format) to be sup‐
2769 ported for SSL connections. The default when this option is
2770 omitted is HIGH:!aNULL:!MD5.
2771 Common Columns:
2773 The overall purpose of these columns is described under Common Columns
2775 at the beginning of this document.
2776 external_ids: map of string-string pairs
2778
2780 Each row in this table stores the DNS records. The OVN action
2781 dns_lookup uses this table for DNS resolution.
2782 Summary:
2784 records map of string-string pairs
2785 datapaths set of 1 or more Datapath_Bindings
2786 Common Columns:
2787 external_ids map of string-string pairs
2788 Details:
2790 records: map of string-string pairs
2791 Key-value pair of DNS records with DNS query name as the key and
2792 a string of IP address(es) separated by comma or space as the
2793 value. ovn-northd stores the DNS query name in all lowercase in
2794 order to facilitate case-insensitive lookups.
2795 Example: "vm1.ovn.org" = "10.0.0.4 aef0::4"
2797 datapaths: set of 1 or more Datapath_Bindings
2799 The DNS records defined in the column records will be applied
2800 only to the DNS queries originating from the datapaths defined
2801 in this column.
2802 Common Columns:
2804 external_ids: map of string-string pairs
2806 See External IDs at the beginning of this document.
2807
2809 Role table for role-based access controls.
2810 Summary:
2812 name string
2813 permissions map of string-weak reference to RBAC_Per‐
2814 mission pairs
2815 Details:
2817 name: string
2818 The role name, corresponding to the role column in the Connec‐
2819 tion table.
2820 permissions: map of string-weak reference to RBAC_Permission pairs
2822 A mapping of table names to rows in the RBAC_Permission table.
2823
2825 Permissions table for role-based access controls.
2826 Summary:
2828 table string
2829 authorization set of strings
2830 insert_delete boolean
2831 update set of strings
2832 Details:
2834 table: string
2835 Name of table to which this row applies.
2836 authorization: set of strings
2838 Set of strings identifying columns and column:key pairs to be
2839 compared with client ID. At least one match is required in order
2840 to be authorized. A zero-length string is treated as a special
2841 value indicating all clients should be considered authorized.
2842 insert_delete: boolean
2844 When "true", row insertions and authorized row deletions are
2845 permitted.
2846 update: set of strings
2848 Set of strings identifying columns and column:key pairs that
2849 authorized clients are allowed to modify.
2850
2852 Association of Port_Binding rows of type chassisredirect to a Chassis.
2853 The traffic going out through a specific chassisredirect port will be
2854 redirected to a chassis, or a set of them in high availability configu‐
2855 rations.
2856 Summary:
2858 name string (must be unique within table)
2859 chassis optional weak reference to Chassis
2860 priority integer, in range 0 to 32,767
2861 options map of string-string pairs
2862 Common Columns:
2863 external_ids map of string-string pairs
2864 Details:
2866 name: string (must be unique within table)
2867 Name of the Gateway_Chassis.
2868 A suggested, but not required naming convention is
2870 ${port_name}_${chassis_name}.
2871 chassis: optional weak reference to Chassis
2873 The Chassis to which we send the traffic.
2874 priority: integer, in range 0 to 32,767
2876 This is the priority the specific Chassis among all Gate‐
2877 way_Chassis belonging to the same Port_Binding.
2878 options: map of string-string pairs
2880 Reserved for future use.
2881 Common Columns:
2883 The overall purpose of these columns is described under Common Columns
2885 at the beginning of this document.
2886 external_ids: map of string-string pairs
2888
2890 Summary:
2891 chassis optional weak reference to Chassis
2892 priority integer, in range 0 to 32,767
2893 Common Columns:
2894 external_ids map of string-string pairs
2895 Details:
2897 chassis: optional weak reference to Chassis
2898 The Chassis which provides the HA functionality.
2899 priority: integer, in range 0 to 32,767
2901 Priority of the HA chassis. Chassis with highest priority will
2902 be the master in the HA chassis group.
2903 Common Columns:
2905 external_ids: map of string-string pairs
2907 See External IDs at the beginning of this document.
2908
2910 Table representing a group of chassis which can provide High availabil‐
2911 ity services. Each chassis in the group is represented by the table
2912 HA_Chassis. The HA chassis with highest priority will be the master of
2913 this group. If the master chassis failover is detected, the HA chassis
2914 with the next higher priority takes over the responsibility of provid‐
2915 ing the HA. If ha_chassis_group column of the table Port_Binding refer‐
2916 ences this table, then this HA chassis group provides the gateway func‐
2917 tionality and redirects the gateway traffic to the master of this
2918 group.
2919 Summary:
2921 name string (must be unique within table)
2922 ha_chassis set of HA_Chassiss
2923 ref_chassis set of weak reference to Chassiss
2924 Common Columns:
2925 external_ids map of string-string pairs
2926 Details:
2928 name: string (must be unique within table)
2929 Name of the HA_Chassis_Group. Name should be unique.
2930 ha_chassis: set of HA_Chassiss
2932 A list of HA_Chassis which belongs to this group.
2933 ref_chassis: set of weak reference to Chassiss
2935 A list of chassis which references this HA chassis group.
2936 Common Columns:
2938 external_ids: map of string-string pairs
2940 See External IDs at the beginning of this document.
2941
2943 Database table used by ovn-controller to report CMS related events.
2944 Please note there is no guarantee a given event is written exactly once
2945 in the db. It is CMS responsibility to squash duplicated lines or to
2946 filter out duplicated events
2947 Summary:
2949 event_type string, must be empty_lb_backends
2950 event_info map of string-string pairs
2951 chassis optional weak reference to Chassis
2952 seq_num integer
2953 Details:
2955 event_type: string, must be empty_lb_backends
2956 Event type occurred
2957 event_info: map of string-string pairs
2959 Key-value pairs used to specify event info to the CMS. Possible
2960 values are:
2961 · vip: VIP reported for the empty_lb_backends event
2963 · protocol: Transport protocol reported for the
2965 empty_lb_backends event
2966 · load_balancer: UUID of the load balancer reported for the
2968 empty_lb_backends event
2969 chassis: optional weak reference to Chassis
2971 This column is a Chassis record to identify the chassis that has
2972 managed a given event.
2973 seq_num: integer
2975 Event sequence number. Global counter for controller generated
2976 events. It can be used by the CMS to detect possible duplication
2977 of the same event.
2978
2980 IP Multicast configuration options. For now only applicable to IGMP.
2981 Summary:
2983 datapath weak reference to Datapath_Binding (must
2984 be unique within table)
2985 enabled optional boolean
2986 querier optional boolean
2987 table_size optional integer
2988 idle_timeout optional integer
2989 query_interval optional integer
2990 seq_no integer
2991 Querier configuration options:
2992 eth_src string
2993 ip4_src string
2994 ip6_src string
2995 query_max_resp optional integer
2996 Details:
2998 datapath: weak reference to Datapath_Binding (must be unique within ta‐
2999 ble)
3000 Datapath_Binding entry for which these configuration options are
3001 defined.
3002 enabled: optional boolean
3004 Enables/disables multicast snooping. Default: disabled.
3005 querier: optional boolean
3007 Enables/disables multicast querying. If enabled then multicast
3008 querying is enabled by default.
3009 table_size: optional integer
3011 Limits the number of multicast groups that can be learned.
3012 Default: 2048 groups per datapath.
3013 idle_timeout: optional integer
3015 Configures the idle timeout (in seconds) for IP multicast groups
3016 if multicast snooping is enabled. Default: 300 seconds.
3017 query_interval: optional integer
3019 Configures the interval (in seconds) for sending multicast
3020 queries if snooping and querier are enabled. Default: idle_time‐
3021 out/2 seconds.
3022 seq_no: integer
3024 ovn-controller reads this value and flushes all learned multi‐
3025 cast groups when it detects that seq_no was changed.
3026 Querier configuration options:
3028 The ovn-controller process that runs on OVN hypervisor nodes uses the
3030 following columns to determine field values in IGMP/MLD queries that it
3031 originates:
3032 eth_src: string
3034 Source Ethernet address.
3035 ip4_src: string
3037 Source IPv4 address.
3038 ip6_src: string
3040 Source IPv6 address.
3041 query_max_resp: optional integer
3043 Value (in seconds) to be used as "max-response" field in multi‐
3044 cast queries. Default: 1 second.
3046 Contains learned IGMP groups indexed by address/datapath/chassis.
3047 Summary:
3049 address string
3050 datapath optional weak reference to Datapath_Bind‐
3051 ing
3052 chassis optional weak reference to Chassis
3053 ports set of weak reference to Port_Bindings
3054 Details:
3056 address: string
3057 Destination IPv4 address for the IGMP group.
3058 datapath: optional weak reference to Datapath_Binding
3060 Datapath to which this IGMP group belongs.
3061 chassis: optional weak reference to Chassis
3063 Chassis to which this IGMP group belongs.
3064 ports: set of weak reference to Port_Bindings
3066 The destination port bindings for this IGMP group.
3067
3069 This table montiors a service for its liveliness. The service can be an
3070 IPv4 tcp or a udp service. ovn-controller periodically sends out ser‐
3071 vice monitor packets and updates the status of the service. Service
3072 monitoring for IPv6 services is not supported.
3073 Summary:
3075 ip string
3076 protocol optional string, either tcp or udp
3077 port integer, in range 0 to 32,767
3078 logical_port string
3079 status optional string, one of error, offline,
3080 or online
3081 src_mac string
3082 src_ip string
3083 Service monitor options:
3084 options : interval optional string, containing an integer
3085 options : timeout optional string, containing an integer
3086 options : success_count optional string, containing an integer
3087 options : failure_count optional string, containing an integer
3088 Common Columns:
3089 external_ids map of string-string pairs
3090 Details:
3092 ip: string
3093 IP of the service to be monitored. Only IPv4 is supported.
3094 protocol: optional string, either tcp or udp
3096 The protocol of the service. It can be either tcp or udp.
3097 port: integer, in range 0 to 32,767
3099 The tcp or udp port of the service.
3100 logical_port: string
3102 The VIF of logical port on which the service is running. The
3103 ovn-controller which binds this logical_port monitors the ser‐
3104 vice by sending periodic monitor packets.
3105 status: optional string, one of error, offline, or online
3107 The ovn-controller which binds the logical_port updates the sta‐
3108 tus to online offline or error.
3109 For tcp service, ovn-controller sends a TCP SYN packet to the
3111 service and expects a TCP ACK response to consider the service
3112 to be online.
3113 For udp service, ovn-controller sends a udp packet to the ser‐
3115 vice and doesn’t expect any reply. If it receives ICMP reply,
3116 then it considers the service to be offline.
3117 src_mac: string
3119 Source Ethernet address to use in the service monitor packet.
3120 src_ip: string
3122 Source IPv4 address to use in the service monitor packet.
3123 Service monitor options:
3125 options : interval: optional string, containing an integer
3127 The interval, in seconds, between service monitor checks.
3128 options : timeout: optional string, containing an integer
3130 The time, in seconds, after which the service monitor check
3131 times out.
3132 options : success_count: optional string, containing an integer
3134 The number of successful checks after which the service is con‐
3135 sidered online.
3136 options : failure_count: optional string, containing an integer
3138 The number of failure checks after which the service is consid‐
3139 ered offline.
3140 Common Columns:
3142 external_ids: map of string-string pairs
3144 See External IDs at the beginning of this document.
3145Open vSwitch 20.03.0 DB Schema 2.7.0 ovn-sb(5)