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
156 Southbound configuration for an OVN system. This table must have
157 exactly one row.
158 Summary:
160 Status:
161 nb_cfg integer
162 Common Columns:
163 external_ids map of string-string pairs
164 options map of string-string pairs
165 Common options:
166 options map of string-string pairs
167 Options for configuring BFD:
168 options : bfd-min-rx optional string
169 options : bfd-decay-min-rx
170 optional string
171 options : bfd-min-tx optional string
172 options : bfd-mult optional string
173 Connection Options:
174 connections set of Connections
175 ssl optional SSL
176 Security Configurations:
177 ipsec boolean
178 Details:
180 Status:
181 This column allow a client to track the overall configuration state of
183 the system.
184 nb_cfg: integer
186 Sequence number for the configuration. When a CMS or ovn-nbctl
187 updates the northbound database, it increments the nb_cfg column
188 in the NB_Global table in the northbound database. In turn, when
189 ovn-northd updates the southbound database to bring it up to
190 date with these changes, it updates this column to the same
191 value.
192 Common Columns:
194 external_ids: map of string-string pairs
196 See External IDs at the beginning of this document.
197 options: map of string-string pairs
199 Common options:
201 options: map of string-string pairs
203 This column provides general key/value settings. The supported
204 options are described individually below.
205 Options for configuring BFD:
207 These options apply when ovn-controller configures BFD on tunnels
209 interfaces.
210 options : bfd-min-rx: optional string
212 BFD option min-rx value to use when configuring BFD on tunnel
213 interfaces.
214 options : bfd-decay-min-rx: optional string
216 BFD option decay-min-rx value to use when configuring BFD on
217 tunnel interfaces.
218 options : bfd-min-tx: optional string
220 BFD option min-tx value to use when configuring BFD on tunnel
221 interfaces.
222 options : bfd-mult: optional string
224 BFD option mult value to use when configuring BFD on tunnel
225 interfaces.
226 Connection Options:
228 connections: set of Connections
230 Database clients to which the Open vSwitch database server
231 should connect or on which it should listen, along with options
232 for how these connections should be configured. See the Connec‐
233 tion table for more information.
234 ssl: optional SSL
236 Global SSL configuration.
237 Security Configurations:
239 ipsec: boolean
241 Tunnel encryption configuration. If this column is set to be
242 true, all OVN tunnels will be encrypted with IPsec.
244 Each row in this table represents a hypervisor or gateway (a chassis)
245 in the physical network. Each chassis, via ovn-controller/ovn-con‐
246 troller-vtep, adds and updates its own row, and keeps a copy of the
247 remaining rows to determine how to reach other hypervisors.
248 When a chassis shuts down gracefully, it should remove its own row.
250 (This is not critical because resources hosted on the chassis are
251 equally unreachable regardless of whether the row is present.) If a
252 chassis shuts down permanently without removing its row, some kind of
253 manual or automatic cleanup is eventually needed; we can devise a
254 process for that as necessary.
255 Summary:
257 name string (must be unique within table)
258 hostname string
259 nb_cfg integer
260 external_ids : ovn-bridge-mappings
261 optional string
262 external_ids : datapath-type optional string
263 external_ids : iface-types optional string
264 external_ids : ovn-cms-options
265 optional string
266 transport_zones set of strings
267 external_ids : ovn-chassis-mac-mappings
268 optional string
269 Common Columns:
270 external_ids map of string-string pairs
271 Encapsulation Configuration:
272 encaps set of 1 or more Encaps
273 Gateway Configuration:
274 vtep_logical_switches set of strings
275 Details:
277 name: string (must be unique within table)
278 OVN does not prescribe a particular format for chassis names.
279 ovn-controller populates this column using external_ids:system-
280 id in the Open_vSwitch database’s Open_vSwitch table. ovn-con‐
281 troller-vtep populates this column with name in the hard‐
282 ware_vtep database’s Physical_Switch table.
283 hostname: string
285 The hostname of the chassis, if applicable. ovn-controller will
286 populate this column with the hostname of the host it is running
287 on. ovn-controller-vtep will leave this column empty.
288 nb_cfg: integer
290 Sequence number for the configuration. When ovn-controller
291 updates the configuration of a chassis from the contents of the
292 southbound database, it copies nb_cfg from the SB_Global table
293 into this column.
294 external_ids : ovn-bridge-mappings: optional string
296 ovn-controller populates this key with the set of bridge map‐
297 pings it has been configured to use. Other applications should
298 treat this key as read-only. See ovn-controller(8) for more
299 information.
300 external_ids : datapath-type: optional string
302 ovn-controller populates this key with the datapath type config‐
303 ured in the datapath_type column of the Open_vSwitch database’s
304 Bridge table. Other applications should treat this key as read-
305 only. See ovn-controller(8) for more information.
306 external_ids : iface-types: optional string
308 ovn-controller populates this key with the interface types con‐
309 figured in the iface_types column of the Open_vSwitch database’s
310 Open_vSwitch table. Other applications should treat this key as
311 read-only. See ovn-controller(8) for more information.
312 external_ids : ovn-cms-options: optional string
314 ovn-controller populates this key with the set of options con‐
315 figured in the external_ids:ovn-cms-options column of the
316 Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
317 troller(8) for more information.
318 transport_zones: set of strings
320 ovn-controller populates this key with the transport zones con‐
321 figured in the external_ids:ovn-transport-zones column of the
322 Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
323 troller(8) for more information.
324 external_ids : ovn-chassis-mac-mappings: optional string
326 ovn-controller populates this key with the set of options con‐
327 figured in the external_ids:ovn-chassis-mac-mappings column of
328 the Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
329 troller(8) for more information.
330 Common Columns:
332 The overall purpose of these columns is described under Common Columns
334 at the beginning of this document.
335 external_ids: map of string-string pairs
337 Encapsulation Configuration:
339 OVN uses encapsulation to transmit logical dataplane packets between
341 chassis.
342 encaps: set of 1 or more Encaps
344 Points to supported encapsulation configurations to transmit
345 logical dataplane packets to this chassis. Each entry is a Encap
346 record that describes the configuration.
347 Gateway Configuration:
349 A gateway is a chassis that forwards traffic between the OVN-managed
351 part of a logical network and a physical VLAN, extending a tunnel-based
352 logical network into a physical network. Gateways are typically dedi‐
353 cated nodes that do not host VMs and will be controlled by ovn-con‐
354 troller-vtep.
355 vtep_logical_switches: set of strings
357 Stores all VTEP logical switch names connected by this gateway
358 chassis. The Port_Binding table entry with options:vtep-physi‐
359 cal-switch equal Chassis name, and options:vtep-logical-switch
360 value in Chassis vtep_logical_switches, will be associated with
361 this Chassis.
362
364 The encaps column in the Chassis table refers to rows in this table to
365 identify how OVN may transmit logical dataplane packets to this chas‐
366 sis. Each chassis, via ovn-controller(8) or ovn-controller-vtep(8),
367 adds and updates its own rows and keeps a copy of the remaining rows to
368 determine how to reach other chassis.
369 Summary:
371 type string, one of geneve, stt, or vxlan
372 options map of string-string pairs
373 options : csum optional string, either true or false
374 options : dst_port optional string, containing an integer
375 ip string
376 chassis_name string
377 Details:
379 type: string, one of geneve, stt, or vxlan
380 The encapsulation to use to transmit packets to this chassis.
381 Hypervisors must use either geneve or stt. Gateways may use
382 vxlan, geneve, or stt.
383 options: map of string-string pairs
385 Options for configuring the encapsulation, which may be type
386 specific.
387 options : csum: optional string, either true or false
389 csum indicates whether this chassis can transmit and receive
390 packets that include checksums with reasonable performance. It
391 hints to senders transmitting data to this chassis that they
392 should use checksums to protect OVN metadata. ovn-controller
393 populates this key with the value defined in external_ids:ovn-
394 encap-csum column of the Open_vSwitch database’s Open_vSwitch
395 table. Other applications should treat this key as read-only.
396 See ovn-controller(8) for more information.
397 In terms of performance, checksumming actually significantly
399 increases throughput in most common cases when running on Linux
400 based hosts without NICs supporting encapsulation hardware off‐
401 load (around 60% for bulk traffic). The reason is that generally
402 all NICs are capable of offloading transmitted and received
403 TCP/UDP checksums (viewed as ordinary data packets and not as
404 tunnels). The benefit comes on the receive side where the vali‐
405 dated outer checksum can be used to additionally validate an
406 inner checksum (such as TCP), which in turn allows aggregation
407 of packets to be more efficiently handled by the rest of the
408 stack.
409 Not all devices see such a benefit. The most notable exception
411 is hardware VTEPs. These devices are designed to not buffer
412 entire packets in their switching engines and are therefore
413 unable to efficiently compute or validate full packet checksums.
414 In addition certain versions of the Linux kernel are not able to
415 fully take advantage of encapsulation NIC offloads in the pres‐
416 ence of checksums. (This is actually a pretty narrow corner case
417 though: earlier versions of Linux don’t support encapsulation
418 offloads at all and later versions support both offloads and
419 checksums well.)
420 csum defaults to false for hardware VTEPs and true for all other
422 cases.
423 This option applies to geneve and vxlan encapsulations.
425 options : dst_port: optional string, containing an integer
427 If set, overrides the UDP (for geneve and vxlan) or TCP (for
428 stt) destination port.
429 ip: string
431 The IPv4 address of the encapsulation tunnel endpoint.
432 chassis_name: string
434 The name of the chassis that created this encap.
435
437 This table contains address sets synced from the Address_Set table in
438 the OVN_Northbound database and address sets generated from the
439 Port_Group table in the OVN_Northbound database.
440 See the documentation for the Address_Set table and Port_Group table in
442 the OVN_Northbound database for details.
443 Summary:
445 name string (must be unique within table)
446 addresses set of strings
447 Details:
449 name: string (must be unique within table)
450 addresses: set of strings
452
454 This table contains names for the logical switch ports in the
455 OVN_Northbound database that belongs to the same group that is defined
456 in Port_Group in the OVN_Northbound database.
457 Summary:
459 name string (must be unique within table)
460 ports set of strings
461 Details:
463 name: string (must be unique within table)
464 ports: set of strings
466
468 Each row in this table represents one logical flow. ovn-northd popu‐
469 lates this table with logical flows that implement the L2 and L3
470 topologies specified in the OVN_Northbound database. Each hypervisor,
471 via ovn-controller, translates the logical flows into OpenFlow flows
472 specific to its hypervisor and installs them into Open vSwitch.
473 Logical flows are expressed in an OVN-specific format, described here.
475 A logical datapath flow is much like an OpenFlow flow, except that the
476 flows are written in terms of logical ports and logical datapaths
477 instead of physical ports and physical datapaths. Translation between
478 logical and physical flows helps to ensure isolation between logical
479 datapaths. (The logical flow abstraction also allows the OVN central‐
480 ized components to do less work, since they do not have to separately
481 compute and push out physical flows to each chassis.)
482 The default action when no flow matches is to drop packets.
484 Architectural Logical Life Cycle of a Packet
486 This following description focuses on the life cycle of a packet
488 through a logical datapath, ignoring physical details of the implemen‐
489 tation. Please refer to Architectural Physical Life Cycle of a Packet
490 in ovn-architecture(7) for the physical information.
491 The description here is written as if OVN itself executes these steps,
493 but in fact OVN (that is, ovn-controller) programs Open vSwitch, via
494 OpenFlow and OVSDB, to execute them on its behalf.
495 At a high level, OVN passes each packet through the logical datapath’s
497 logical ingress pipeline, which may output the packet to one or more
498 logical port or logical multicast groups. For each such logical output
499 port, OVN passes the packet through the datapath’s logical egress pipe‐
500 line, which may either drop the packet or deliver it to the destina‐
501 tion. Between the two pipelines, outputs to logical multicast groups
502 are expanded into logical ports, so that the egress pipeline only pro‐
503 cesses a single logical output port at a time. Between the two pipe‐
504 lines is also where, when necessary, OVN encapsulates a packet in a
505 tunnel (or tunnels) to transmit to remote hypervisors.
506 In more detail, to start, OVN searches the Logical_Flow table for a row
508 with correct logical_datapath, a pipeline of ingress, a table_id of 0,
509 and a match that is true for the packet. If none is found, OVN drops
510 the packet. If OVN finds more than one, it chooses the match with the
511 highest priority. Then OVN executes each of the actions specified in
512 the row’s actions column, in the order specified. Some actions, such as
513 those to modify packet headers, require no further details. The next
514 and output actions are special.
515 The next action causes the above process to be repeated recursively,
517 except that OVN searches for table_id of 1 instead of 0. Similarly, any
518 next action in a row found in that table would cause a further search
519 for a table_id of 2, and so on. When recursive processing completes,
520 flow control returns to the action following next.
521 The output action also introduces recursion. Its effect depends on the
523 current value of the outport field. Suppose outport designates a logi‐
524 cal port. First, OVN compares inport to outport; if they are equal, it
525 treats the output as a no-op by default. In the common case, where they
526 are different, the packet enters the egress pipeline. This transition
527 to the egress pipeline discards register data, e.g. reg0 ... reg9 and
528 connection tracking state, to achieve uniform behavior regardless of
529 whether the egress pipeline is on a different hypervisor (because reg‐
530 isters aren’t preserve across tunnel encapsulation).
531 To execute the egress pipeline, OVN again searches the Logical_Flow ta‐
533 ble for a row with correct logical_datapath, a table_id of 0, a match
534 that is true for the packet, but now looking for a pipeline of egress.
535 If no matching row is found, the output becomes a no-op. Otherwise, OVN
536 executes the actions for the matching flow (which is chosen from multi‐
537 ple, if necessary, as already described).
538 In the egress pipeline, the next action acts as already described,
540 except that it, of course, searches for egress flows. The output
541 action, however, now directly outputs the packet to the output port
542 (which is now fixed, because outport is read-only within the egress
543 pipeline).
544 The description earlier assumed that outport referred to a logical
546 port. If it instead designates a logical multicast group, then the
547 description above still applies, with the addition of fan-out from the
548 logical multicast group to each logical port in the group. For each
549 member of the group, OVN executes the logical pipeline as described,
550 with the logical output port replaced by the group member.
551 Pipeline Stages
553 ovn-northd populates the Logical_Flow table with the logical flows
555 described in detail in ovn-northd(8).
556 Summary:
558 logical_datapath Datapath_Binding
559 pipeline string, either egress or ingress
560 table_id integer, in range 0 to 23
561 priority integer, in range 0 to 65,535
562 match string
563 actions string
564 external_ids : stage-name optional string
565 external_ids : stage-hint optional string, containing an uuid
566 external_ids : source optional string
567 Common Columns:
568 external_ids map of string-string pairs
569 Details:
571 logical_datapath: Datapath_Binding
572 The logical datapath to which the logical flow belongs.
573 pipeline: string, either egress or ingress
575 The primary flows used for deciding on a packet’s destination
576 are the ingress flows. The egress flows implement ACLs. See Log‐
577 ical Life Cycle of a Packet, above, for details.
578 table_id: integer, in range 0 to 23
580 The stage in the logical pipeline, analogous to an OpenFlow ta‐
581 ble number.
582 priority: integer, in range 0 to 65,535
584 The flow’s priority. Flows with numerically higher priority take
585 precedence over those with lower. If two logical datapath flows
586 with the same priority both match, then the one actually applied
587 to the packet is undefined.
588 match: string
590 A matching expression. OVN provides a superset of OpenFlow
591 matching capabilities, using a syntax similar to Boolean expres‐
592 sions in a programming language.
593 The most important components of match expression are compar‐
595 isons between symbols and constants, e.g. ip4.dst ==
596 192.168.0.1, ip.proto == 6, arp.op == 1, eth.type == 0x800. The
597 logical AND operator && and logical OR operator || can combine
598 comparisons into a larger expression.
599 Matching expressions also support parentheses for grouping, the
601 logical NOT prefix operator !, and literals 0 and 1 to express
602 ``false’’ or ``true,’’ respectively. The latter is useful by
603 itself as a catch-all expression that matches every packet.
604 Match expressions also support a kind of function syntax. The
606 following functions are supported:
607 is_chassis_resident(lport)
609 Evaluates to true on a chassis on which logical port
610 lport (a quoted string) resides, and to false elsewhere.
611 This function was introduced in OVN 2.7.
612 Symbols
614 Type. Symbols have integer or string type. Integer symbols have
616 a width in bits.
617 Kinds. There are three kinds of symbols:
619 · Fields. A field symbol represents a packet header or
621 metadata field. For example, a field named vlan.tci might
622 represent the VLAN TCI field in a packet.
623 A field symbol can have integer or string type. Integer
625 fields can be nominal or ordinal (see Level of Measure‐
626 ment, below).
627 · Subfields. A subfield represents a subset of bits from a
629 larger field. For example, a field vlan.vid might be
630 defined as an alias for vlan.tci[0..11]. Subfields are
631 provided for syntactic convenience, because it is always
632 possible to instead refer to a subset of bits from a
633 field directly.
634 Only ordinal fields (see Level of Measurement, below) may
636 have subfields. Subfields are always ordinal.
637 · Predicates. A predicate is shorthand for a Boolean
639 expression. Predicates may be used much like 1-bit
640 fields. For example, ip4 might expand to eth.type ==
641 0x800. Predicates are provided for syntactic convenience,
642 because it is always possible to instead specify the
643 underlying expression directly.
644 A predicate whose expansion refers to any nominal field
646 or predicate (see Level of Measurement, below) is nomi‐
647 nal; other predicates have Boolean level of measurement.
648 Level of Measurement. See
650 http://en.wikipedia.org/wiki/Level_of_measurement for the sta‐
651 tistical concept on which this classification is based. There
652 are three levels:
653 · Ordinal. In statistics, ordinal values can be ordered on
655 a scale. OVN considers a field (or subfield) to be ordi‐
656 nal if its bits can be examined individually. This is
657 true for the OpenFlow fields that OpenFlow or Open
658 vSwitch makes ``maskable.’’
659 Any use of a ordinal field may specify a single bit or a
661 range of bits, e.g. vlan.tci[13..15] refers to the PCP
662 field within the VLAN TCI, and eth.dst[40] refers to the
663 multicast bit in the Ethernet destination address.
664 OVN supports all the usual arithmetic relations (==, !=,
666 <, <=, >, and >=) on ordinal fields and their subfields,
667 because OVN can implement these in OpenFlow and Open
668 vSwitch as collections of bitwise tests.
669 · Nominal. In statistics, nominal values cannot be usefully
671 compared except for equality. This is true of OpenFlow
672 port numbers, Ethernet types, and IP protocols are exam‐
673 ples: all of these are just identifiers assigned arbi‐
674 trarily with no deeper meaning. In OpenFlow and Open
675 vSwitch, bits in these fields generally aren’t individu‐
676 ally addressable.
677 OVN only supports arithmetic tests for equality on nomi‐
679 nal fields, because OpenFlow and Open vSwitch provide no
680 way for a flow to efficiently implement other comparisons
681 on them. (A test for inequality can be sort of built out
682 of two flows with different priorities, but OVN matching
683 expressions always generate flows with a single prior‐
684 ity.)
685 String fields are always nominal.
687 · Boolean. A nominal field that has only two values, 0 and
689 1, is somewhat exceptional, since it is easy to support
690 both equality and inequality tests on such a field:
691 either one can be implemented as a test for 0 or 1.
692 Only predicates (see above) have a Boolean level of mea‐
694 surement.
695 This isn’t a standard level of measurement.
697 Prerequisites. Any symbol can have prerequisites, which are
699 additional condition implied by the use of the symbol. For exam‐
700 ple, For example, icmp4.type symbol might have prerequisite
701 icmp4, which would cause an expression icmp4.type == 0 to be
702 interpreted as icmp4.type == 0 && icmp4, which would in turn
703 expand to icmp4.type == 0 && eth.type == 0x800 && ip4.proto == 1
704 (assuming icmp4 is a predicate defined as suggested under Types
705 above).
706 Relational operators
708 All of the standard relational operators ==, !=, <, <=, >, and
710 >= are supported. Nominal fields support only == and !=, and
711 only in a positive sense when outer ! are taken into account,
712 e.g. given string field inport, inport == "eth0" and !(inport !=
713 "eth0") are acceptable, but not inport != "eth0".
714 The implementation of == (or != when it is negated), is more
716 efficient than that of the other relational operators.
717 Constants
719 Integer constants may be expressed in decimal, hexadecimal pre‐
721 fixed by 0x, or as dotted-quad IPv4 addresses, IPv6 addresses in
722 their standard forms, or Ethernet addresses as colon-separated
723 hex digits. A constant in any of these forms may be followed by
724 a slash and a second constant (the mask) in the same form, to
725 form a masked constant. IPv4 and IPv6 masks may be given as
726 integers, to express CIDR prefixes.
727 String constants have the same syntax as quoted strings in JSON
729 (thus, they are Unicode strings).
730 Some operators support sets of constants written inside curly
732 braces { ... }. Commas between elements of a set, and after the
733 last elements, are optional. With ==, ``field == { constant1,
734 constant2, ... }’’ is syntactic sugar for ``field == constant1
735 || field == constant2 || .... Similarly, ``field != { constant1,
736 constant2, ... }’’ is equivalent to ``field != constant1 &&
737 field != constant2 && ...’’.
738 You may refer to a set of IPv4, IPv6, or MAC addresses stored in
740 the Address_Set table by its name. An Address_Set with a name of
741 set1 can be referred to as $set1.
742 You may refer to a group of logical switch ports stored in the
744 Port_Group table by its name. An Port_Group with a name of
745 port_group1 can be referred to as @port_group1.
746 Additionally, you may refer to the set of addresses belonging to
748 a group of logical switch ports stored in the Port_Group table
749 by its name followed by a suffix ’_ip4’/’_ip6’. The IPv4 address
750 set of a Port_Group with a name of port_group1 can be referred
751 to as $port_group1_ip4, and the IPv6 address set of the same
752 Port_Group can be referred to as $port_group1_ip6
753 Miscellaneous
755 Comparisons may name the symbol or the constant first, e.g.
757 tcp.src == 80 and 80 == tcp.src are both acceptable.
758 Tests for a range may be expressed using a syntax like 1024 <=
760 tcp.src <= 49151, which is equivalent to 1024 <= tcp.src &&
761 tcp.src <= 49151.
762 For a one-bit field or predicate, a mention of its name is
764 equivalent to symobl == 1, e.g. vlan.present is equivalent to
765 vlan.present == 1. The same is true for one-bit subfields, e.g.
766 vlan.tci[12]. There is no technical limitation to implementing
767 the same for ordinal fields of all widths, but the implementa‐
768 tion is expensive enough that the syntax parser requires writing
769 an explicit comparison against zero to make mistakes less
770 likely, e.g. in tcp.src != 0 the comparison against 0 is
771 required.
772 Operator precedence is as shown below, from highest to lowest.
774 There are two exceptions where parentheses are required even
775 though the table would suggest that they are not: && and ||
776 require parentheses when used together, and ! requires parenthe‐
777 ses when applied to a relational expression. Thus, in (eth.type
778 == 0x800 || eth.type == 0x86dd) && ip.proto == 6 or !(arp.op ==
779 1), the parentheses are mandatory.
780 · ()
782 · == != < <= > >=
784 · !
786 · && ||
788 Comments may be introduced by //, which extends to the next new-
790 line. Comments within a line may be bracketed by /* and */. Mul‐
791 tiline comments are not supported.
792 Symbols
794 Most of the symbols below have integer type. Only inport and
796 outport have string type. inport names a logical port. Thus, its
797 value is a logical_port name from the Port_Binding table. out‐
798 port may name a logical port, as inport, or a logical multicast
799 group defined in the Multicast_Group table. For both symbols,
800 only names within the flow’s logical datapath may be used.
801 The regX symbols are 32-bit integers. The xxregX symbols are
803 128-bit integers, which overlay four of the 32-bit registers:
804 xxreg0 overlays reg0 through reg3, with reg0 supplying the most-
805 significant bits of xxreg0 and reg3 the least-signficant. xxreg1
806 similarly overlays reg4 through reg7.
807 · reg0...reg9
809 · xxreg0 xxreg1
811 · inport outport
813 · flags.loopback
815 · eth.src eth.dst eth.type
817 · vlan.tci vlan.vid vlan.pcp vlan.present
819 · ip.proto ip.dscp ip.ecn ip.ttl ip.frag
821 · ip4.src ip4.dst
823 · ip6.src ip6.dst ip6.label
825 · arp.op arp.spa arp.tpa arp.sha arp.tha
827 · tcp.src tcp.dst tcp.flags
829 · udp.src udp.dst
831 · sctp.src sctp.dst
833 · icmp4.type icmp4.code
835 · icmp6.type icmp6.code
837 · nd.target nd.sll nd.tll
839 · ct_mark ct_label
841 · ct_state, which has several Boolean subfields. The
843 ct_next action initializes the following subfields:
844 · ct.trk: Always set to true by ct_next to indicate
846 that connection tracking has taken place. All
847 other ct subfields have ct.trk as a prerequisite.
848 · ct.new: True for a new flow
850 · ct.est: True for an established flow
852 · ct.rel: True for a related flow
854 · ct.rpl: True for a reply flow
856 · ct.inv: True for a connection entry in a bad state
858 The ct_dnat, ct_snat, and ct_lb actions initialize the
860 following subfields:
861 · ct.dnat: True for a packet whose destination IP
863 address has been changed.
864 · ct.snat: True for a packet whose source IP address
866 has been changed.
867 The following predicates are supported:
869 · eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff
871 · eth.mcast expands to eth.dst[40]
873 · vlan.present expands to vlan.tci[12]
875 · ip4 expands to eth.type == 0x800
877 · ip4.src_mcast expands to ip4.src[28..31] == 0xe
879 · ip4.mcast expands to ip4.dst[28..31] == 0xe
881 · ip6 expands to eth.type == 0x86dd
883 · ip expands to ip4 || ip6
885 · icmp4 expands to ip4 && ip.proto == 1
887 · icmp6 expands to ip6 && ip.proto == 58
889 · icmp expands to icmp4 || icmp6
891 · ip.is_frag expands to ip.frag[0]
893 · ip.later_frag expands to ip.frag[1]
895 · ip.first_frag expands to ip.is_frag && !ip.later_frag
897 · arp expands to eth.type == 0x806
899 · nd expands to icmp6.type == {135, 136} && icmp6.code == 0
901 && ip.ttl == 255
902 · nd_ns expands to icmp6.type == 135 && icmp6.code == 0 &&
904 ip.ttl == 255
905 · nd_na expands to icmp6.type == 136 && icmp6.code == 0 &&
907 ip.ttl == 255
908 · nd_rs expands to icmp6.type == 133 && icmp6.code == 0 &&
910 ip.ttl == 255
911 · nd_ra expands to icmp6.type == 134 && icmp6.code == 0 &&
913 ip.ttl == 255
914 · tcp expands to ip.proto == 6
916 · udp expands to ip.proto == 17
918 · sctp expands to ip.proto == 132
920 actions: string
922 Logical datapath actions, to be executed when the logical flow
923 represented by this row is the highest-priority match.
924 Actions share lexical syntax with the match column. An empty set
926 of actions (or one that contains just white space or comments),
927 or a set of actions that consists of just drop;, causes the
928 matched packets to be dropped. Otherwise, the column should con‐
929 tain a sequence of actions, each terminated by a semicolon.
930 The following actions are defined:
932 output;
934 In the ingress pipeline, this action executes the egress
935 pipeline as a subroutine. If outport names a logical
936 port, the egress pipeline executes once; if it is a mul‐
937 ticast group, the egress pipeline runs once for each log‐
938 ical port in the group.
939 In the egress pipeline, this action performs the actual
941 output to the outport logical port. (In the egress pipe‐
942 line, outport never names a multicast group.)
943 By default, output to the input port is implicitly
945 dropped, that is, output becomes a no-op if outport ==
946 inport. Occasionally it may be useful to override this
947 behavior, e.g. to send an ARP reply to an ARP request; to
948 do so, use flags.loopback = 1 to allow the packet to
949 "hair-pin" back to the input port.
950 next;
952 next(table);
953 next(pipeline=pipeline, table=table);
954 Executes the given logical datapath table in pipeline as a
955 subroutine. The default table is just after the current
956 one. If pipeline is specified, it may be ingress or egress;
957 the default pipeline is the one currently executing.
958 Actions in the ingress pipeline may not use next to jump
959 into the egress pipeline (use the output instead), but
960 transitions in the opposite direction are allowed.
961 field = constant;
963 Sets data or metadata field field to constant value con‐
964 stant, e.g. outport = "vif0"; to set the logical output
965 port. To set only a subset of bits in a field, specify a
966 subfield for field or a masked constant, e.g. one may use
967 vlan.pcp[2] = 1; or vlan.pcp = 4/4; to set the most sigifi‐
968 cant bit of the VLAN PCP.
969 Assigning to a field with prerequisites implicitly adds
971 those prerequisites to match; thus, for example, a flow
972 that sets tcp.dst applies only to TCP flows, regardless of
973 whether its match mentions any TCP field.
974 Not all fields are modifiable (e.g. eth.type and ip.proto
976 are read-only), and not all modifiable fields may be par‐
977 tially modified (e.g. ip.ttl must assigned as a whole). The
978 outport field is modifiable in the ingress pipeline but not
979 in the egress pipeline.
980 ovn_field = constant;
982 Sets OVN field ovn_field to constant value constant.
983 OVN supports setting the values of certain fields which are
985 not yet supported in OpenFlow to set or modify them.
986 Below are the supported OVN fields:
988 · icmp4.frag_mtu
990 This field sets the low-order 16 bits of the ICMP4
992 header field that is labelled "unused" in the ICMP
993 specification as defined in the RFC 1191 with the
994 value specified in constant.
995 Eg. icmp4.frag_mtu = 1500;
997 field1 = field2;
999 Sets data or metadata field field1 to the value of data or
1000 metadata field field2, e.g. reg0 = ip4.src; copies ip4.src
1001 into reg0. To modify only a subset of a field’s bits, spec‐
1002 ify a subfield for field1 or field2 or both, e.g. vlan.pcp
1003 = reg0[0..2]; copies the least-significant bits of reg0
1004 into the VLAN PCP.
1005 field1 and field2 must be the same type, either both string
1007 or both integer fields. If they are both integer fields,
1008 they must have the same width.
1009 If field1 or field2 has prerequisites, they are added
1011 implicitly to match. It is possible to write an assignment
1012 with contradictory prerequisites, such as ip4.src =
1013 ip6.src[0..31];, but the contradiction means that a logical
1014 flow with such an assignment will never be matched.
1015 field1 <-> field2;
1017 Similar to field1 = field2; except that the two values are
1018 exchanged instead of copied. Both field1 and field2 must
1019 modifiable.
1020 ip.ttl--;
1022 Decrements the IPv4 or IPv6 TTL. If this would make the TTL
1023 zero or negative, then processing of the packet halts; no
1024 further actions are processed. (To properly handle such
1025 cases, a higher-priority flow should match on ip.ttl == {0,
1026 1};.)
1027 Prerequisite: ip
1029 ct_next;
1031 Apply connection tracking to the flow, initializing
1032 ct_state for matching in later tables. Automatically moves
1033 on to the next table, as if followed by next.
1034 As a side effect, IP fragments will be reassembled for
1036 matching. If a fragmented packet is output, then it will be
1037 sent with any overlapping fragments squashed. The connec‐
1038 tion tracking state is scoped by the logical port when the
1039 action is used in a flow for a logical switch, so overlap‐
1040 ping addresses may be used. To allow traffic related to the
1041 matched flow, execute ct_commit . Connection tracking state
1042 is scoped by the logical topology when the action is used
1043 in a flow for a router.
1044 It is possible to have actions follow ct_next, but they
1046 will not have access to any of its side-effects and is not
1047 generally useful.
1048 ct_commit;
1050 ct_commit(ct_mark=value[/mask]);
1051 ct_commit(ct_label=value[/mask]);
1052 ct_commit(ct_mark=value[/mask], ct_label=value[/mask]);
1053 Commit the flow to the connection tracking entry associated
1054 with it by a previous call to ct_next. When
1055 ct_mark=value[/mask] and/or ct_label=value[/mask] are sup‐
1056 plied, ct_mark and/or ct_label will be set to the values
1057 indicated by value[/mask] on the connection tracking entry.
1058 ct_mark is a 32-bit field. ct_label is a 128-bit field. The
1059 value[/mask] should be specified in hex string if more than
1060 64bits are to be used.
1061 Note that if you want processing to continue in the next
1063 table, you must execute the next action after ct_commit.
1064 You may also leave out next which will commit connection
1065 tracking state, and then drop the packet. This could be
1066 useful for setting ct_mark on a connection tracking entry
1067 before dropping a packet, for example.
1068 ct_dnat;
1070 ct_dnat(IP);
1071 ct_dnat sends the packet through the DNAT zone in connec‐
1072 tion tracking table to unDNAT any packet that was DNATed in
1073 the opposite direction. The packet is then automatically
1074 sent to to the next tables as if followed by next; action.
1075 The next tables will see the changes in the packet caused
1076 by the connection tracker.
1077 ct_dnat(IP) sends the packet through the DNAT zone to
1079 change the destination IP address of the packet to the one
1080 provided inside the parentheses and commits the connection.
1081 The packet is then automatically sent to the next tables as
1082 if followed by next; action. The next tables will see the
1083 changes in the packet caused by the connection tracker.
1084 ct_snat;
1086 ct_snat(IP);
1087 ct_snat sends the packet through the SNAT zone to unSNAT
1088 any packet that was SNATed in the opposite direction. The
1089 packet is automatically sent to the next tables as if fol‐
1090 lowed by the next; action. The next tables will see the
1091 changes in the packet caused by the connection tracker.
1092 ct_snat(IP) sends the packet through the SNAT zone to
1094 change the source IP address of the packet to the one pro‐
1095 vided inside the parenthesis and commits the connection.
1096 The packet is then automatically sent to the next tables as
1097 if followed by next; action. The next tables will see the
1098 changes in the packet caused by the connection tracker.
1099 ct_clear;
1101 Clears connection tracking state.
1102 clone { action; ... };
1104 Makes a copy of the packet being processed and executes
1105 each action on the copy. Actions following the clone
1106 action, if any, apply to the original, unmodified packet.
1107 This can be used as a way to ``save and restore’’ the
1108 packet around a set of actions that may modify it and
1109 should not persist.
1110 arp { action; ... };
1112 Temporarily replaces the IPv4 packet being processed by an
1113 ARP packet and executes each nested action on the ARP
1114 packet. Actions following the arp action, if any, apply to
1115 the original, unmodified packet.
1116 The ARP packet that this action operates on is initialized
1118 based on the IPv4 packet being processed, as follows. These
1119 are default values that the nested actions will probably
1120 want to change:
1121 · eth.src unchanged
1123 · eth.dst unchanged
1125 · eth.type = 0x0806
1127 · arp.op = 1 (ARP request)
1129 · arp.sha copied from eth.src
1131 · arp.spa copied from ip4.src
1133 · arp.tha = 00:00:00:00:00:00
1135 · arp.tpa copied from ip4.dst
1137 The ARP packet has the same VLAN header, if any, as the IP
1139 packet it replaces.
1140 Prerequisite: ip4
1142 get_arp(P, A);
1144 Parameters: logical port string field P, 32-bit IP address
1145 field A.
1146 Looks up A in P’s mac binding table. If an entry is found,
1148 stores its Ethernet address in eth.dst, otherwise stores
1149 00:00:00:00:00:00 in eth.dst.
1150 Example: get_arp(outport, ip4.dst);
1152 put_arp(P, A, E);
1154 Parameters: logical port string field P, 32-bit IP address
1155 field A, 48-bit Ethernet address field E.
1156 Adds or updates the entry for IP address A in logical port
1158 P’s mac binding table, setting its Ethernet address to E.
1159 Example: put_arp(inport, arp.spa, arp.sha);
1161 R = lookup_arp(P, A, M);
1163 Parameters: logical port string field P, 32-bit IP address
1164 field A, 48-bit MAC address field M.
1165 Result: stored to a 1-bit subfield R.
1167 Looks up A and M in P’s mac binding table. If an entry is
1169 found, stores 1 in the 1-bit subfield R, else 0.
1170 Example: reg0[0] = lookup_arp(inport, arp.spa, arp.sha);
1172 nd_ns { action; ... };
1174 Temporarily replaces the IPv6 packet being processed by an
1175 IPv6 Neighbor Solicitation packet and executes each nested
1176 action on the IPv6 NS packet. Actions following the nd_ns
1177 action, if any, apply to the original, unmodified packet.
1178 The IPv6 NS packet that this action operates on is initial‐
1180 ized based on the IPv6 packet being processed, as follows.
1181 These are default values that the nested actions will prob‐
1182 ably want to change:
1183 · eth.src unchanged
1185 · eth.dst set to IPv6 multicast MAC address
1187 · eth.type = 0x86dd
1189 · ip6.src copied from ip6.src
1191 · ip6.dst set to IPv6 Solicited-Node multicast address
1193 · icmp6.type = 135 (Neighbor Solicitation)
1195 · nd.target copied from ip6.dst
1197 The IPv6 NS packet has the same VLAN header, if any, as the
1199 IP packet it replaces.
1200 Prerequisite: ip6
1202 nd_na { action; ... };
1204 Temporarily replaces the IPv6 neighbor solicitation packet
1205 being processed by an IPv6 neighbor advertisement (NA)
1206 packet and executes each nested action on the NA packet.
1207 Actions following the nd_na action, if any, apply to the
1208 original, unmodified packet.
1209 The NA packet that this action operates on is initialized
1211 based on the IPv6 packet being processed, as follows. These
1212 are default values that the nested actions will probably
1213 want to change:
1214 · eth.dst exchanged with eth.src
1216 · eth.type = 0x86dd
1218 · ip6.dst copied from ip6.src
1220 · ip6.src copied from nd.target
1222 · icmp6.type = 136 (Neighbor Advertisement)
1224 · nd.target unchanged
1226 · nd.sll = 00:00:00:00:00:00
1228 · nd.tll copied from eth.dst
1230 The ND packet has the same VLAN header, if any, as the IPv6
1232 packet it replaces.
1233 Prerequisite: nd_ns
1235 nd_na_router { action; ... };
1237 Temporarily replaces the IPv6 neighbor solicitation packet
1238 being processed by an IPv6 neighbor advertisement (NA)
1239 packet, sets ND_NSO_ROUTER in the RSO flags and executes
1240 each nested action on the NA packet. Actions following the
1241 nd_na_router action, if any, apply to the original, unmodi‐
1242 fied packet.
1243 The NA packet that this action operates on is initialized
1245 based on the IPv6 packet being processed, as follows. These
1246 are default values that the nested actions will probably
1247 want to change:
1248 · eth.dst exchanged with eth.src
1250 · eth.type = 0x86dd
1252 · ip6.dst copied from ip6.src
1254 · ip6.src copied from nd.target
1256 · icmp6.type = 136 (Neighbor Advertisement)
1258 · nd.target unchanged
1260 · nd.sll = 00:00:00:00:00:00
1262 · nd.tll copied from eth.dst
1264 The ND packet has the same VLAN header, if any, as the IPv6
1266 packet it replaces.
1267 Prerequisite: nd_ns
1269 get_nd(P, A);
1271 Parameters: logical port string field P, 128-bit IPv6
1272 address field A.
1273 Looks up A in P’s mac binding table. If an entry is found,
1275 stores its Ethernet address in eth.dst, otherwise stores
1276 00:00:00:00:00:00 in eth.dst.
1277 Example: get_nd(outport, ip6.dst);
1279 put_nd(P, A, E);
1281 Parameters: logical port string field P, 128-bit IPv6
1282 address field A, 48-bit Ethernet address field E.
1283 Adds or updates the entry for IPv6 address A in logical
1285 port P’s mac binding table, setting its Ethernet address to
1286 E.
1287 Example: put_nd(inport, nd.target, nd.tll);
1289 R = lookup_nd(P, A, M);
1291 Parameters: logical port string field P, 128-bit IP address
1292 field A, 48-bit MAC address field M.
1293 Result: stored to a 1-bit subfield R.
1295 Looks up A and M in P’s mac binding table. If an entry is
1297 found, stores 1 in the 1-bit subfield R, else 0.
1298 Example: reg0[0] = lookup_nd(inport, ip6.src, eth.src);
1300 R = put_dhcp_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1302 Parameters: one or more DHCP option/value pairs, which must
1303 include an offerip option (with code 0).
1304 Result: stored to a 1-bit subfield R.
1306 Valid only in the ingress pipeline.
1308 When this action is applied to a DHCP request packet
1310 (DHCPDISCOVER or DHCPREQUEST), it changes the packet into a
1311 DHCP reply (DHCPOFFER or DHCPACK, respectively), replaces
1312 the options by those specified as parameters, and stores 1
1313 in R.
1314 When this action is applied to a non-DHCP packet or a DHCP
1316 packet that is not DHCPDISCOVER or DHCPREQUEST, it leaves
1317 the packet unchanged and stores 0 in R.
1318 The contents of the DHCP_Option table control the DHCP
1320 option names and values that this action supports.
1321 Example: reg0[0] = put_dhcp_opts(offerip = 10.0.0.2, router
1323 = 10.0.0.1, netmask = 255.255.255.0, dns_server = {8.8.8.8,
1324 7.7.7.7});
1325 R = put_dhcpv6_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1327 Parameters: one or more DHCPv6 option/value pairs.
1328 Result: stored to a 1-bit subfield R.
1330 Valid only in the ingress pipeline.
1332 When this action is applied to a DHCPv6 request packet, it
1334 changes the packet into a DHCPv6 reply, replaces the
1335 options by those specified as parameters, and stores 1 in
1336 R.
1337 When this action is applied to a non-DHCPv6 packet or an
1339 invalid DHCPv6 request packet , it leaves the packet
1340 unchanged and stores 0 in R.
1341 The contents of the DHCPv6_Options table control the DHCPv6
1343 option names and values that this action supports.
1344 Example: reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4,
1346 server_id = 00:00:00:00:10:02,
1347 dns_server={ae70::1,ae70::2});
1348 set_queue(queue_number);
1350 Parameters: Queue number queue_number, in the range 0 to
1351 61440.
1352 This is a logical equivalent of the OpenFlow set_queue
1354 action. It affects packets that egress a hypervisor through
1355 a physical interface. For nonzero queue_number, it config‐
1356 ures packet queuing to match the settings configured for
1357 the Port_Binding with options:qdisc_queue_id matching
1358 queue_number. When queue_number is zero, it resets queuing
1359 to the default strategy.
1360 Example: set_queue(10);
1362 ct_lb;
1364 ct_lb(ip[:port]...);
1365 With one or more arguments, ct_lb commits the packet to the
1366 connection tracking table and DNATs the packet’s destina‐
1367 tion IP address (and port) to the IP address or addresses
1368 (and optional ports) specified in the string. If multiple
1369 comma-separated IP addresses are specified, each is given
1370 equal weight for picking the DNAT address. Processing auto‐
1371 matically moves on to the next table, as if next; were
1372 specified, and later tables act on the packet as modified
1373 by the connection tracker. Connection tracking state is
1374 scoped by the logical port when the action is used in a
1375 flow for a logical switch, so overlapping addresses may be
1376 used. Connection tracking state is scoped by the logical
1377 topology when the action is used in a flow for a router.
1378 Without arguments, ct_lb sends the packet to the connection
1380 tracking table to NAT the packets. If the packet is part of
1381 an established connection that was previously committed to
1382 the connection tracker via ct_lb(...), it will automati‐
1383 cally get DNATed to the same IP address as the first packet
1384 in that connection.
1385 R = dns_lookup();
1387 Parameters: No parameters.
1388 Result: stored to a 1-bit subfield R.
1390 Valid only in the ingress pipeline.
1392 When this action is applied to a valid DNS request (a UDP
1394 packet typically directed to port 53), it attempts to
1395 resolve the query using the contents of the DNS table. If
1396 it is successful, it changes the packet into a DNS reply
1397 and stores 1 in R. If the action is applied to a non-DNS
1398 packet, an invalid DNS request packet, or a valid DNS
1399 request for which the DNS table does not supply an answer,
1400 it leaves the packet unchanged and stores 0 in R.
1401 Regardless of success, the action does not make any of the
1403 changes to the flow that are necessary to direct the packet
1404 back to the requester. The logical pipeline can implement
1405 this behavior with matches and actions in later tables.
1406 Example: reg0[3] = dns_lookup();
1408 Prerequisite: udp
1410 R = put_nd_ra_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1412 Parameters: The following IPv6 ND Router Advertisement
1413 option/value pairs as defined in RFC 4861.
1414 · addr_mode
1416 Mandatory parameter which specifies the address mode
1418 flag to be set in the RA flag options field. The
1419 value of this option is a string and the following
1420 values can be defined - "slaac", "dhcpv6_stateful"
1421 and "dhcpv6_stateless".
1422 · slla
1424 Mandatory parameter which specifies the link-layer
1426 address of the interface from which the Router
1427 Advertisement is sent.
1428 · mtu
1430 Optional parameter which specifies the MTU.
1432 · prefix
1434 Optional parameter which should be specified if the
1436 addr_mode is "slaac" or "dhcpv6_stateless". The
1437 value should be an IPv6 prefix which will be used
1438 for stateless IPv6 address configuration. This
1439 option can be defined multiple times.
1440 Result: stored to a 1-bit subfield R.
1442 Valid only in the ingress pipeline.
1444 When this action is applied to an IPv6 Router solicitation
1446 request packet, it changes the packet into an IPv6 Router
1447 Advertisement reply and adds the options specified in the
1448 parameters, and stores 1 in R.
1449 When this action is applied to a non-IPv6 Router solicita‐
1451 tion packet or an invalid IPv6 request packet , it leaves
1452 the packet unchanged and stores 0 in R.
1453 Example: reg0[3] = put_nd_ra_opts(addr_mode = "slaac", slla
1455 = 00:00:00:00:10:02, prefix = aef0::/64, mtu = 1450);
1456 set_meter(rate);
1458 set_meter(rate, burst);
1459 Parameters: rate limit int field rate in kbps, burst rate
1460 limits int field burst in kbps.
1461 This action sets the rate limit for a flow.
1463 Example: set_meter(100, 1000);
1465 R = check_pkt_larger(L)
1467 Parameters: packet length L to check for in bytes.
1468 Result: stored to a 1-bit subfield R.
1470 This is a logical equivalent of the OpenFlow
1472 check_pkt_larger action. If the packet is larger than the
1473 length specified in L, it stores 1 in the subfield R.
1474 Example: reg0[6] = check_pkt_larger(1000);
1476 log(key=value, ...);
1478 Causes ovn-controller to log the packet on the chassis
1479 that processes it. Packet logging currently uses the same
1480 logging mechanism as other Open vSwitch and OVN messages,
1481 which means that whether and where log messages appear
1482 depends on the local logging configuration that can be
1483 configured with ovs-appctl, etc.
1484 The log action takes zero or more of the following key-
1486 value pair arguments that control what is logged:
1487 name=string
1489 An optional name for the ACL. The string is cur‐
1490 rently limited to 64 bytes.
1491 severity=level
1493 Indicates the severity of the event. The level is
1494 one of following (from more to less serious):
1495 alert, warning, notice, info, or debug. If a
1496 severity is not provided, the default is info.
1497 verdict=value
1499 The verdict for packets matching the flow. The
1500 value must be one of allow, deny, or reject.
1501 meter=string
1503 An optional rate-limiting meter to be applied to
1504 the logs. The string should reference a name entry
1505 from the Meter table. The only meter action that
1506 is appriopriate is drop.
1507 icmp4 { action; ... };
1509 icmp4_error { action; ... };
1510 Temporarily replaces the IPv4 packet being processed by an
1511 ICMPv4 packet and executes each nested action on the ICMPv4
1512 packet. Actions following these actions, if any, apply to
1513 the original, unmodified packet.
1514 The ICMPv4 packet that these actions operates on is ini‐
1516 tialized based on the IPv4 packet being processed, as fol‐
1517 lows. These are default values that the nested actions will
1518 probably want to change. Ethernet and IPv4 fields not
1519 listed here are not changed:
1520 · ip.proto = 1 (ICMPv4)
1522 · ip.frag = 0 (not a fragment)
1524 · ip.ttl = 255
1526 · icmp4.type = 3 (destination unreachable)
1528 · icmp4.code = 1 (host unreachable)
1530 icmp4_error action is expected to be used to generate an
1532 ICMPv4 packet in response to an error in original IP
1533 packet. When this action generates the ICMPv4 packet, it
1534 also copies the original IP datagram following the ICMPv4
1535 header as per RFC 1122: 3.2.2.
1536 Prerequisite: ip4
1538 icmp6 { action; ... };
1540 Temporarily replaces the IPv6 packet being processed by an
1541 ICMPv6 packet and executes each nested action on the ICMPv6
1542 packet. Actions following the icmp6 action, if any, apply
1543 to the original, unmodified packet.
1544 The ICMPv6 packet that this action operates on is initial‐
1546 ized based on the IPv6 packet being processed, as follows.
1547 These are default values that the nested actions will prob‐
1548 ably want to change. Ethernet and IPv6 fields not listed
1549 here are not changed:
1550 · ip.proto = 58 (ICMPv6)
1552 · ip.ttl = 255
1554 · icmp6.type = 1 (destination unreachable)
1556 · icmp6.code = 1 (administratively prohibited)
1558 Prerequisite: ip6
1560 tcp_reset;
1562 This action transforms the current TCP packet according to
1563 the following pseudocode:
1564 if (tcp.ack) {
1566 tcp.seq = tcp.ack;
1567 } else {
1568 tcp.ack = tcp.seq + length(tcp.payload);
1569 tcp.seq = 0;
1570 }
1571 tcp.flags = RST;
1572 Then, the action drops all TCP options and payload data,
1574 and updates the TCP checksum. IP ttl is set to 255.
1575 Prerequisite: tcp
1577 trigger_event;
1579 This action is used to allow ovs-vswitchd to report CMS
1580 related events writing them in Controller_Event table. It
1581 is possible to associate a meter to a each event in order
1582 to not overload pinctrl thread under heavy load; each meter
1583 is identified though a defined naming convention. Supported
1584 events:
1585 · empty_lb_backends. This event is raised if a
1587 received packet is destined for a load balancer VIP
1588 that has no configured backend destinations. For
1589 this event, the event info includes the load bal‐
1590 ancer VIP, the load balancer UUID, and the transport
1591 protocol. Associated meter: event-elb
1592 igmp;
1594 This action sends the packet to ovn-controller for multi‐
1595 cast snooping.
1596 Prerequisite: igmp
1598 bind_vport(V, P);
1600 Parameters: logical port string field V of type virtual,
1601 logical port string field P.
1602 Binds the virtual logical port V and sets the chassis col‐
1604 umn and virtual_parent of the table Port_Binding. vir‐
1605 tual_parent is set to P.
1606 external_ids : stage-name: optional string
1608 Human-readable name for this flow’s stage in the pipeline.
1609 external_ids : stage-hint: optional string, containing an uuid
1611 UUID of a OVN_Northbound record that caused this logical flow to
1612 be created. Currently used only for attribute of logical flows
1613 to northbound ACL records.
1614 external_ids : source: optional string
1616 Source file and line number of the code that added this flow to
1617 the pipeline.
1618 Common Columns:
1620 The overall purpose of these columns is described under Common Columns
1622 at the beginning of this document.
1623 external_ids: map of string-string pairs
1625
1627 The rows in this table define multicast groups of logical ports. Multi‐
1628 cast groups allow a single packet transmitted over a tunnel to a hyper‐
1629 visor to be delivered to multiple VMs on that hypervisor, which uses
1630 bandwidth more efficiently.
1631 Each row in this table defines a logical multicast group numbered tun‐
1633 nel_key within datapath, whose logical ports are listed in the ports
1634 column.
1635 Summary:
1637 datapath Datapath_Binding
1638 tunnel_key integer, in range 32,768 to 65,535
1639 name string
1640 ports set of 1 or more weak reference to
1641 Port_Bindings
1642 Details:
1644 datapath: Datapath_Binding
1645 The logical datapath in which the multicast group resides.
1646 tunnel_key: integer, in range 32,768 to 65,535
1648 The value used to designate this logical egress port in tunnel
1649 encapsulations. An index forces the key to be unique within the
1650 datapath. The unusual range ensures that multicast group IDs do
1651 not overlap with logical port IDs.
1652 name: string
1654 The logical multicast group’s name. An index forces the name to
1655 be unique within the datapath. Logical flows in the ingress
1656 pipeline may output to the group just as for individual logical
1657 ports, by assigning the group’s name to outport and executing an
1658 output action.
1659 Multicast group names and logical port names share a single
1661 namespace and thus should not overlap (but the database schema
1662 cannot enforce this). To try to avoid conflicts, ovn-northd uses
1663 names that begin with _MC_.
1664 ports: set of 1 or more weak reference to Port_Bindings
1666 The logical ports included in the multicast group. All of these
1667 ports must be in the datapath logical datapath (but the database
1668 schema cannot enforce this).
1669
1671 Each row in this table represents a meter that can be used for QoS or
1672 rate-limiting.
1673 Summary:
1675 name string (must be unique within table)
1676 unit string, either kbps or pktps
1677 bands set of 1 or more Meter_Bands
1678 Details:
1680 name: string (must be unique within table)
1681 A name for this meter.
1682 Names that begin with "__" (two underscores) are reserved for
1684 OVN internal use and should not be added manually.
1685 unit: string, either kbps or pktps
1687 The unit for rate and burst_rate parameters in the bands entry.
1688 kbps specifies kilobits per second, and pktps specifies packets
1689 per second.
1690 bands: set of 1 or more Meter_Bands
1692 The bands associated with this meter. Each band specifies a rate
1693 above which the band is to take the action action. If multiple
1694 bands’ rates are exceeded, then the band with the highest rate
1695 among the exceeded bands is selected.
1696
1698 Each row in this table represents a meter band which specifies the rate
1699 above which the configured action should be applied. These bands are
1700 referenced by the bands column in the Meter table.
1701 Summary:
1703 action string, must be drop
1704 rate integer, in range 1 to 4,294,967,295
1705 burst_size integer, in range 0 to 4,294,967,295
1706 Details:
1708 action: string, must be drop
1709 The action to execute when this band matches. The only supported
1710 action is drop.
1711 rate: integer, in range 1 to 4,294,967,295
1713 The rate limit for this band, in kilobits per second or bits per
1714 second, depending on whether the parent Meter entry’s unit col‐
1715 umn specified kbps or pktps.
1716 burst_size: integer, in range 0 to 4,294,967,295
1718 The maximum burst allowed for the band in kilobits or packets,
1719 depending on whether kbps or pktps was selected in the parent
1720 Meter entry’s unit column. If the size is zero, the switch is
1721 free to select some reasonable value depending on its configura‐
1722 tion.
1723
1725 Each row in this table represents a logical datapath, which implements
1726 a logical pipeline among the ports in the Port_Binding table associated
1727 with it. In practice, the pipeline in a given logical datapath imple‐
1728 ments either a logical switch or a logical router.
1729 The main purpose of a row in this table is provide a physical binding
1731 for a logical datapath. A logical datapath does not have a physical
1732 location, so its physical binding information is limited: just tun‐
1733 nel_key. The rest of the data in this table does not affect packet for‐
1734 warding.
1735 Summary:
1737 tunnel_key integer, in range 1 to 16,777,215 (must
1738 be unique within table)
1739 OVN_Northbound Relationship:
1740 external_ids : logical-switch
1741 optional string, containing an uuid
1742 external_ids : logical-router
1743 optional string, containing an uuid
1744 Naming:
1745 external_ids : name optional string
1746 external_ids : name2 optional string
1747 Common Columns:
1748 external_ids map of string-string pairs
1749 Details:
1751 tunnel_key: integer, in range 1 to 16,777,215 (must be unique within
1752 table)
1753 The tunnel key value to which the logical datapath is bound. The
1754 Tunnel Encapsulation section in ovn-architecture(7) describes
1755 how tunnel keys are constructed for each supported encapsula‐
1756 tion.
1757 OVN_Northbound Relationship:
1759 Each row in Datapath_Binding is associated with some logical datapath.
1761 ovn-northd uses these keys to track the association of a logical data‐
1762 path with concepts in the OVN_Northbound database.
1763 external_ids : logical-switch: optional string, containing an uuid
1765 For a logical datapath that represents a logical switch,
1766 ovn-northd stores in this key the UUID of the corresponding Log‐
1767 ical_Switch row in the OVN_Northbound database.
1768 external_ids : logical-router: optional string, containing an uuid
1770 For a logical datapath that represents a logical router,
1771 ovn-northd stores in this key the UUID of the corresponding Log‐
1772 ical_Router row in the OVN_Northbound database.
1773 Naming:
1775 ovn-northd copies these from the name fields in the OVN_Northbound
1777 database, either from name and external_ids:neutron:router_name in the
1778 Logical_Router table or from name and external_ids:neutron:network_name
1779 in the Logical_Switch table.
1780 external_ids : name: optional string
1782 A name for the logical datapath.
1783 external_ids : name2: optional string
1785 Another name for the logical datapath.
1786 Common Columns:
1788 The overall purpose of these columns is described under Common Columns
1790 at the beginning of this document.
1791 external_ids: map of string-string pairs
1793
1795 Each row in this table binds a logical port to a realization. For most
1796 logical ports, this means binding to some physical location, for exam‐
1797 ple by binding a logical port to a VIF that belongs to a VM running on
1798 a particular hypervisor. Other logical ports, such as logical patch
1799 ports, can be realized without a specific physical location, but their
1800 bindings are still expressed through rows in this table.
1801 For every Logical_Switch_Port record in OVN_Northbound database,
1803 ovn-northd creates a record in this table. ovn-northd populates and
1804 maintains every column except the chassis column, which it leaves empty
1805 in new records.
1806 ovn-controller/ovn-controller-vtep populates the chassis column for the
1808 records that identify the logical ports that are located on its hyper‐
1809 visor/gateway, which ovn-controller/ovn-controller-vtep in turn finds
1810 out by monitoring the local hypervisor’s Open_vSwitch database, which
1811 identifies logical ports via the conventions described in Integra‐
1812 tionGuide.rst. (The exceptions are for Port_Binding records with type
1813 of l3gateway, whose locations are identified by ovn-northd via the
1814 options:l3gateway-chassis column in this table. ovn-controller is still
1815 responsible to populate the chassis column.)
1816 When a chassis shuts down gracefully, it should clean up the chassis
1818 column that it previously had populated. (This is not critical because
1819 resources hosted on the chassis are equally unreachable regardless of
1820 whether their rows are present.) To handle the case where a VM is shut
1821 down abruptly on one chassis, then brought up again on a different one,
1822 ovn-controller/ovn-controller-vtep must overwrite the chassis column
1823 with new information.
1824 Summary:
1826 Core Features:
1827 datapath Datapath_Binding
1828 logical_port string (must be unique within table)
1829 encap optional weak reference to Encap
1830 chassis optional weak reference to Chassis
1831 gateway_chassis set of Gateway_Chassiss
1832 ha_chassis_group optional HA_Chassis_Group
1833 tunnel_key integer, in range 1 to 32,767
1834 mac set of strings
1835 type string
1836 Patch Options:
1837 options : peer optional string
1838 nat_addresses set of strings
1839 L3 Gateway Options:
1840 options : peer optional string
1841 options : l3gateway-chassis
1842 optional string
1843 options : nat-addresses optional string
1844 nat_addresses set of strings
1845 Localnet Options:
1846 options : network_name optional string
1847 tag optional integer, in range 1 to 4,095
1848 L2 Gateway Options:
1849 options : network_name optional string
1850 options : l2gateway-chassis
1851 optional string
1852 tag optional integer, in range 1 to 4,095
1853 VTEP Options:
1854 options : vtep-physical-switch
1855 optional string
1856 options : vtep-logical-switch
1857 optional string
1858 VMI (or VIF) Options:
1859 options : requested-chassis
1860 optional string
1861 options : qos_max_rate optional string
1862 options : qos_burst optional string
1863 options : qdisc_queue_id optional string, containing an integer,
1864 in range 1 to 61,440
1865 Chassis Redirect Options:
1866 options : distributed-port optional string
1867 options : redirect-chassis optional string
1868 Nested Containers:
1869 parent_port optional string
1870 tag optional integer, in range 1 to 4,095
1871 Virtual ports:
1872 virtual_parent optional string
1873 Naming:
1874 external_ids : name optional string
1875 Common Columns:
1876 external_ids map of string-string pairs
1877 Details:
1879 Core Features:
1880 datapath: Datapath_Binding
1882 The logical datapath to which the logical port belongs.
1883 logical_port: string (must be unique within table)
1885 A logical port, taken from name in the OVN_Northbound database’s
1886 Logical_Switch_Port table. OVN does not prescribe a particular
1887 format for the logical port ID.
1888 encap: optional weak reference to Encap
1890 Points to supported encapsulation configurations to transmit
1891 logical dataplane packets to this chassis. Each entry is a Encap
1892 record that describes the configuration.
1893 chassis: optional weak reference to Chassis
1895 The meaning of this column depends on the value of the type col‐
1896 umn. This is the meaning for each type
1897 (empty string)
1899 The physical location of the logical port. To success‐
1900 fully identify a chassis, this column must be a Chassis
1901 record. This is populated by ovn-controller.
1902 vtep The physical location of the hardware_vtep gateway. To
1904 successfully identify a chassis, this column must be a
1905 Chassis record. This is populated by ovn-controller-vtep.
1906 localnet
1908 Always empty. A localnet port is realized on every chas‐
1909 sis that has connectivity to the corresponding physical
1910 network.
1911 localport
1913 Always empty. A localport port is present on every chas‐
1914 sis.
1915 l3gateway
1917 The physical location of the L3 gateway. To successfully
1918 identify a chassis, this column must be a Chassis record.
1919 This is populated by ovn-controller based on the value of
1920 the options:l3gateway-chassis column in this table.
1921 l2gateway
1923 The physical location of this L2 gateway. To successfully
1924 identify a chassis, this column must be a Chassis record.
1925 This is populated by ovn-controller based on the value of
1926 the options:l2gateway-chassis column in this table.
1927 gateway_chassis: set of Gateway_Chassiss
1929 A list of Gateway_Chassis.
1930 This should only be populated for ports with type set to chas‐
1932 sisredirect. This column defines the list of chassis used as
1933 gateways where traffic will be redirected through.
1934 ha_chassis_group: optional HA_Chassis_Group
1936 This should only be populated for ports with type set to chas‐
1937 sisredirect. This column defines the HA chassis group with a
1938 list of HA chassis used as gateways where traffic will be redi‐
1939 rected through.
1940 tunnel_key: integer, in range 1 to 32,767
1942 A number that represents the logical port in the key (e.g. STT
1943 key or Geneve TLV) field carried within tunnel protocol packets.
1944 The tunnel ID must be unique within the scope of a logical data‐
1946 path.
1947 mac: set of strings
1949 The Ethernet address or addresses used as a source address on
1950 the logical port, each in the form xx:xx:xx:xx:xx:xx. The string
1951 unknown is also allowed to indicate that the logical port has an
1952 unknown set of (additional) source addresses.
1953 A VM interface would ordinarily have a single Ethernet address.
1955 A gateway port might initially only have unknown, and then add
1956 MAC addresses to the set as it learns new source addresses.
1957 type: string
1959 A type for this logical port. Logical ports can be used to model
1960 other types of connectivity into an OVN logical switch. The fol‐
1961 lowing types are defined:
1962 (empty string)
1964 VM (or VIF) interface.
1965 patch One of a pair of logical ports that act as if connected
1967 by a patch cable. Useful for connecting two logical data‐
1968 paths, e.g. to connect a logical router to a logical
1969 switch or to another logical router.
1970 l3gateway
1972 One of a pair of logical ports that act as if connected
1973 by a patch cable across multiple chassis. Useful for con‐
1974 necting a logical switch with a Gateway router (which is
1975 only resident on a particular chassis).
1976 localnet
1978 A connection to a locally accessible network from each
1979 ovn-controller instance. A logical switch can only have a
1980 single localnet port attached. This is used to model
1981 direct connectivity to an existing network.
1982 localport
1984 A connection to a local VIF. Traffic that arrives on a
1985 localport is never forwarded over a tunnel to another
1986 chassis. These ports are present on every chassis and
1987 have the same address in all of them. This is used to
1988 model connectivity to local services that run on every
1989 hypervisor.
1990 l2gateway
1992 An L2 connection to a physical network. The chassis this
1993 Port_Binding is bound to will serve as an L2 gateway to
1994 the network named by options:network_name.
1995 vtep A port to a logical switch on a VTEP gateway chassis. In
1997 order to get this port correctly recognized by the OVN
1998 controller, the options:vtep-physical-switch and
1999 options:vtep-logical-switch must also be defined.
2000 chassisredirect
2002 A logical port that represents a particular instance,
2003 bound to a specific chassis, of an otherwise distributed
2004 parent port (e.g. of type patch). A chassisredirect port
2005 should never be used as an inport. When an ingress pipe‐
2006 line sets the outport, it may set the value to a logical
2007 port of type chassisredirect. This will cause the packet
2008 to be directed to a specific chassis to carry out the
2009 egress pipeline. At the beginning of the egress pipeline,
2010 the outport will be reset to the value of the distributed
2011 port.
2012 virtual
2014 Represents a logical port with an virtual ip. This vir‐
2015 tual ip can be configured on a logical port (which is
2016 refered as virtual parent).
2017 Patch Options:
2019 These options apply to logical ports with type of patch.
2021 options : peer: optional string
2023 The logical_port in the Port_Binding record for the other side
2024 of the patch. The named logical_port must specify this logi‐
2025 cal_port in its own peer option. That is, the two patch logical
2026 ports must have reversed logical_port and peer values.
2027 nat_addresses: set of strings
2029 MAC address followed by a list of SNAT and DNAT external IP
2030 addresses, followed by is_chassis_resident("lport"), where lport
2031 is the name of a logical port on the same chassis where the cor‐
2032 responding NAT rules are applied. This is used to send gratu‐
2033 itous ARPs for SNAT and DNAT external IP addresses via localnet,
2034 from the chassis where lport resides. Example: 80:fa:5b:06:72:b7
2035 158.36.44.22 158.36.44.24 is_chassis_resident("foo1"). This
2036 would result in generation of gratuitous ARPs for IP addresses
2037 158.36.44.22 and 158.36.44.24 with a MAC address of
2038 80:fa:5b:06:72:b7 from the chassis where the logical port "foo1"
2039 resides.
2040 L3 Gateway Options:
2042 These options apply to logical ports with type of l3gateway.
2044 options : peer: optional string
2046 The logical_port in the Port_Binding record for the other side
2047 of the ’l3gateway’ port. The named logical_port must specify
2048 this logical_port in its own peer option. That is, the two
2049 ’l3gateway’ logical ports must have reversed logical_port and
2050 peer values.
2051 options : l3gateway-chassis: optional string
2053 The chassis in which the port resides.
2054 options : nat-addresses: optional string
2056 MAC address of the l3gateway port followed by a list of SNAT and
2057 DNAT external IP addresses. This is used to send gratuitous ARPs
2058 for SNAT and DNAT external IP addresses via localnet. Example:
2059 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
2060 in generation of gratuitous ARPs for IP addresses 158.36.44.22
2061 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
2062 is used in OVS versions prior to 2.8.
2063 nat_addresses: set of strings
2065 MAC address of the l3gateway port followed by a list of SNAT and
2066 DNAT external IP addresses. This is used to send gratuitous ARPs
2067 for SNAT and DNAT external IP addresses via localnet. Example:
2068 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
2069 in generation of gratuitous ARPs for IP addresses 158.36.44.22
2070 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
2071 is used in OVS version 2.8 and later versions.
2072 Localnet Options:
2074 These options apply to logical ports with type of localnet.
2076 options : network_name: optional string
2078 Required. ovn-controller uses the configuration entry
2079 ovn-bridge-mappings to determine how to connect to this network.
2080 ovn-bridge-mappings is a list of network names mapped to a local
2081 OVS bridge that provides access to that network. An example of
2082 configuring ovn-bridge-mappings would be: .IP
2083 $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
2084 When a logical switch has a localnet port attached, every chas‐
2086 sis that may have a local vif attached to that logical switch
2087 must have a bridge mapping configured to reach that localnet.
2088 Traffic that arrives on a localnet port is never forwarded over
2089 a tunnel to another chassis.
2090 tag: optional integer, in range 1 to 4,095
2092 If set, indicates that the port represents a connection to a
2093 specific VLAN on a locally accessible network. The VLAN ID is
2094 used to match incoming traffic and is also added to outgoing
2095 traffic.
2096 L2 Gateway Options:
2098 These options apply to logical ports with type of l2gateway.
2100 options : network_name: optional string
2102 Required. ovn-controller uses the configuration entry
2103 ovn-bridge-mappings to determine how to connect to this network.
2104 ovn-bridge-mappings is a list of network names mapped to a local
2105 OVS bridge that provides access to that network. An example of
2106 configuring ovn-bridge-mappings would be: .IP
2107 $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
2108 When a logical switch has a l2gateway port attached, the chassis
2110 that the l2gateway port is bound to must have a bridge mapping
2111 configured to reach the network identified by network_name.
2112 options : l2gateway-chassis: optional string
2114 Required. The chassis in which the port resides.
2115 tag: optional integer, in range 1 to 4,095
2117 If set, indicates that the gateway is connected to a specific
2118 VLAN on the physical network. The VLAN ID is used to match
2119 incoming traffic and is also added to outgoing traffic.
2120 VTEP Options:
2122 These options apply to logical ports with type of vtep.
2124 options : vtep-physical-switch: optional string
2126 Required. The name of the VTEP gateway.
2127 options : vtep-logical-switch: optional string
2129 Required. A logical switch name connected by the VTEP gateway.
2130 Must be set when type is vtep.
2131 VMI (or VIF) Options:
2133 These options apply to logical ports with type having (empty string)
2135 options : requested-chassis: optional string
2137 If set, identifies a specific chassis (by name or hostname) that
2138 is allowed to bind this port. Using this option will prevent
2139 thrashing between two chassis trying to bind the same port dur‐
2140 ing a live migration. It can also prevent similar thrashing due
2141 to a mis-configuration, if a port is accidentally created on
2142 more than one chassis.
2143 options : qos_max_rate: optional string
2145 If set, indicates the maximum rate for data sent from this
2146 interface, in bit/s. The traffic will be shaped according to
2147 this limit.
2148 options : qos_burst: optional string
2150 If set, indicates the maximum burst size for data sent from this
2151 interface, in bits.
2152 options : qdisc_queue_id: optional string, containing an integer, in
2154 range 1 to 61,440
2155 Indicates the queue number on the physical device. This is same
2156 as the queue_id used in OpenFlow in struct ofp_action_enqueue.
2157 Chassis Redirect Options:
2159 These options apply to logical ports with type of chassisredirect.
2161 options : distributed-port: optional string
2163 The name of the distributed port for which this chassisredirect
2164 port represents a particular instance.
2165 options : redirect-chassis: optional string
2167 The chassis that this chassisredirect port is bound to. This is
2168 taken from options:redirect-chassis in the OVN_Northbound data‐
2169 base’s Logical_Router_Port table.
2170 Nested Containers:
2172 These columns support containers nested within a VM. Specifically, they
2174 are used when type is empty and logical_port identifies the interface
2175 of a container spawned inside a VM. They are empty for containers or
2176 VMs that run directly on a hypervisor.
2177 parent_port: optional string
2179 This is taken from parent_name in the OVN_Northbound database’s
2180 Logical_Switch_Port table.
2181 tag: optional integer, in range 1 to 4,095
2183 Identifies the VLAN tag in the network traffic associated with
2184 that container’s network interface.
2185 This column is used for a different purpose when type is local‐
2187 net (see Localnet Options, above) or l2gateway (see L2 Gateway
2188 Options, above).
2189 Virtual ports:
2191 virtual_parent: optional string
2193 This column is set by ovn-controller with one of the value from
2194 the options:virtual-parents in the OVN_Northbound database’s
2195 Logical_Switch_Port table when the OVN action bind_vport is exe‐
2196 cuted. ovn-controller also sets the chassis column when it exe‐
2197 cutes this action with its chassis id.
2198 ovn-controller sets this column only if the type is "virtual".
2200 Naming:
2202 external_ids : name: optional string
2204 For a logical switch port, ovn-northd copies this from exter‐
2205 nal_ids:neutron:port_name in the Logical_Switch_Port table in
2206 the OVN_Northbound database, if it is a nonempty string.
2207 For a logical switch port, ovn-northd does not currently set
2209 this key.
2210 Common Columns:
2212 external_ids: map of string-string pairs
2214 See External IDs at the beginning of this document.
2215 The ovn-northd program populates this column with all entries
2217 into the external_ids column of the Logical_Switch_Port table of
2218 the OVN_Northbound database.
2219
2221 Each row in this table specifies a binding from an IP address to an
2222 Ethernet address that has been discovered through ARP (for IPv4) or
2223 neighbor discovery (for IPv6). This table is primarily used to discover
2224 bindings on physical networks, because IP-to-MAC bindings for virtual
2225 machines are usually populated statically into the Port_Binding table.
2226 This table expresses a functional relationship: MAC_Binding(logi‐
2228 cal_port, ip) = mac.
2229 In outline, the lifetime of a logical router’s MAC binding looks like
2231 this:
2232 1. On hypervisor 1, a logical router determines that a packet
2234 should be forwarded to IP address A on one of its router
2235 ports. It uses its logical flow table to determine that A
2236 lacks a static IP-to-MAC binding and the get_arp action to
2237 determine that it lacks a dynamic IP-to-MAC binding.
2238 2. Using an OVN logical arp action, the logical router gener‐
2240 ates and sends a broadcast ARP request to the router port.
2241 It drops the IP packet.
2242 3. The logical switch attached to the router port delivers the
2244 ARP request to all of its ports. (It might make sense to
2245 deliver it only to ports that have no static IP-to-MAC bind‐
2246 ings, but this could also be surprising behavior.)
2247 4. A host or VM on hypervisor 2 (which might be the same as
2249 hypervisor 1) attached to the logical switch owns the IP
2250 address in question. It composes an ARP reply and unicasts
2251 it to the logical router port’s Ethernet address.
2252 5. The logical switch delivers the ARP reply to the logical
2254 router port.
2255 6. The logical router flow table executes a put_arp action. To
2257 record the IP-to-MAC binding, ovn-controller adds a row to
2258 the MAC_Binding table.
2259 7. On hypervisor 1, ovn-controller receives the updated
2261 MAC_Binding table from the OVN southbound database. The next
2262 packet destined to A through the logical router is sent
2263 directly to the bound Ethernet address.
2264 Summary:
2266 logical_port string
2267 ip string
2268 mac string
2269 datapath Datapath_Binding
2270 Details:
2272 logical_port: string
2273 The logical port on which the binding was discovered.
2274 ip: string
2276 The bound IP address.
2277 mac: string
2279 The Ethernet address to which the IP is bound.
2280 datapath: Datapath_Binding
2282 The logical datapath to which the logical port belongs.
2283
2285 Each row in this table stores the DHCP Options supported by native OVN
2286 DHCP. ovn-northd populates this table with the supported DHCP options.
2287 ovn-controller looks up this table to get the DHCP codes of the DHCP
2288 options defined in the "put_dhcp_opts" action. Please refer to the RFC
2289 2132 "https://tools.ietf.org/html/rfc2132" for the possible list of
2290 DHCP options that can be defined here.
2291 Summary:
2293 name string
2294 code integer, in range 0 to 254
2295 type string, one of bool, ipv4, static_routes,
2296 str, uint16, uint32, or uint8
2297 Details:
2299 name: string
2300 Name of the DHCP option.
2301 Example. name="router"
2303 code: integer, in range 0 to 254
2305 DHCP option code for the DHCP option as defined in the RFC 2132.
2306 Example. code=3
2308 type: string, one of bool, ipv4, static_routes, str, uint16, uint32, or
2310 uint8
2311 Data type of the DHCP option code.
2312 value: bool
2314 This indicates that the value of the DHCP option is a
2315 bool.
2316 Example. "name=ip_forward_enable", "code=19",
2318 "type=bool".
2319 put_dhcp_opts(..., ip_forward_enable = 1,...)
2321 value: uint8
2323 This indicates that the value of the DHCP option is an
2324 unsigned int8 (8 bits)
2325 Example. "name=default_ttl", "code=23", "type=uint8".
2327 put_dhcp_opts(..., default_ttl = 50,...)
2329 value: uint16
2331 This indicates that the value of the DHCP option is an
2332 unsigned int16 (16 bits).
2333 Example. "name=mtu", "code=26", "type=uint16".
2335 put_dhcp_opts(..., mtu = 1450,...)
2337 value: uint32
2339 This indicates that the value of the DHCP option is an
2340 unsigned int32 (32 bits).
2341 Example. "name=lease_time", "code=51", "type=uint32".
2343 put_dhcp_opts(..., lease_time = 86400,...)
2345 value: ipv4
2347 This indicates that the value of the DHCP option is an
2348 IPv4 address or addresses.
2349 Example. "name=router", "code=3", "type=ipv4".
2351 put_dhcp_opts(..., router = 10.0.0.1,...)
2353 Example. "name=dns_server", "code=6", "type=ipv4".
2355 put_dhcp_opts(..., dns_server = {8.8.8.8 7.7.7.7},...)
2357 value: static_routes
2359 This indicates that the value of the DHCP option contains
2360 a pair of IPv4 route and next hop addresses.
2361 Example. "name=classless_static_route", "code=121",
2363 "type=static_routes".
2364 put_dhcp_opts(..., classless_static_route =
2366 {30.0.0.0/24,10.0.0.4,0.0.0.0/0,10.0.0.1}...)
2367 value: str
2369 This indicates that the value of the DHCP option is a
2370 string.
2371 Example. "name=host_name", "code=12", "type=str".
2373
2375 Each row in this table stores the DHCPv6 Options supported by native
2376 OVN DHCPv6. ovn-northd populates this table with the supported DHCPv6
2377 options. ovn-controller looks up this table to get the DHCPv6 codes of
2378 the DHCPv6 options defined in the put_dhcpv6_opts action. Please refer
2379 to RFC 3315 and RFC 3646 for the list of DHCPv6 options that can be
2380 defined here.
2381 Summary:
2383 name string
2384 code integer, in range 0 to 254
2385 type string, one of ipv6, mac, or str
2386 Details:
2388 name: string
2389 Name of the DHCPv6 option.
2390 Example. name="ia_addr"
2392 code: integer, in range 0 to 254
2394 DHCPv6 option code for the DHCPv6 option as defined in the
2395 appropriate RFC.
2396 Example. code=3
2398 type: string, one of ipv6, mac, or str
2400 Data type of the DHCPv6 option code.
2401 value: ipv6
2403 This indicates that the value of the DHCPv6 option is an
2404 IPv6 address(es).
2405 Example. "name=ia_addr", "code=5", "type=ipv6".
2407 put_dhcpv6_opts(..., ia_addr = ae70::4,...)
2409 value: str
2411 This indicates that the value of the DHCPv6 option is a
2412 string.
2413 Example. "name=domain_search", "code=24", "type=str".
2415 put_dhcpv6_opts(..., domain_search = ovn.domain,...)
2417 value: mac
2419 This indicates that the value of the DHCPv6 option is a
2420 MAC address.
2421 Example. "name=server_id", "code=2", "type=mac".
2423 put_dhcpv6_opts(..., server_id = 01:02:03:04L05:06,...)
2425
2427 Configuration for a database connection to an Open vSwitch database
2428 (OVSDB) client.
2429 This table primarily configures the Open vSwitch database server
2431 (ovsdb-server).
2432 The Open vSwitch database server can initiate and maintain active con‐
2434 nections to remote clients. It can also listen for database connec‐
2435 tions.
2436 Summary:
2438 Core Features:
2439 target string (must be unique within table)
2440 read_only boolean
2441 role string
2442 Client Failure Detection and Handling:
2443 max_backoff optional integer, at least 1,000
2444 inactivity_probe optional integer
2445 Status:
2446 is_connected boolean
2447 status : last_error optional string
2448 status : state optional string, one of ACTIVE, BACKOFF,
2449 CONNECTING, IDLE, or VOID
2450 status : sec_since_connect optional string, containing an integer,
2451 at least 0
2452 status : sec_since_disconnect
2453 optional string, containing an integer,
2454 at least 0
2455 status : locks_held optional string
2456 status : locks_waiting optional string
2457 status : locks_lost optional string
2458 status : n_connections optional string, containing an integer,
2459 at least 2
2460 status : bound_port optional string, containing an integer
2461 Common Columns:
2462 external_ids map of string-string pairs
2463 other_config map of string-string pairs
2464 Details:
2466 Core Features:
2467 target: string (must be unique within table)
2469 Connection methods for clients.
2470 The following connection methods are currently supported:
2472 ssl:host[:port]
2474 The specified SSL port on the given host, which can
2475 either be a DNS name (if built with unbound library) or
2476 an IP address. A valid SSL configuration must be provided
2477 when this form is used, this configuration can be speci‐
2478 fied via command-line options or the SSL table.
2479 If port is not specified, it defaults to 6640.
2481 SSL support is an optional feature that is not always
2483 built as part of Open vSwitch.
2484 tcp:host[:port]
2486 The specified TCP port on the given host, which can
2487 either be a DNS name (if built with unbound library) or
2488 an IP address (IPv4 or IPv6). If host is an IPv6 address,
2489 wrap it in square brackets, e.g. tcp:[::1]:6640.
2490 If port is not specified, it defaults to 6640.
2492 pssl:[port][:host]
2494 Listens for SSL connections on the specified TCP port.
2495 Specify 0 for port to have the kernel automatically
2496 choose an available port. If host, which can either be a
2497 DNS name (if built with unbound library) or an IP
2498 address, is specified, then connections are restricted to
2499 the resolved or specified local IP address (either IPv4
2500 or IPv6 address). If host is an IPv6 address, wrap in
2501 square brackets, e.g. pssl:6640:[::1]. If host is not
2502 specified then it listens only on IPv4 (but not IPv6)
2503 addresses. A valid SSL configuration must be provided
2504 when this form is used, this can be specified either via
2505 command-line options or the SSL table.
2506 If port is not specified, it defaults to 6640.
2508 SSL support is an optional feature that is not always
2510 built as part of Open vSwitch.
2511 ptcp:[port][:host]
2513 Listens for connections on the specified TCP port. Spec‐
2514 ify 0 for port to have the kernel automatically choose an
2515 available port. If host, which can either be a DNS name
2516 (if built with unbound library) or an IP address, is
2517 specified, then connections are restricted to the
2518 resolved or specified local IP address (either IPv4 or
2519 IPv6 address). If host is an IPv6 address, wrap it in
2520 square brackets, e.g. ptcp:6640:[::1]. If host is not
2521 specified then it listens only on IPv4 addresses.
2522 If port is not specified, it defaults to 6640.
2524 When multiple clients are configured, the target values must be
2526 unique. Duplicate target values yield unspecified results.
2527 read_only: boolean
2529 true to restrict these connections to read-only transactions,
2530 false to allow them to modify the database.
2531 role: string
2533 String containing role name for this connection entry.
2534 Client Failure Detection and Handling:
2536 max_backoff: optional integer, at least 1,000
2538 Maximum number of milliseconds to wait between connection
2539 attempts. Default is implementation-specific.
2540 inactivity_probe: optional integer
2542 Maximum number of milliseconds of idle time on connection to the
2543 client before sending an inactivity probe message. If Open
2544 vSwitch does not communicate with the client for the specified
2545 number of seconds, it will send a probe. If a response is not
2546 received for the same additional amount of time, Open vSwitch
2547 assumes the connection has been broken and attempts to recon‐
2548 nect. Default is implementation-specific. A value of 0 disables
2549 inactivity probes.
2550 Status:
2552 Key-value pair of is_connected is always updated. Other key-value pairs
2554 in the status columns may be updated depends on the target type.
2555 When target specifies a connection method that listens for inbound con‐
2557 nections (e.g. ptcp: or punix:), both n_connections and is_connected
2558 may also be updated while the remaining key-value pairs are omitted.
2559 On the other hand, when target specifies an outbound connection, all
2561 key-value pairs may be updated, except the above-mentioned two key-
2562 value pairs associated with inbound connection targets. They are omit‐
2563 ted.
2564 is_connected: boolean
2566 true if currently connected to this client, false otherwise.
2567 status : last_error: optional string
2569 A human-readable description of the last error on the connection
2570 to the manager; i.e. strerror(errno). This key will exist only
2571 if an error has occurred.
2572 status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
2574 IDLE, or VOID
2575 The state of the connection to the manager:
2576 VOID Connection is disabled.
2578 BACKOFF
2580 Attempting to reconnect at an increasing period.
2581 CONNECTING
2583 Attempting to connect.
2584 ACTIVE Connected, remote host responsive.
2586 IDLE Connection is idle. Waiting for response to keep-alive.
2588 These values may change in the future. They are provided only
2590 for human consumption.
2591 status : sec_since_connect: optional string, containing an integer, at
2593 least 0
2594 The amount of time since this client last successfully connected
2595 to the database (in seconds). Value is empty if client has never
2596 successfully been connected.
2597 status : sec_since_disconnect: optional string, containing an integer,
2599 at least 0
2600 The amount of time since this client last disconnected from the
2601 database (in seconds). Value is empty if client has never dis‐
2602 connected.
2603 status : locks_held: optional string
2605 Space-separated list of the names of OVSDB locks that the con‐
2606 nection holds. Omitted if the connection does not hold any
2607 locks.
2608 status : locks_waiting: optional string
2610 Space-separated list of the names of OVSDB locks that the con‐
2611 nection is currently waiting to acquire. Omitted if the connec‐
2612 tion is not waiting for any locks.
2613 status : locks_lost: optional string
2615 Space-separated list of the names of OVSDB locks that the con‐
2616 nection has had stolen by another OVSDB client. Omitted if no
2617 locks have been stolen from this connection.
2618 status : n_connections: optional string, containing an integer, at
2620 least 2
2621 When target specifies a connection method that listens for
2622 inbound connections (e.g. ptcp: or pssl:) and more than one con‐
2623 nection is actually active, the value is the number of active
2624 connections. Otherwise, this key-value pair is omitted.
2625 status : bound_port: optional string, containing an integer
2627 When target is ptcp: or pssl:, this is the TCP port on which the
2628 OVSDB server is listening. (This is particularly useful when
2629 target specifies a port of 0, allowing the kernel to choose any
2630 available port.)
2631 Common Columns:
2633 The overall purpose of these columns is described under Common Columns
2635 at the beginning of this document.
2636 external_ids: map of string-string pairs
2638 other_config: map of string-string pairs
2640
2642 SSL configuration for ovn-sb database access.
2643 Summary:
2645 private_key string
2646 certificate string
2647 ca_cert string
2648 bootstrap_ca_cert boolean
2649 ssl_protocols string
2650 ssl_ciphers string
2651 Common Columns:
2652 external_ids map of string-string pairs
2653 Details:
2655 private_key: string
2656 Name of a PEM file containing the private key used as the
2657 switch’s identity for SSL connections to the controller.
2658 certificate: string
2660 Name of a PEM file containing a certificate, signed by the cer‐
2661 tificate authority (CA) used by the controller and manager, that
2662 certifies the switch’s private key, identifying a trustworthy
2663 switch.
2664 ca_cert: string
2666 Name of a PEM file containing the CA certificate used to verify
2667 that the switch is connected to a trustworthy controller.
2668 bootstrap_ca_cert: boolean
2670 If set to true, then Open vSwitch will attempt to obtain the CA
2671 certificate from the controller on its first SSL connection and
2672 save it to the named PEM file. If it is successful, it will
2673 immediately drop the connection and reconnect, and from then on
2674 all SSL connections must be authenticated by a certificate
2675 signed by the CA certificate thus obtained. This option exposes
2676 the SSL connection to a man-in-the-middle attack obtaining the
2677 initial CA certificate. It may still be useful for bootstrap‐
2678 ping.
2679 ssl_protocols: string
2681 List of SSL protocols to be enabled for SSL connections. The
2682 default when this option is omitted is TLSv1,TLSv1.1,TLSv1.2.
2683 ssl_ciphers: string
2685 List of ciphers (in OpenSSL cipher string format) to be sup‐
2686 ported for SSL connections. The default when this option is
2687 omitted is HIGH:!aNULL:!MD5.
2688 Common Columns:
2690 The overall purpose of these columns is described under Common Columns
2692 at the beginning of this document.
2693 external_ids: map of string-string pairs
2695
2697 Each row in this table stores the DNS records. The OVN action
2698 dns_lookup uses this table for DNS resolution.
2699 Summary:
2701 records map of string-string pairs
2702 datapaths set of 1 or more Datapath_Bindings
2703 Common Columns:
2704 external_ids map of string-string pairs
2705 Details:
2707 records: map of string-string pairs
2708 Key-value pair of DNS records with DNS query name as the key and
2709 a string of IP address(es) separated by comma or space as the
2710 value.
2711 Example: "vm1.ovn.org" = "10.0.0.4 aef0::4"
2713 datapaths: set of 1 or more Datapath_Bindings
2715 The DNS records defined in the column records will be applied
2716 only to the DNS queries originating from the datapaths defined
2717 in this column.
2718 Common Columns:
2720 external_ids: map of string-string pairs
2722 See External IDs at the beginning of this document.
2723
2725 Role table for role-based access controls.
2726 Summary:
2728 name string
2729 permissions map of string-weak reference to RBAC_Per‐
2730 mission pairs
2731 Details:
2733 name: string
2734 The role name, corresponding to the role column in the Connec‐
2735 tion table.
2736 permissions: map of string-weak reference to RBAC_Permission pairs
2738 A mapping of table names to rows in the RBAC_Permission table.
2739
2741 Permissions table for role-based access controls.
2742 Summary:
2744 table string
2745 authorization set of strings
2746 insert_delete boolean
2747 update set of strings
2748 Details:
2750 table: string
2751 Name of table to which this row applies.
2752 authorization: set of strings
2754 Set of strings identifying columns and column:key pairs to be
2755 compared with client ID. At least one match is required in order
2756 to be authorized. A zero-length string is treated as a special
2757 value indicating all clients should be considered authorized.
2758 insert_delete: boolean
2760 When "true", row insertions and authorized row deletions are
2761 permitted.
2762 update: set of strings
2764 Set of strings identifying columns and column:key pairs that
2765 authorized clients are allowed to modify.
2766
2768 Association of Port_Binding rows of type chassisredirect to a Chassis.
2769 The traffic going out through a specific chassisredirect port will be
2770 redirected to a chassis, or a set of them in high availability configu‐
2771 rations.
2772 Summary:
2774 name string (must be unique within table)
2775 chassis optional weak reference to Chassis
2776 priority integer, in range 0 to 32,767
2777 options map of string-string pairs
2778 Common Columns:
2779 external_ids map of string-string pairs
2780 Details:
2782 name: string (must be unique within table)
2783 Name of the Gateway_Chassis.
2784 A suggested, but not required naming convention is
2786 ${port_name}_${chassis_name}.
2787 chassis: optional weak reference to Chassis
2789 The Chassis to which we send the traffic.
2790 priority: integer, in range 0 to 32,767
2792 This is the priority the specific Chassis among all Gate‐
2793 way_Chassis belonging to the same Port_Binding.
2794 options: map of string-string pairs
2796 Reserved for future use.
2797 Common Columns:
2799 The overall purpose of these columns is described under Common Columns
2801 at the beginning of this document.
2802 external_ids: map of string-string pairs
2804
2806 Summary:
2807 chassis optional weak reference to Chassis
2808 priority integer, in range 0 to 32,767
2809 Common Columns:
2810 external_ids map of string-string pairs
2811 Details:
2813 chassis: optional weak reference to Chassis
2814 The Chassis which provides the HA functionality.
2815 priority: integer, in range 0 to 32,767
2817 Priority of the HA chassis. Chassis with highest priority will
2818 be the master in the HA chassis group.
2819 Common Columns:
2821 external_ids: map of string-string pairs
2823 See External IDs at the beginning of this document.
2824
2826 Table representing a group of chassis which can provide High availabil‐
2827 ity services. Each chassis in the group is represented by the table
2828 HA_Chassis. The HA chassis with highest priority will be the master of
2829 this group. If the master chassis failover is detected, the HA chassis
2830 with the next higher priority takes over the responsibility of provid‐
2831 ing the HA. If ha_chassis_group column of the table Port_Binding refer‐
2832 ences this table, then this HA chassis group provides the gateway func‐
2833 tionality and redirects the gateway traffic to the master of this
2834 group.
2835 Summary:
2837 name string (must be unique within table)
2838 ha_chassis set of HA_Chassiss
2839 ref_chassis set of weak reference to Chassiss
2840 Common Columns:
2841 external_ids map of string-string pairs
2842 Details:
2844 name: string (must be unique within table)
2845 Name of the HA_Chassis_Group. Name should be unique.
2846 ha_chassis: set of HA_Chassiss
2848 A list of HA_Chassis which belongs to this group.
2849 ref_chassis: set of weak reference to Chassiss
2851 A list of chassis which references this HA chassis group.
2852 Common Columns:
2854 external_ids: map of string-string pairs
2856 See External IDs at the beginning of this document.
2857
2859 Database table used by ovn-controller to report CMS related events.
2860 Please note there is no guarantee a given event is written exactly once
2861 in the db. It is CMS responsibility to squash duplicated lines or to
2862 filter out duplicated events
2863 Summary:
2865 event_type string, must be empty_lb_backends
2866 event_info map of string-string pairs
2867 chassis optional weak reference to Chassis
2868 seq_num integer
2869 Details:
2871 event_type: string, must be empty_lb_backends
2872 Event type occurred
2873 event_info: map of string-string pairs
2875 Key-value pairs used to specify event info to the CMS. Possible
2876 values are:
2877 · vip: VIP reported for the empty_lb_backends event
2879 · protocol: Transport protocol reported for the
2881 empty_lb_backends event
2882 · load_balancer: UUID of the load balancer reported for the
2884 empty_lb_backends event
2885 chassis: optional weak reference to Chassis
2887 This column is a Chassis record to identify the chassis that has
2888 managed a given event.
2889 seq_num: integer
2891 Event sequence number. Global counter for controller generated
2892 events. It can be used by the CMS to detect possible duplication
2893 of the same event.
2894
2896 IP Multicast configuration options. For now only applicable to IGMP.
2897 Summary:
2899 datapath weak reference to Datapath_Binding (must
2900 be unique within table)
2901 enabled optional boolean
2902 querier optional boolean
2903 table_size optional integer
2904 idle_timeout optional integer
2905 query_interval optional integer
2906 seq_no integer
2907 Querier configuration options:
2908 eth_src string
2909 ip4_src string
2910 query_max_resp optional integer
2911 Details:
2913 datapath: weak reference to Datapath_Binding (must be unique within ta‐
2914 ble)
2915 Datapath_Binding entry for which these configuration options are
2916 defined.
2917 enabled: optional boolean
2919 Enables/disables multicast snooping. Default: disabled.
2920 querier: optional boolean
2922 Enables/disables multicast querying. If enabled then multicast
2923 querying is enabled by default.
2924 table_size: optional integer
2926 Limits the number of multicast groups that can be learned.
2927 Default: 2048 groups per datapath.
2928 idle_timeout: optional integer
2930 Configures the idle timeout (in seconds) for IP multicast groups
2931 if multicast snooping is enabled. Default: 300 seconds.
2932 query_interval: optional integer
2934 Configures the interval (in seconds) for sending multicast
2935 queries if snooping and querier are enabled. Default: idle_time‐
2936 out/2 seconds.
2937 seq_no: integer
2939 ovn-controller reads this value and flushes all learned multi‐
2940 cast groups when it detects that seq_no was changed.
2941 Querier configuration options:
2943 The ovn-controller process that runs on OVN hypervisor nodes uses the
2945 following columns to determine field values in IGMP queries that it
2946 originates:
2947 eth_src: string
2949 Source Ethernet address.
2950 ip4_src: string
2952 Source IPv4 address.
2953 query_max_resp: optional integer
2955 Value (in seconds) to be used as "max-response" field in multi‐
2956 cast queries. Default: 1 second.
2957
2959 Contains learned IGMP groups indexed by address/datapath/chassis.
2960 Summary:
2962 address string
2963 datapath optional weak reference to Datapath_Bind‐
2964 ing
2965 chassis optional weak reference to Chassis
2966 ports set of weak reference to Port_Bindings
2967 Details:
2969 address: string
2970 Destination IPv4 address for the IGMP group.
2971 datapath: optional weak reference to Datapath_Binding
2973 Datapath to which this IGMP group belongs.
2974 chassis: optional weak reference to Chassis
2976 Chassis to which this IGMP group belongs.
2977 ports: set of weak reference to Port_Bindings
2979 The destination port bindings for this IGMP group.
2980Open vSwitch 2.12.0 DB Schema 2.5.0 ovn-sb(5)