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
146 Southbound configuration for an OVN system. This table must have
147 exactly one row.
148 Summary:
150 Status:
151 nb_cfg integer
152 Common Columns:
153 external_ids map of string-string pairs
154 Connection Options:
155 connections set of Connections
156 ssl optional SSL
157 Details:
159 Status:
160 This column allow a client to track the overall configuration state of
162 the system.
163 nb_cfg: integer
165 Sequence number for the configuration. When a CMS or ovn-nbctl
166 updates the northbound database, it increments the nb_cfg column
167 in the NB_Global table in the northbound database. In turn, when
168 ovn-northd updates the southbound database to bring it up to
169 date with these changes, it updates this column to the same
170 value.
171 Common Columns:
173 external_ids: map of string-string pairs
175 See External IDs at the beginning of this document.
176 Connection Options:
178 connections: set of Connections
180 Database clients to which the Open vSwitch database server
181 should connect or on which it should listen, along with options
182 for how these connections should be configured. See the Connec‐
183 tion table for more information.
184 ssl: optional SSL
186 Global SSL configuration.
187
189 Each row in this table represents a hypervisor or gateway (a chassis)
190 in the physical network. Each chassis, via ovn-controller/ovn-con‐
191 troller-vtep, adds and updates its own row, and keeps a copy of the
192 remaining rows to determine how to reach other hypervisors.
193 When a chassis shuts down gracefully, it should remove its own row.
195 (This is not critical because resources hosted on the chassis are
196 equally unreachable regardless of whether the row is present.) If a
197 chassis shuts down permanently without removing its row, some kind of
198 manual or automatic cleanup is eventually needed; we can devise a
199 process for that as necessary.
200 Summary:
202 name string (must be unique within table)
203 hostname string
204 nb_cfg integer
205 external_ids : ovn-bridge-mappings
206 optional string
207 external_ids : datapath-type optional string
208 external_ids : iface-types optional string
209 external_ids : ovn-cms-options
210 optional string
211 Common Columns:
212 external_ids map of string-string pairs
213 Encapsulation Configuration:
214 encaps set of 1 or more Encaps
215 Gateway Configuration:
216 vtep_logical_switches set of strings
217 Details:
219 name: string (must be unique within table)
220 OVN does not prescribe a particular format for chassis names.
221 ovn-controller populates this column using external_ids:system-
222 id in the Open_vSwitch database’s Open_vSwitch table. ovn-con‐
223 troller-vtep populates this column with name in the hard‐
224 ware_vtep database’s Physical_Switch table.
225 hostname: string
227 The hostname of the chassis, if applicable. ovn-controller will
228 populate this column with the hostname of the host it is running
229 on. ovn-controller-vtep will leave this column empty.
230 nb_cfg: integer
232 Sequence number for the configuration. When ovn-controller
233 updates the configuration of a chassis from the contents of the
234 southbound database, it copies nb_cfg from the SB_Global table
235 into this column.
236 external_ids : ovn-bridge-mappings: optional string
238 ovn-controller populates this key with the set of bridge map‐
239 pings it has been configured to use. Other applications should
240 treat this key as read-only. See ovn-controller(8) for more
241 information.
242 external_ids : datapath-type: optional string
244 ovn-controller populates this key with the datapath type config‐
245 ured in the datapath_type column of the Open_vSwitch database’s
246 Bridge table. Other applications should treat this key as read-
247 only. See ovn-controller(8) for more information.
248 external_ids : iface-types: optional string
250 ovn-controller populates this key with the interface types con‐
251 figured in the iface_types column of the Open_vSwitch database’s
252 Open_vSwitch table. Other applications should treat this key as
253 read-only. See ovn-controller(8) for more information.
254 external_ids : ovn-cms-options: optional string
256 ovn-controller populates this key with the set of options con‐
257 figured in the external_ids:ovn-cms-options column of the
258 Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
259 troller(8) for more information.
260 Common Columns:
262 The overall purpose of these columns is described under Common Columns
264 at the beginning of this document.
265 external_ids: map of string-string pairs
267 Encapsulation Configuration:
269 OVN uses encapsulation to transmit logical dataplane packets between
271 chassis.
272 encaps: set of 1 or more Encaps
274 Points to supported encapsulation configurations to transmit
275 logical dataplane packets to this chassis. Each entry is a Encap
276 record that describes the configuration.
277 Gateway Configuration:
279 A gateway is a chassis that forwards traffic between the OVN-managed
281 part of a logical network and a physical VLAN, extending a tunnel-based
282 logical network into a physical network. Gateways are typically dedi‐
283 cated nodes that do not host VMs and will be controlled by ovn-con‐
284 troller-vtep.
285 vtep_logical_switches: set of strings
287 Stores all VTEP logical switch names connected by this gateway
288 chassis. The Port_Binding table entry with options:vtep-physi‐
289 cal-switch equal Chassis name, and options:vtep-logical-switch
290 value in Chassis vtep_logical_switches, will be associated with
291 this Chassis.
292
294 The encaps column in the Chassis table refers to rows in this table to
295 identify how OVN may transmit logical dataplane packets to this chas‐
296 sis. Each chassis, via ovn-controller(8) or ovn-controller-vtep(8),
297 adds and updates its own rows and keeps a copy of the remaining rows to
298 determine how to reach other chassis.
299 Summary:
301 type string, one of geneve, stt, or vxlan
302 options map of string-string pairs
303 ip string
304 chassis_name string
305 Details:
307 type: string, one of geneve, stt, or vxlan
308 The encapsulation to use to transmit packets to this chassis.
309 Hypervisors must use either geneve or stt. Gateways may use
310 vxlan, geneve, or stt.
311 options: map of string-string pairs
313 Options for configuring the encapsulation. Currently, the only
314 option that has been defined is csum.
315 csum indicates that encapsulation checksums can be transmitted
317 and received with reasonable performance. It is a hint to
318 senders transmitting data to this chassis that they should use
319 checksums to protect OVN metadata. ovn-controller populates this
320 key with the value defined in external_ids:ovn-encap-csum column
321 of the Open_vSwitch database’s Open_vSwitch table. Other appli‐
322 cations should treat this key as read-only. See ovn-con‐
323 troller(8) for more information.
324 In terms of performance, this actually significantly increases
326 throughput in most common cases when running on Linux based
327 hosts without NICs supporting encapsulation hardware offload
328 (around 60% for bulk traffic). The reason is that generally all
329 NICs are capable of offloading transmitted and received TCP/UDP
330 checksums (viewed as ordinary data packets and not as tunnels).
331 The benefit comes on the receive side where the validated outer
332 checksum can be used to additionally validate an inner checksum
333 (such as TCP), which in turn allows aggregation of packets to be
334 more efficiently handled by the rest of the stack.
335 Not all devices see such a benefit. The most notable exception
337 is hardware VTEPs. These devices are designed to not buffer
338 entire packets in their switching engines and are therefore
339 unable to efficiently compute or validate full packet checksums.
340 In addition certain versions of the Linux kernel are not able to
341 fully take advantage of encapsulation NIC offloads in the pres‐
342 ence of checksums. (This is actually a pretty narrow corner case
343 though - earlier versions of Linux don’t support encapsulation
344 offloads at all and later versions support both offloads and
345 checksums well.)
346 csum defaults to false for hardware VTEPs and true for all other
348 cases.
349 ip: string
351 The IPv4 address of the encapsulation tunnel endpoint.
352 chassis_name: string
354 The name of the chassis that created this encap.
355
357 This table contains address sets synced from the Address_Set table in
358 the OVN_Northbound database and address sets generated from the
359 Port_Group table in the OVN_Northbound database.
360 See the documentation for the Address_Set table and Port_Group table in
362 the OVN_Northbound database for details.
363 Summary:
365 name string (must be unique within table)
366 addresses set of strings
367 Details:
369 name: string (must be unique within table)
370 addresses: set of strings
372
374 This table contains names for the logical switch ports in the
375 OVN_Northbound database that belongs to the same group that is defined
376 in Port_Group in the OVN_Northbound database.
377 Summary:
379 name string (must be unique within table)
380 ports set of strings
381 Details:
383 name: string (must be unique within table)
384 ports: set of strings
386
388 Each row in this table represents one logical flow. ovn-northd popu‐
389 lates this table with logical flows that implement the L2 and L3
390 topologies specified in the OVN_Northbound database. Each hypervisor,
391 via ovn-controller, translates the logical flows into OpenFlow flows
392 specific to its hypervisor and installs them into Open vSwitch.
393 Logical flows are expressed in an OVN-specific format, described here.
395 A logical datapath flow is much like an OpenFlow flow, except that the
396 flows are written in terms of logical ports and logical datapaths
397 instead of physical ports and physical datapaths. Translation between
398 logical and physical flows helps to ensure isolation between logical
399 datapaths. (The logical flow abstraction also allows the OVN central‐
400 ized components to do less work, since they do not have to separately
401 compute and push out physical flows to each chassis.)
402 The default action when no flow matches is to drop packets.
404 Architectural Logical Life Cycle of a Packet
406 This following description focuses on the life cycle of a packet
408 through a logical datapath, ignoring physical details of the implemen‐
409 tation. Please refer to Architectural Physical Life Cycle of a Packet
410 in ovn-architecture(7) for the physical information.
411 The description here is written as if OVN itself executes these steps,
413 but in fact OVN (that is, ovn-controller) programs Open vSwitch, via
414 OpenFlow and OVSDB, to execute them on its behalf.
415 At a high level, OVN passes each packet through the logical datapath’s
417 logical ingress pipeline, which may output the packet to one or more
418 logical port or logical multicast groups. For each such logical output
419 port, OVN passes the packet through the datapath’s logical egress pipe‐
420 line, which may either drop the packet or deliver it to the destina‐
421 tion. Between the two pipelines, outputs to logical multicast groups
422 are expanded into logical ports, so that the egress pipeline only pro‐
423 cesses a single logical output port at a time. Between the two pipe‐
424 lines is also where, when necessary, OVN encapsulates a packet in a
425 tunnel (or tunnels) to transmit to remote hypervisors.
426 In more detail, to start, OVN searches the Logical_Flow table for a row
428 with correct logical_datapath, a pipeline of ingress, a table_id of 0,
429 and a match that is true for the packet. If none is found, OVN drops
430 the packet. If OVN finds more than one, it chooses the match with the
431 highest priority. Then OVN executes each of the actions specified in
432 the row’s actions column, in the order specified. Some actions, such as
433 those to modify packet headers, require no further details. The next
434 and output actions are special.
435 The next action causes the above process to be repeated recursively,
437 except that OVN searches for table_id of 1 instead of 0. Similarly, any
438 next action in a row found in that table would cause a further search
439 for a table_id of 2, and so on. When recursive processing completes,
440 flow control returns to the action following next.
441 The output action also introduces recursion. Its effect depends on the
443 current value of the outport field. Suppose outport designates a logi‐
444 cal port. First, OVN compares inport to outport; if they are equal, it
445 treats the output as a no-op by default. In the common case, where they
446 are different, the packet enters the egress pipeline. This transition
447 to the egress pipeline discards register data, e.g. reg0 ... reg9 and
448 connection tracking state, to achieve uniform behavior regardless of
449 whether the egress pipeline is on a different hypervisor (because reg‐
450 isters aren’t preserve across tunnel encapsulation).
451 To execute the egress pipeline, OVN again searches the Logical_Flow ta‐
453 ble for a row with correct logical_datapath, a table_id of 0, a match
454 that is true for the packet, but now looking for a pipeline of egress.
455 If no matching row is found, the output becomes a no-op. Otherwise, OVN
456 executes the actions for the matching flow (which is chosen from multi‐
457 ple, if necessary, as already described).
458 In the egress pipeline, the next action acts as already described,
460 except that it, of course, searches for egress flows. The output
461 action, however, now directly outputs the packet to the output port
462 (which is now fixed, because outport is read-only within the egress
463 pipeline).
464 The description earlier assumed that outport referred to a logical
466 port. If it instead designates a logical multicast group, then the
467 description above still applies, with the addition of fan-out from the
468 logical multicast group to each logical port in the group. For each
469 member of the group, OVN executes the logical pipeline as described,
470 with the logical output port replaced by the group member.
471 Pipeline Stages
473 ovn-northd populates the Logical_Flow table with the logical flows
475 described in detail in ovn-northd(8).
476 Summary:
478 logical_datapath Datapath_Binding
479 pipeline string, either egress or ingress
480 table_id integer, in range 0 to 23
481 priority integer, in range 0 to 65,535
482 match string
483 actions string
484 external_ids : stage-name optional string
485 external_ids : stage-hint optional string, containing an uuid
486 external_ids : source optional string
487 Common Columns:
488 external_ids map of string-string pairs
489 Details:
491 logical_datapath: Datapath_Binding
492 The logical datapath to which the logical flow belongs.
493 pipeline: string, either egress or ingress
495 The primary flows used for deciding on a packet’s destination
496 are the ingress flows. The egress flows implement ACLs. See Log‐
497 ical Life Cycle of a Packet, above, for details.
498 table_id: integer, in range 0 to 23
500 The stage in the logical pipeline, analogous to an OpenFlow ta‐
501 ble number.
502 priority: integer, in range 0 to 65,535
504 The flow’s priority. Flows with numerically higher priority take
505 precedence over those with lower. If two logical datapath flows
506 with the same priority both match, then the one actually applied
507 to the packet is undefined.
508 match: string
510 A matching expression. OVN provides a superset of OpenFlow
511 matching capabilities, using a syntax similar to Boolean expres‐
512 sions in a programming language.
513 The most important components of match expression are compar‐
515 isons between symbols and constants, e.g. ip4.dst ==
516 192.168.0.1, ip.proto == 6, arp.op == 1, eth.type == 0x800. The
517 logical AND operator && and logical OR operator || can combine
518 comparisons into a larger expression.
519 Matching expressions also support parentheses for grouping, the
521 logical NOT prefix operator !, and literals 0 and 1 to express
522 ``false’’ or ``true,’’ respectively. The latter is useful by
523 itself as a catch-all expression that matches every packet.
524 Match expressions also support a kind of function syntax. The
526 following functions are supported:
527 is_chassis_resident(lport)
529 Evaluates to true on a chassis on which logical port
530 lport (a quoted string) resides, and to false elsewhere.
531 This function was introduced in OVN 2.7.
532 Symbols
534 Type. Symbols have integer or string type. Integer symbols have
536 a width in bits.
537 Kinds. There are three kinds of symbols:
539 · Fields. A field symbol represents a packet header or
541 metadata field. For example, a field named vlan.tci might
542 represent the VLAN TCI field in a packet.
543 A field symbol can have integer or string type. Integer
545 fields can be nominal or ordinal (see Level of Measure‐
546 ment, below).
547 · Subfields. A subfield represents a subset of bits from a
549 larger field. For example, a field vlan.vid might be
550 defined as an alias for vlan.tci[0..11]. Subfields are
551 provided for syntactic convenience, because it is always
552 possible to instead refer to a subset of bits from a
553 field directly.
554 Only ordinal fields (see Level of Measurement, below) may
556 have subfields. Subfields are always ordinal.
557 · Predicates. A predicate is shorthand for a Boolean
559 expression. Predicates may be used much like 1-bit
560 fields. For example, ip4 might expand to eth.type ==
561 0x800. Predicates are provided for syntactic convenience,
562 because it is always possible to instead specify the
563 underlying expression directly.
564 A predicate whose expansion refers to any nominal field
566 or predicate (see Level of Measurement, below) is nomi‐
567 nal; other predicates have Boolean level of measurement.
568 Level of Measurement. See
570 http://en.wikipedia.org/wiki/Level_of_measurement for the sta‐
571 tistical concept on which this classification is based. There
572 are three levels:
573 · Ordinal. In statistics, ordinal values can be ordered on
575 a scale. OVN considers a field (or subfield) to be ordi‐
576 nal if its bits can be examined individually. This is
577 true for the OpenFlow fields that OpenFlow or Open
578 vSwitch makes ``maskable.’’
579 Any use of a ordinal field may specify a single bit or a
581 range of bits, e.g. vlan.tci[13..15] refers to the PCP
582 field within the VLAN TCI, and eth.dst[40] refers to the
583 multicast bit in the Ethernet destination address.
584 OVN supports all the usual arithmetic relations (==, !=,
586 <, <=, >, and >=) on ordinal fields and their subfields,
587 because OVN can implement these in OpenFlow and Open
588 vSwitch as collections of bitwise tests.
589 · Nominal. In statistics, nominal values cannot be usefully
591 compared except for equality. This is true of OpenFlow
592 port numbers, Ethernet types, and IP protocols are exam‐
593 ples: all of these are just identifiers assigned arbi‐
594 trarily with no deeper meaning. In OpenFlow and Open
595 vSwitch, bits in these fields generally aren’t individu‐
596 ally addressable.
597 OVN only supports arithmetic tests for equality on nomi‐
599 nal fields, because OpenFlow and Open vSwitch provide no
600 way for a flow to efficiently implement other comparisons
601 on them. (A test for inequality can be sort of built out
602 of two flows with different priorities, but OVN matching
603 expressions always generate flows with a single prior‐
604 ity.)
605 String fields are always nominal.
607 · Boolean. A nominal field that has only two values, 0 and
609 1, is somewhat exceptional, since it is easy to support
610 both equality and inequality tests on such a field:
611 either one can be implemented as a test for 0 or 1.
612 Only predicates (see above) have a Boolean level of mea‐
614 surement.
615 This isn’t a standard level of measurement.
617 Prerequisites. Any symbol can have prerequisites, which are
619 additional condition implied by the use of the symbol. For exam‐
620 ple, For example, icmp4.type symbol might have prerequisite
621 icmp4, which would cause an expression icmp4.type == 0 to be
622 interpreted as icmp4.type == 0 && icmp4, which would in turn
623 expand to icmp4.type == 0 && eth.type == 0x800 && ip4.proto == 1
624 (assuming icmp4 is a predicate defined as suggested under Types
625 above).
626 Relational operators
628 All of the standard relational operators ==, !=, <, <=, >, and
630 >= are supported. Nominal fields support only == and !=, and
631 only in a positive sense when outer ! are taken into account,
632 e.g. given string field inport, inport == "eth0" and !(inport !=
633 "eth0") are acceptable, but not inport != "eth0".
634 The implementation of == (or != when it is negated), is more
636 efficient than that of the other relational operators.
637 Constants
639 Integer constants may be expressed in decimal, hexadecimal pre‐
641 fixed by 0x, or as dotted-quad IPv4 addresses, IPv6 addresses in
642 their standard forms, or Ethernet addresses as colon-separated
643 hex digits. A constant in any of these forms may be followed by
644 a slash and a second constant (the mask) in the same form, to
645 form a masked constant. IPv4 and IPv6 masks may be given as
646 integers, to express CIDR prefixes.
647 String constants have the same syntax as quoted strings in JSON
649 (thus, they are Unicode strings).
650 Some operators support sets of constants written inside curly
652 braces { ... }. Commas between elements of a set, and after the
653 last elements, are optional. With ==, ``field == { constant1,
654 constant2, ... }’’ is syntactic sugar for ``field == constant1
655 || field == constant2 || .... Similarly, ``field != { constant1,
656 constant2, ... }’’ is equivalent to ``field != constant1 &&
657 field != constant2 && ...’’.
658 You may refer to a set of IPv4, IPv6, or MAC addresses stored in
660 the Address_Set table by its name. An Address_Set with a name of
661 set1 can be referred to as $set1.
662 You may refer to a group of logical switch ports stored in the
664 Port_Group table by its name. An Port_Group with a name of
665 port_group1 can be referred to as @port_group1.
666 Additionally, you may refer to the set of addresses belonging to
668 a group of logical switch ports stored in the Port_Group table
669 by its name followed by a suffix ’_ip4’/’_ip6’. The IPv4 address
670 set of a Port_Group with a name of port_group1 can be referred
671 to as $port_group1_ip4, and the IPv6 address set of the same
672 Port_Group can be referred to as $port_group1_ip6
673 Miscellaneous
675 Comparisons may name the symbol or the constant first, e.g.
677 tcp.src == 80 and 80 == tcp.src are both acceptable.
678 Tests for a range may be expressed using a syntax like 1024 <=
680 tcp.src <= 49151, which is equivalent to 1024 <= tcp.src &&
681 tcp.src <= 49151.
682 For a one-bit field or predicate, a mention of its name is
684 equivalent to symobl == 1, e.g. vlan.present is equivalent to
685 vlan.present == 1. The same is true for one-bit subfields, e.g.
686 vlan.tci[12]. There is no technical limitation to implementing
687 the same for ordinal fields of all widths, but the implementa‐
688 tion is expensive enough that the syntax parser requires writing
689 an explicit comparison against zero to make mistakes less
690 likely, e.g. in tcp.src != 0 the comparison against 0 is
691 required.
692 Operator precedence is as shown below, from highest to lowest.
694 There are two exceptions where parentheses are required even
695 though the table would suggest that they are not: && and ||
696 require parentheses when used together, and ! requires parenthe‐
697 ses when applied to a relational expression. Thus, in (eth.type
698 == 0x800 || eth.type == 0x86dd) && ip.proto == 6 or !(arp.op ==
699 1), the parentheses are mandatory.
700 · ()
702 · == != < <= > >=
704 · !
706 · && ||
708 Comments may be introduced by //, which extends to the next new-
710 line. Comments within a line may be bracketed by /* and */. Mul‐
711 tiline comments are not supported.
712 Symbols
714 Most of the symbols below have integer type. Only inport and
716 outport have string type. inport names a logical port. Thus, its
717 value is a logical_port name from the Port_Binding table. out‐
718 port may name a logical port, as inport, or a logical multicast
719 group defined in the Multicast_Group table. For both symbols,
720 only names within the flow’s logical datapath may be used.
721 The regX symbols are 32-bit integers. The xxregX symbols are
723 128-bit integers, which overlay four of the 32-bit registers:
724 xxreg0 overlays reg0 through reg3, with reg0 supplying the most-
725 significant bits of xxreg0 and reg3 the least-signficant. xxreg1
726 similarly overlays reg4 through reg7.
727 · reg0...reg9
729 · xxreg0 xxreg1
731 · inport outport
733 · flags.loopback
735 · eth.src eth.dst eth.type
737 · vlan.tci vlan.vid vlan.pcp vlan.present
739 · ip.proto ip.dscp ip.ecn ip.ttl ip.frag
741 · ip4.src ip4.dst
743 · ip6.src ip6.dst ip6.label
745 · arp.op arp.spa arp.tpa arp.sha arp.tha
747 · tcp.src tcp.dst tcp.flags
749 · udp.src udp.dst
751 · sctp.src sctp.dst
753 · icmp4.type icmp4.code
755 · icmp6.type icmp6.code
757 · nd.target nd.sll nd.tll
759 · ct_mark ct_label
761 · ct_state, which has several Boolean subfields. The
763 ct_next action initializes the following subfields:
764 · ct.trk: Always set to true by ct_next to indicate
766 that connection tracking has taken place. All
767 other ct subfields have ct.trk as a prerequisite.
768 · ct.new: True for a new flow
770 · ct.est: True for an established flow
772 · ct.rel: True for a related flow
774 · ct.rpl: True for a reply flow
776 · ct.inv: True for a connection entry in a bad state
778 The ct_dnat, ct_snat, and ct_lb actions initialize the
780 following subfields:
781 · ct.dnat: True for a packet whose destination IP
783 address has been changed.
784 · ct.snat: True for a packet whose source IP address
786 has been changed.
787 The following predicates are supported:
789 · eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff
791 · eth.mcast expands to eth.dst[40]
793 · vlan.present expands to vlan.tci[12]
795 · ip4 expands to eth.type == 0x800
797 · ip4.mcast expands to ip4.dst[28..31] == 0xe
799 · ip6 expands to eth.type == 0x86dd
801 · ip expands to ip4 || ip6
803 · icmp4 expands to ip4 && ip.proto == 1
805 · icmp6 expands to ip6 && ip.proto == 58
807 · icmp expands to icmp4 || icmp6
809 · ip.is_frag expands to ip.frag[0]
811 · ip.later_frag expands to ip.frag[1]
813 · ip.first_frag expands to ip.is_frag && !ip.later_frag
815 · arp expands to eth.type == 0x806
817 · nd expands to icmp6.type == {135, 136} && icmp6.code == 0
819 && ip.ttl == 255
820 · nd_ns expands to icmp6.type == 135 && icmp6.code == 0 &&
822 ip.ttl == 255
823 · nd_na expands to icmp6.type == 136 && icmp6.code == 0 &&
825 ip.ttl == 255
826 · nd_rs expands to icmp6.type == 133 && icmp6.code == 0 &&
828 ip.ttl == 255
829 · nd_ra expands to icmp6.type == 134 && icmp6.code == 0 &&
831 ip.ttl == 255
832 · tcp expands to ip.proto == 6
834 · udp expands to ip.proto == 17
836 · sctp expands to ip.proto == 132
838 actions: string
840 Logical datapath actions, to be executed when the logical flow
841 represented by this row is the highest-priority match.
842 Actions share lexical syntax with the match column. An empty set
844 of actions (or one that contains just white space or comments),
845 or a set of actions that consists of just drop;, causes the
846 matched packets to be dropped. Otherwise, the column should con‐
847 tain a sequence of actions, each terminated by a semicolon.
848 The following actions are defined:
850 output;
852 In the ingress pipeline, this action executes the egress
853 pipeline as a subroutine. If outport names a logical
854 port, the egress pipeline executes once; if it is a mul‐
855 ticast group, the egress pipeline runs once for each log‐
856 ical port in the group.
857 In the egress pipeline, this action performs the actual
859 output to the outport logical port. (In the egress pipe‐
860 line, outport never names a multicast group.)
861 By default, output to the input port is implicitly
863 dropped, that is, output becomes a no-op if outport ==
864 inport. Occasionally it may be useful to override this
865 behavior, e.g. to send an ARP reply to an ARP request; to
866 do so, use flags.loopback = 1 to allow the packet to
867 "hair-pin" back to the input port.
868 next;
870 next(table);
871 next(pipeline=pipeline, table=table);
872 Executes the given logical datapath table in pipeline as a
873 subroutine. The default table is just after the current
874 one. If pipeline is specified, it may be ingress or egress;
875 the default pipeline is the one currently executing.
876 Actions in the ingress pipeline may not use next to jump
877 into the egress pipeline (use the output instead), but
878 transitions in the opposite direction are allowed.
879 field = constant;
881 Sets data or metadata field field to constant value con‐
882 stant, e.g. outport = "vif0"; to set the logical output
883 port. To set only a subset of bits in a field, specify a
884 subfield for field or a masked constant, e.g. one may use
885 vlan.pcp[2] = 1; or vlan.pcp = 4/4; to set the most sigifi‐
886 cant bit of the VLAN PCP.
887 Assigning to a field with prerequisites implicitly adds
889 those prerequisites to match; thus, for example, a flow
890 that sets tcp.dst applies only to TCP flows, regardless of
891 whether its match mentions any TCP field.
892 Not all fields are modifiable (e.g. eth.type and ip.proto
894 are read-only), and not all modifiable fields may be par‐
895 tially modified (e.g. ip.ttl must assigned as a whole). The
896 outport field is modifiable in the ingress pipeline but not
897 in the egress pipeline.
898 field1 = field2;
900 Sets data or metadata field field1 to the value of data or
901 metadata field field2, e.g. reg0 = ip4.src; copies ip4.src
902 into reg0. To modify only a subset of a field’s bits, spec‐
903 ify a subfield for field1 or field2 or both, e.g. vlan.pcp
904 = reg0[0..2]; copies the least-significant bits of reg0
905 into the VLAN PCP.
906 field1 and field2 must be the same type, either both string
908 or both integer fields. If they are both integer fields,
909 they must have the same width.
910 If field1 or field2 has prerequisites, they are added
912 implicitly to match. It is possible to write an assignment
913 with contradictory prerequisites, such as ip4.src =
914 ip6.src[0..31];, but the contradiction means that a logical
915 flow with such an assignment will never be matched.
916 field1 <-> field2;
918 Similar to field1 = field2; except that the two values are
919 exchanged instead of copied. Both field1 and field2 must
920 modifiable.
921 ip.ttl--;
923 Decrements the IPv4 or IPv6 TTL. If this would make the TTL
924 zero or negative, then processing of the packet halts; no
925 further actions are processed. (To properly handle such
926 cases, a higher-priority flow should match on ip.ttl == {0,
927 1};.)
928 Prerequisite: ip
930 ct_next;
932 Apply connection tracking to the flow, initializing
933 ct_state for matching in later tables. Automatically moves
934 on to the next table, as if followed by next.
935 As a side effect, IP fragments will be reassembled for
937 matching. If a fragmented packet is output, then it will be
938 sent with any overlapping fragments squashed. The connec‐
939 tion tracking state is scoped by the logical port when the
940 action is used in a flow for a logical switch, so overlap‐
941 ping addresses may be used. To allow traffic related to the
942 matched flow, execute ct_commit . Connection tracking state
943 is scoped by the logical topology when the action is used
944 in a flow for a router.
945 It is possible to have actions follow ct_next, but they
947 will not have access to any of its side-effects and is not
948 generally useful.
949 ct_commit;
951 ct_commit(ct_mark=value[/mask]);
952 ct_commit(ct_label=value[/mask]);
953 ct_commit(ct_mark=value[/mask], ct_label=value[/mask]);
954 Commit the flow to the connection tracking entry associated
955 with it by a previous call to ct_next. When
956 ct_mark=value[/mask] and/or ct_label=value[/mask] are sup‐
957 plied, ct_mark and/or ct_label will be set to the values
958 indicated by value[/mask] on the connection tracking entry.
959 ct_mark is a 32-bit field. ct_label is a 128-bit field. The
960 value[/mask] should be specified in hex string if more than
961 64bits are to be used.
962 Note that if you want processing to continue in the next
964 table, you must execute the next action after ct_commit.
965 You may also leave out next which will commit connection
966 tracking state, and then drop the packet. This could be
967 useful for setting ct_mark on a connection tracking entry
968 before dropping a packet, for example.
969 ct_dnat;
971 ct_dnat(IP);
972 ct_dnat sends the packet through the DNAT zone in connec‐
973 tion tracking table to unDNAT any packet that was DNATed in
974 the opposite direction. The packet is then automatically
975 sent to to the next tables as if followed by next; action.
976 The next tables will see the changes in the packet caused
977 by the connection tracker.
978 ct_dnat(IP) sends the packet through the DNAT zone to
980 change the destination IP address of the packet to the one
981 provided inside the parentheses and commits the connection.
982 The packet is then automatically sent to the next tables as
983 if followed by next; action. The next tables will see the
984 changes in the packet caused by the connection tracker.
985 ct_snat;
987 ct_snat(IP);
988 ct_snat sends the packet through the SNAT zone to unSNAT
989 any packet that was SNATed in the opposite direction. The
990 packet is automatically sent to the next tables as if fol‐
991 lowed by the next; action. The next tables will see the
992 changes in the packet caused by the connection tracker.
993 ct_snat(IP) sends the packet through the SNAT zone to
995 change the source IP address of the packet to the one pro‐
996 vided inside the parenthesis and commits the connection.
997 The packet is then automatically sent to the next tables as
998 if followed by next; action. The next tables will see the
999 changes in the packet caused by the connection tracker.
1000 ct_clear;
1002 Clears connection tracking state.
1003 clone { action; ... };
1005 Makes a copy of the packet being processed and executes
1006 each action on the copy. Actions following the clone
1007 action, if any, apply to the original, unmodified packet.
1008 This can be used as a way to ``save and restore’’ the
1009 packet around a set of actions that may modify it and
1010 should not persist.
1011 arp { action; ... };
1013 Temporarily replaces the IPv4 packet being processed by an
1014 ARP packet and executes each nested action on the ARP
1015 packet. Actions following the arp action, if any, apply to
1016 the original, unmodified packet.
1017 The ARP packet that this action operates on is initialized
1019 based on the IPv4 packet being processed, as follows. These
1020 are default values that the nested actions will probably
1021 want to change:
1022 · eth.src unchanged
1024 · eth.dst unchanged
1026 · eth.type = 0x0806
1028 · arp.op = 1 (ARP request)
1030 · arp.sha copied from eth.src
1032 · arp.spa copied from ip4.src
1034 · arp.tha = 00:00:00:00:00:00
1036 · arp.tpa copied from ip4.dst
1038 The ARP packet has the same VLAN header, if any, as the IP
1040 packet it replaces.
1041 Prerequisite: ip4
1043 get_arp(P, A);
1045 Parameters: logical port string field P, 32-bit IP address
1046 field A.
1047 Looks up A in P’s mac binding table. If an entry is found,
1049 stores its Ethernet address in eth.dst, otherwise stores
1050 00:00:00:00:00:00 in eth.dst.
1051 Example: get_arp(outport, ip4.dst);
1053 put_arp(P, A, E);
1055 Parameters: logical port string field P, 32-bit IP address
1056 field A, 48-bit Ethernet address field E.
1057 Adds or updates the entry for IP address A in logical port
1059 P’s mac binding table, setting its Ethernet address to E.
1060 Example: put_arp(inport, arp.spa, arp.sha);
1062 nd_ns { action; ... };
1064 Temporarily replaces the IPv6 packet being processed by an
1065 IPv6 Neighbor Solicitation packet and executes each nested
1066 action on the IPv6 NS packet. Actions following the nd_ns
1067 action, if any, apply to the original, unmodified packet.
1068 The IPv6 NS packet that this action operates on is initial‐
1070 ized based on the IPv6 packet being processed, as follows.
1071 These are default values that the nested actions will prob‐
1072 ably want to change:
1073 · eth.src unchanged
1075 · eth.dst set to IPv6 multicast MAC address
1077 · eth.type = 0x86dd
1079 · ip6.src copied from ip6.src
1081 · ip6.dst set to IPv6 Solicited-Node multicast address
1083 · icmp6.type = 135 (Neighbor Solicitation)
1085 · nd.target copied from ip6.dst
1087 The IPv6 NS packet has the same VLAN header, if any, as the
1089 IP packet it replaces.
1090 Prerequisite: ip6
1092 nd_na { action; ... };
1094 Temporarily replaces the IPv6 neighbor solicitation packet
1095 being processed by an IPv6 neighbor advertisement (NA)
1096 packet and executes each nested action on the NA packet.
1097 Actions following the nd_na action, if any, apply to the
1098 original, unmodified packet.
1099 The NA packet that this action operates on is initialized
1101 based on the IPv6 packet being processed, as follows. These
1102 are default values that the nested actions will probably
1103 want to change:
1104 · eth.dst exchanged with eth.src
1106 · eth.type = 0x86dd
1108 · ip6.dst copied from ip6.src
1110 · ip6.src copied from nd.target
1112 · icmp6.type = 136 (Neighbor Advertisement)
1114 · nd.target unchanged
1116 · nd.sll = 00:00:00:00:00:00
1118 · nd.tll copied from eth.dst
1120 The ND packet has the same VLAN header, if any, as the IPv6
1122 packet it replaces.
1123 Prerequisite: nd_ns
1125 nd_na_router { action; ... };
1127 Temporarily replaces the IPv6 neighbor solicitation packet
1128 being processed by an IPv6 neighbor advertisement (NA)
1129 packet, sets ND_NSO_ROUTER in the RSO flags and executes
1130 each nested action on the NA packet. Actions following the
1131 nd_na_router action, if any, apply to the original, unmodi‐
1132 fied packet.
1133 The NA packet that this action operates on is initialized
1135 based on the IPv6 packet being processed, as follows. These
1136 are default values that the nested actions will probably
1137 want to change:
1138 · eth.dst exchanged with eth.src
1140 · eth.type = 0x86dd
1142 · ip6.dst copied from ip6.src
1144 · ip6.src copied from nd.target
1146 · icmp6.type = 136 (Neighbor Advertisement)
1148 · nd.target unchanged
1150 · nd.sll = 00:00:00:00:00:00
1152 · nd.tll copied from eth.dst
1154 The ND packet has the same VLAN header, if any, as the IPv6
1156 packet it replaces.
1157 Prerequisite: nd_ns
1159 get_nd(P, A);
1161 Parameters: logical port string field P, 128-bit IPv6
1162 address field A.
1163 Looks up A in P’s mac binding table. If an entry is found,
1165 stores its Ethernet address in eth.dst, otherwise stores
1166 00:00:00:00:00:00 in eth.dst.
1167 Example: get_nd(outport, ip6.dst);
1169 put_nd(P, A, E);
1171 Parameters: logical port string field P, 128-bit IPv6
1172 address field A, 48-bit Ethernet address field E.
1173 Adds or updates the entry for IPv6 address A in logical
1175 port P’s mac binding table, setting its Ethernet address to
1176 E.
1177 Example: put_nd(inport, nd.target, nd.tll);
1179 R = put_dhcp_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1181 Parameters: one or more DHCP option/value pairs, which must
1182 include an offerip option (with code 0).
1183 Result: stored to a 1-bit subfield R.
1185 Valid only in the ingress pipeline.
1187 When this action is applied to a DHCP request packet
1189 (DHCPDISCOVER or DHCPREQUEST), it changes the packet into a
1190 DHCP reply (DHCPOFFER or DHCPACK, respectively), replaces
1191 the options by those specified as parameters, and stores 1
1192 in R.
1193 When this action is applied to a non-DHCP packet or a DHCP
1195 packet that is not DHCPDISCOVER or DHCPREQUEST, it leaves
1196 the packet unchanged and stores 0 in R.
1197 The contents of the DHCP_Option table control the DHCP
1199 option names and values that this action supports.
1200 Example: reg0[0] = put_dhcp_opts(offerip = 10.0.0.2, router
1202 = 10.0.0.1, netmask = 255.255.255.0, dns_server = {8.8.8.8,
1203 7.7.7.7});
1204 R = put_dhcpv6_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1206 Parameters: one or more DHCPv6 option/value pairs.
1207 Result: stored to a 1-bit subfield R.
1209 Valid only in the ingress pipeline.
1211 When this action is applied to a DHCPv6 request packet, it
1213 changes the packet into a DHCPv6 reply, replaces the
1214 options by those specified as parameters, and stores 1 in
1215 R.
1216 When this action is applied to a non-DHCPv6 packet or an
1218 invalid DHCPv6 request packet , it leaves the packet
1219 unchanged and stores 0 in R.
1220 The contents of the DHCPv6_Options table control the DHCPv6
1222 option names and values that this action supports.
1223 Example: reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4,
1225 server_id = 00:00:00:00:10:02,
1226 dns_server={ae70::1,ae70::2});
1227 set_queue(queue_number);
1229 Parameters: Queue number queue_number, in the range 0 to
1230 61440.
1231 This is a logical equivalent of the OpenFlow set_queue
1233 action. It affects packets that egress a hypervisor through
1234 a physical interface. For nonzero queue_number, it config‐
1235 ures packet queuing to match the settings configured for
1236 the Port_Binding with options:qdisc_queue_id matching
1237 queue_number. When queue_number is zero, it resets queuing
1238 to the default strategy.
1239 Example: set_queue(10);
1241 ct_lb;
1243 ct_lb(ip[:port]...);
1244 With one or more arguments, ct_lb commits the packet to the
1245 connection tracking table and DNATs the packet’s destina‐
1246 tion IP address (and port) to the IP address or addresses
1247 (and optional ports) specified in the string. If multiple
1248 comma-separated IP addresses are specified, each is given
1249 equal weight for picking the DNAT address. Processing auto‐
1250 matically moves on to the next table, as if next; were
1251 specified, and later tables act on the packet as modified
1252 by the connection tracker. Connection tracking state is
1253 scoped by the logical port when the action is used in a
1254 flow for a logical switch, so overlapping addresses may be
1255 used. Connection tracking state is scoped by the logical
1256 topology when the action is used in a flow for a router.
1257 Without arguments, ct_lb sends the packet to the connection
1259 tracking table to NAT the packets. If the packet is part of
1260 an established connection that was previously committed to
1261 the connection tracker via ct_lb(...), it will automati‐
1262 cally get DNATed to the same IP address as the first packet
1263 in that connection.
1264 R = dns_lookup();
1266 Parameters: No parameters.
1267 Result: stored to a 1-bit subfield R.
1269 Valid only in the ingress pipeline.
1271 When this action is applied to a valid DNS request (a UDP
1273 packet typically directed to port 53), it attempts to
1274 resolve the query using the contents of the DNS table. If
1275 it is successful, it changes the packet into a DNS reply
1276 and stores 1 in R. If the action is applied to a non-DNS
1277 packet, an invalid DNS request packet, or a valid DNS
1278 request for which the DNS table does not supply an answer,
1279 it leaves the packet unchanged and stores 0 in R.
1280 Regardless of success, the action does not make any of the
1282 changes to the flow that are necessary to direct the packet
1283 back to the requester. The logical pipeline can implement
1284 this behavior with matches and actions in later tables.
1285 Example: reg0[3] = dns_lookup();
1287 Prerequisite: udp
1289 R = put_nd_ra_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1291 Parameters: The following IPv6 ND Router Advertisement
1292 option/value pairs as defined in RFC 4861.
1293 · addr_mode
1295 Mandatory parameter which specifies the address mode
1297 flag to be set in the RA flag options field. The
1298 value of this option is a string and the following
1299 values can be defined - "slaac", "dhcpv6_stateful"
1300 and "dhcpv6_stateless".
1301 · slla
1303 Mandatory parameter which specifies the link-layer
1305 address of the interface from which the Router
1306 Advertisement is sent.
1307 · mtu
1309 Optional parameter which specifies the MTU.
1311 · prefix
1313 Optional parameter which should be specified if the
1315 addr_mode is "slaac" or "dhcpv6_stateless". The
1316 value should be an IPv6 prefix which will be used
1317 for stateless IPv6 address configuration. This
1318 option can be defined multiple times.
1319 Result: stored to a 1-bit subfield R.
1321 Valid only in the ingress pipeline.
1323 When this action is applied to an IPv6 Router solicitation
1325 request packet, it changes the packet into an IPv6 Router
1326 Advertisement reply and adds the options specified in the
1327 parameters, and stores 1 in R.
1328 When this action is applied to a non-IPv6 Router solicita‐
1330 tion packet or an invalid IPv6 request packet , it leaves
1331 the packet unchanged and stores 0 in R.
1332 Example: reg0[3] = put_nd_ra_opts(addr_mode = "slaac", slla
1334 = 00:00:00:00:10:02, prefix = aef0::/64, mtu = 1450);
1335 set_meter(rate);
1337 set_meter(rate, burst);
1338 Parameters: rate limit int field rate in kbps, burst rate
1339 limits int field burst in kbps.
1340 This action sets the rate limit for a flow.
1342 Example: set_meter(100, 1000);
1344 log(key=value, ...);
1346 Causes ovn-controller to log the packet on the chassis
1347 that processes it. Packet logging currently uses the same
1348 logging mechanism as other Open vSwitch and OVN messages,
1349 which means that whether and where log messages appear
1350 depends on the local logging configuration that can be
1351 configured with ovs-appctl, etc.
1352 The log action takes zero or more of the following key-
1354 value pair arguments that control what is logged:
1355 name=string
1357 An optional name for the ACL. The string is cur‐
1358 rently limited to 64 bytes.
1359 severity=level
1361 Indicates the severity of the event. The level is
1362 one of following (from more to less serious):
1363 alert, warning, notice, info, or debug. If a
1364 severity is not provided, the default is info.
1365 verdict=value
1367 The verdict for packets matching the flow. The
1368 value must be one of allow, deny, or reject.
1369 meter=string
1371 An optional rate-limiting meter to be applied to
1372 the logs. The string should reference a name entry
1373 from the Meter table. The only meter action that
1374 is appriopriate is drop.
1375 The following actions will likely be useful later, but they have
1377 not been thought out carefully.
1378 icmp4 { action; ... };
1380 Temporarily replaces the IPv4 packet being processed by
1381 an ICMPv4 packet and executes each nested action on the
1382 ICMPv4 packet. Actions following the icmp4 action, if
1383 any, apply to the original, unmodified packet.
1384 The ICMPv4 packet that this action operates on is ini‐
1386 tialized based on the IPv4 packet being processed, as
1387 follows. These are default values that the nested actions
1388 will probably want to change. Ethernet and IPv4 fields
1389 not listed here are not changed:
1390 · ip.proto = 1 (ICMPv4)
1392 · ip.frag = 0 (not a fragment)
1394 · ip.ttl = 255
1396 · icmp4.type = 3 (destination unreachable)
1398 · icmp4.code = 1 (host unreachable)
1400 Prerequisite: ip4
1402 icmp6 { action; ... };
1404 Temporarily replaces the IPv6 packet being processed by
1405 an ICMPv6 packet and executes each nested action on the
1406 ICMPv6 packet. Actions following the icmp6 action, if
1407 any, apply to the original, unmodified packet.
1408 The ICMPv6 packet that this action operates on is ini‐
1410 tialized based on the IPv6 packet being processed, as
1411 follows. These are default values that the nested actions
1412 will probably want to change. Ethernet and IPv6 fields
1413 not listed here are not changed:
1414 · ip.proto = 58 (ICMPv6)
1416 · ip.ttl = 255
1418 · icmp6.type = 1 (destination unreachable)
1420 · icmp6.code = 1 (administratively prohibited)
1422 Prerequisite: ip6
1424 tcp_reset;
1426 This action transforms the current TCP packet according
1427 to the following pseudocode:
1428 if (tcp.ack) {
1430 tcp.seq = tcp.ack;
1431 } else {
1432 tcp.ack = tcp.seq + length(tcp.payload);
1433 tcp.seq = 0;
1434 }
1435 tcp.flags = RST;
1436 Then, the action drops all TCP options and payload data,
1438 and updates the TCP checksum. IP ttl is set to 255.
1439 Prerequisite: tcp
1441 external_ids : stage-name: optional string
1443 Human-readable name for this flow’s stage in the pipeline.
1444 external_ids : stage-hint: optional string, containing an uuid
1446 UUID of a OVN_Northbound record that caused this logical flow to
1447 be created. Currently used only for attribute of logical flows
1448 to northbound ACL records.
1449 external_ids : source: optional string
1451 Source file and line number of the code that added this flow to
1452 the pipeline.
1453 Common Columns:
1455 The overall purpose of these columns is described under Common Columns
1457 at the beginning of this document.
1458 external_ids: map of string-string pairs
1460
1462 The rows in this table define multicast groups of logical ports. Multi‐
1463 cast groups allow a single packet transmitted over a tunnel to a hyper‐
1464 visor to be delivered to multiple VMs on that hypervisor, which uses
1465 bandwidth more efficiently.
1466 Each row in this table defines a logical multicast group numbered tun‐
1468 nel_key within datapath, whose logical ports are listed in the ports
1469 column.
1470 Summary:
1472 datapath Datapath_Binding
1473 tunnel_key integer, in range 32,768 to 65,535
1474 name string
1475 ports set of 1 or more weak reference to
1476 Port_Bindings
1477 Details:
1479 datapath: Datapath_Binding
1480 The logical datapath in which the multicast group resides.
1481 tunnel_key: integer, in range 32,768 to 65,535
1483 The value used to designate this logical egress port in tunnel
1484 encapsulations. An index forces the key to be unique within the
1485 datapath. The unusual range ensures that multicast group IDs do
1486 not overlap with logical port IDs.
1487 name: string
1489 The logical multicast group’s name. An index forces the name to
1490 be unique within the datapath. Logical flows in the ingress
1491 pipeline may output to the group just as for individual logical
1492 ports, by assigning the group’s name to outport and executing an
1493 output action.
1494 Multicast group names and logical port names share a single
1496 namespace and thus should not overlap (but the database schema
1497 cannot enforce this). To try to avoid conflicts, ovn-northd uses
1498 names that begin with _MC_.
1499 ports: set of 1 or more weak reference to Port_Bindings
1501 The logical ports included in the multicast group. All of these
1502 ports must be in the datapath logical datapath (but the database
1503 schema cannot enforce this).
1505 Each row in this table represents a meter that can be used for QoS or
1506 rate-limiting.
1507 Summary:
1509 name string (must be unique within table)
1510 unit string, either kbps or pktps
1511 bands set of 1 or more Meter_Bands
1512 Details:
1514 name: string (must be unique within table)
1515 A name for this meter.
1516 Names that begin with "__" (two underscores) are reserved for
1518 OVN internal use and should not be added manually.
1519 unit: string, either kbps or pktps
1521 The unit for rate and burst_rate parameters in the bands entry.
1522 kbps specifies kilobits per second, and pktps specifies packets
1523 per second.
1524 bands: set of 1 or more Meter_Bands
1526 The bands associated with this meter. Each band specifies a rate
1527 above which the band is to take the action action. If multiple
1528 bands’ rates are exceeded, then the band with the highest rate
1529 among the exceeded bands is selected.
1530
1532 Each row in this table represents a meter band which specifies the rate
1533 above which the configured action should be applied. These bands are
1534 referenced by the bands column in the Meter table.
1535 Summary:
1537 action string, must be drop
1538 rate integer, in range 1 to 4,294,967,295
1539 burst_size integer, in range 0 to 4,294,967,295
1540 Details:
1542 action: string, must be drop
1543 The action to execute when this band matches. The only supported
1544 action is drop.
1545 rate: integer, in range 1 to 4,294,967,295
1547 The rate limit for this band, in kilobits per second or bits per
1548 second, depending on whether the parent Meter entry’s unit col‐
1549 umn specified kbps or pktps.
1550 burst_size: integer, in range 0 to 4,294,967,295
1552 The maximum burst allowed for the band in kilobits or packets,
1553 depending on whether kbps or pktps was selected in the parent
1554 Meter entry’s unit column. If the size is zero, the switch is
1555 free to select some reasonable value depending on its configura‐
1556 tion.
1558 Each row in this table represents a logical datapath, which implements
1559 a logical pipeline among the ports in the Port_Binding table associated
1560 with it. In practice, the pipeline in a given logical datapath imple‐
1561 ments either a logical switch or a logical router.
1562 The main purpose of a row in this table is provide a physical binding
1564 for a logical datapath. A logical datapath does not have a physical
1565 location, so its physical binding information is limited: just tun‐
1566 nel_key. The rest of the data in this table does not affect packet for‐
1567 warding.
1568 Summary:
1570 tunnel_key integer, in range 1 to 16,777,215 (must
1571 be unique within table)
1572 OVN_Northbound Relationship:
1573 external_ids : logical-switch
1574 optional string, containing an uuid
1575 external_ids : logical-router
1576 optional string, containing an uuid
1577 Naming:
1578 external_ids : name optional string
1579 external_ids : name2 optional string
1580 Common Columns:
1581 external_ids map of string-string pairs
1582 Details:
1584 tunnel_key: integer, in range 1 to 16,777,215 (must be unique within
1585 table)
1586 The tunnel key value to which the logical datapath is bound. The
1587 Tunnel Encapsulation section in ovn-architecture(7) describes
1588 how tunnel keys are constructed for each supported encapsula‐
1589 tion.
1590 OVN_Northbound Relationship:
1592 Each row in Datapath_Binding is associated with some logical datapath.
1594 ovn-northd uses these keys to track the association of a logical data‐
1595 path with concepts in the OVN_Northbound database.
1596 external_ids : logical-switch: optional string, containing an uuid
1598 For a logical datapath that represents a logical switch,
1599 ovn-northd stores in this key the UUID of the corresponding Log‐
1600 ical_Switch row in the OVN_Northbound database.
1601 external_ids : logical-router: optional string, containing an uuid
1603 For a logical datapath that represents a logical router,
1604 ovn-northd stores in this key the UUID of the corresponding Log‐
1605 ical_Router row in the OVN_Northbound database.
1606 Naming:
1608 ovn-northd copies these from the name fields in the OVN_Northbound
1610 database, either from name and external_ids:neutron:router_name in the
1611 Logical_Router table or from name and external_ids:neutron:network_name
1612 in the Logical_Switch table.
1613 external_ids : name: optional string
1615 A name for the logical datapath.
1616 external_ids : name2: optional string
1618 Another name for the logical datapath.
1619 Common Columns:
1621 The overall purpose of these columns is described under Common Columns
1623 at the beginning of this document.
1624 external_ids: map of string-string pairs
1626
1628 Each row in this table binds a logical port to a realization. For most
1629 logical ports, this means binding to some physical location, for exam‐
1630 ple by binding a logical port to a VIF that belongs to a VM running on
1631 a particular hypervisor. Other logical ports, such as logical patch
1632 ports, can be realized without a specific physical location, but their
1633 bindings are still expressed through rows in this table.
1634 For every Logical_Switch_Port record in OVN_Northbound database,
1636 ovn-northd creates a record in this table. ovn-northd populates and
1637 maintains every column except the chassis column, which it leaves empty
1638 in new records.
1639 ovn-controller/ovn-controller-vtep populates the chassis column for the
1641 records that identify the logical ports that are located on its hyper‐
1642 visor/gateway, which ovn-controller/ovn-controller-vtep in turn finds
1643 out by monitoring the local hypervisor’s Open_vSwitch database, which
1644 identifies logical ports via the conventions described in Integra‐
1645 tionGuide.rst. (The exceptions are for Port_Binding records with type
1646 of l3gateway, whose locations are identified by ovn-northd via the
1647 options:l3gateway-chassis column in this table. ovn-controller is still
1648 responsible to populate the chassis column.)
1649 When a chassis shuts down gracefully, it should clean up the chassis
1651 column that it previously had populated. (This is not critical because
1652 resources hosted on the chassis are equally unreachable regardless of
1653 whether their rows are present.) To handle the case where a VM is shut
1654 down abruptly on one chassis, then brought up again on a different one,
1655 ovn-controller/ovn-controller-vtep must overwrite the chassis column
1656 with new information.
1657 Summary:
1659 Core Features:
1660 datapath Datapath_Binding
1661 logical_port string (must be unique within table)
1662 chassis optional weak reference to Chassis
1663 gateway_chassis set of Gateway_Chassiss
1664 tunnel_key integer, in range 1 to 32,767
1665 mac set of strings
1666 type string
1667 Patch Options:
1668 options : peer optional string
1669 nat_addresses set of strings
1670 L3 Gateway Options:
1671 options : peer optional string
1672 options : l3gateway-chassis
1673 optional string
1674 options : nat-addresses optional string
1675 nat_addresses set of strings
1676 Localnet Options:
1677 options : network_name optional string
1678 tag optional integer, in range 1 to 4,095
1679 L2 Gateway Options:
1680 options : network_name optional string
1681 options : l2gateway-chassis
1682 optional string
1683 tag optional integer, in range 1 to 4,095
1684 VTEP Options:
1685 options : vtep-physical-switch
1686 optional string
1687 options : vtep-logical-switch
1688 optional string
1689 VMI (or VIF) Options:
1690 options : requested-chassis
1691 optional string
1692 options : qos_max_rate optional string
1693 options : qos_burst optional string
1694 options : qdisc_queue_id optional string, containing an integer,
1695 in range 1 to 61,440
1696 Chassis Redirect Options:
1697 options : distributed-port optional string
1698 options : redirect-chassis optional string
1699 Nested Containers:
1700 parent_port optional string
1701 tag optional integer, in range 1 to 4,095
1702 Naming:
1703 external_ids : name optional string
1704 Common Columns:
1705 external_ids map of string-string pairs
1706 Details:
1708 Core Features:
1709 datapath: Datapath_Binding
1711 The logical datapath to which the logical port belongs.
1712 logical_port: string (must be unique within table)
1714 A logical port, taken from name in the OVN_Northbound database’s
1715 Logical_Switch_Port table. OVN does not prescribe a particular
1716 format for the logical port ID.
1717 chassis: optional weak reference to Chassis
1719 The meaning of this column depends on the value of the type col‐
1720 umn. This is the meaning for each type
1721 (empty string)
1723 The physical location of the logical port. To success‐
1724 fully identify a chassis, this column must be a Chassis
1725 record. This is populated by ovn-controller.
1726 vtep The physical location of the hardware_vtep gateway. To
1728 successfully identify a chassis, this column must be a
1729 Chassis record. This is populated by ovn-controller-vtep.
1730 localnet
1732 Always empty. A localnet port is realized on every chas‐
1733 sis that has connectivity to the corresponding physical
1734 network.
1735 localport
1737 Always empty. A localport port is present on every chas‐
1738 sis.
1739 l3gateway
1741 The physical location of the L3 gateway. To successfully
1742 identify a chassis, this column must be a Chassis record.
1743 This is populated by ovn-controller based on the value of
1744 the options:l3gateway-chassis column in this table.
1745 l2gateway
1747 The physical location of this L2 gateway. To successfully
1748 identify a chassis, this column must be a Chassis record.
1749 This is populated by ovn-controller based on the value of
1750 the options:l2gateway-chassis column in this table.
1751 gateway_chassis: set of Gateway_Chassiss
1753 A list of Gateway_Chassis.
1754 This should only be populated for ports with type set to chas‐
1756 sisredirect. This column defines the list of chassis used as
1757 gateways where traffic will be redirected through.
1758 tunnel_key: integer, in range 1 to 32,767
1760 A number that represents the logical port in the key (e.g. STT
1761 key or Geneve TLV) field carried within tunnel protocol packets.
1762 The tunnel ID must be unique within the scope of a logical data‐
1764 path.
1765 mac: set of strings
1767 The Ethernet address or addresses used as a source address on
1768 the logical port, each in the form xx:xx:xx:xx:xx:xx. The string
1769 unknown is also allowed to indicate that the logical port has an
1770 unknown set of (additional) source addresses.
1771 A VM interface would ordinarily have a single Ethernet address.
1773 A gateway port might initially only have unknown, and then add
1774 MAC addresses to the set as it learns new source addresses.
1775 type: string
1777 A type for this logical port. Logical ports can be used to model
1778 other types of connectivity into an OVN logical switch. The fol‐
1779 lowing types are defined:
1780 (empty string)
1782 VM (or VIF) interface.
1783 patch One of a pair of logical ports that act as if connected
1785 by a patch cable. Useful for connecting two logical data‐
1786 paths, e.g. to connect a logical router to a logical
1787 switch or to another logical router.
1788 l3gateway
1790 One of a pair of logical ports that act as if connected
1791 by a patch cable across multiple chassis. Useful for con‐
1792 necting a logical switch with a Gateway router (which is
1793 only resident on a particular chassis).
1794 localnet
1796 A connection to a locally accessible network from each
1797 ovn-controller instance. A logical switch can only have a
1798 single localnet port attached. This is used to model
1799 direct connectivity to an existing network.
1800 localport
1802 A connection to a local VIF. Traffic that arrives on a
1803 localport is never forwarded over a tunnel to another
1804 chassis. These ports are present on every chassis and
1805 have the same address in all of them. This is used to
1806 model connectivity to local services that run on every
1807 hypervisor.
1808 l2gateway
1810 An L2 connection to a physical network. The chassis this
1811 Port_Binding is bound to will serve as an L2 gateway to
1812 the network named by options:network_name.
1813 vtep A port to a logical switch on a VTEP gateway chassis. In
1815 order to get this port correctly recognized by the OVN
1816 controller, the options:vtep-physical-switch and
1817 options:vtep-logical-switch must also be defined.
1818 chassisredirect
1820 A logical port that represents a particular instance,
1821 bound to a specific chassis, of an otherwise distributed
1822 parent port (e.g. of type patch). A chassisredirect port
1823 should never be used as an inport. When an ingress pipe‐
1824 line sets the outport, it may set the value to a logical
1825 port of type chassisredirect. This will cause the packet
1826 to be directed to a specific chassis to carry out the
1827 egress pipeline. At the beginning of the egress pipeline,
1828 the outport will be reset to the value of the distributed
1829 port.
1830 Patch Options:
1832 These options apply to logical ports with type of patch.
1834 options : peer: optional string
1836 The logical_port in the Port_Binding record for the other side
1837 of the patch. The named logical_port must specify this logi‐
1838 cal_port in its own peer option. That is, the two patch logical
1839 ports must have reversed logical_port and peer values.
1840 nat_addresses: set of strings
1842 MAC address followed by a list of SNAT and DNAT external IP
1843 addresses, followed by is_chassis_resident("lport"), where lport
1844 is the name of a logical port on the same chassis where the cor‐
1845 responding NAT rules are applied. This is used to send gratu‐
1846 itous ARPs for SNAT and DNAT external IP addresses via localnet,
1847 from the chassis where lport resides. Example: 80:fa:5b:06:72:b7
1848 158.36.44.22 158.36.44.24 is_chassis_resident("foo1"). This
1849 would result in generation of gratuitous ARPs for IP addresses
1850 158.36.44.22 and 158.36.44.24 with a MAC address of
1851 80:fa:5b:06:72:b7 from the chassis where the logical port "foo1"
1852 resides.
1853 L3 Gateway Options:
1855 These options apply to logical ports with type of l3gateway.
1857 options : peer: optional string
1859 The logical_port in the Port_Binding record for the other side
1860 of the ’l3gateway’ port. The named logical_port must specify
1861 this logical_port in its own peer option. That is, the two
1862 ’l3gateway’ logical ports must have reversed logical_port and
1863 peer values.
1864 options : l3gateway-chassis: optional string
1866 The chassis in which the port resides.
1867 options : nat-addresses: optional string
1869 MAC address of the l3gateway port followed by a list of SNAT and
1870 DNAT external IP addresses. This is used to send gratuitous ARPs
1871 for SNAT and DNAT external IP addresses via localnet. Example:
1872 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
1873 in generation of gratuitous ARPs for IP addresses 158.36.44.22
1874 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
1875 is used in OVS versions prior to 2.8.
1876 nat_addresses: set of strings
1878 MAC address of the l3gateway port followed by a list of SNAT and
1879 DNAT external IP addresses. This is used to send gratuitous ARPs
1880 for SNAT and DNAT external IP addresses via localnet. Example:
1881 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
1882 in generation of gratuitous ARPs for IP addresses 158.36.44.22
1883 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
1884 is used in OVS version 2.8 and later versions.
1885 Localnet Options:
1887 These options apply to logical ports with type of localnet.
1889 options : network_name: optional string
1891 Required. ovn-controller uses the configuration entry
1892 ovn-bridge-mappings to determine how to connect to this network.
1893 ovn-bridge-mappings is a list of network names mapped to a local
1894 OVS bridge that provides access to that network. An example of
1895 configuring ovn-bridge-mappings would be: .IP
1896 $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
1897 When a logical switch has a localnet port attached, every chas‐
1899 sis that may have a local vif attached to that logical switch
1900 must have a bridge mapping configured to reach that localnet.
1901 Traffic that arrives on a localnet port is never forwarded over
1902 a tunnel to another chassis.
1903 tag: optional integer, in range 1 to 4,095
1905 If set, indicates that the port represents a connection to a
1906 specific VLAN on a locally accessible network. The VLAN ID is
1907 used to match incoming traffic and is also added to outgoing
1908 traffic.
1909 L2 Gateway Options:
1911 These options apply to logical ports with type of l2gateway.
1913 options : network_name: optional string
1915 Required. ovn-controller uses the configuration entry
1916 ovn-bridge-mappings to determine how to connect to this network.
1917 ovn-bridge-mappings is a list of network names mapped to a local
1918 OVS bridge that provides access to that network. An example of
1919 configuring ovn-bridge-mappings would be: .IP
1920 $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
1921 When a logical switch has a l2gateway port attached, the chassis
1923 that the l2gateway port is bound to must have a bridge mapping
1924 configured to reach the network identified by network_name.
1925 options : l2gateway-chassis: optional string
1927 Required. The chassis in which the port resides.
1928 tag: optional integer, in range 1 to 4,095
1930 If set, indicates that the gateway is connected to a specific
1931 VLAN on the physical network. The VLAN ID is used to match
1932 incoming traffic and is also added to outgoing traffic.
1933 VTEP Options:
1935 These options apply to logical ports with type of vtep.
1937 options : vtep-physical-switch: optional string
1939 Required. The name of the VTEP gateway.
1940 options : vtep-logical-switch: optional string
1942 Required. A logical switch name connected by the VTEP gateway.
1943 Must be set when type is vtep.
1944 VMI (or VIF) Options:
1946 These options apply to logical ports with type having (empty string)
1948 options : requested-chassis: optional string
1950 If set, identifies a specific chassis (by name or hostname) that
1951 is allowed to bind this port. Using this option will prevent
1952 thrashing between two chassis trying to bind the same port dur‐
1953 ing a live migration. It can also prevent similar thrashing due
1954 to a mis-configuration, if a port is accidentally created on
1955 more than one chassis.
1956 options : qos_max_rate: optional string
1958 If set, indicates the maximum rate for data sent from this
1959 interface, in bit/s. The traffic will be shaped according to
1960 this limit.
1961 options : qos_burst: optional string
1963 If set, indicates the maximum burst size for data sent from this
1964 interface, in bits.
1965 options : qdisc_queue_id: optional string, containing an integer, in
1967 range 1 to 61,440
1968 Indicates the queue number on the physical device. This is same
1969 as the queue_id used in OpenFlow in struct ofp_action_enqueue.
1970 Chassis Redirect Options:
1972 These options apply to logical ports with type of chassisredirect.
1974 options : distributed-port: optional string
1976 The name of the distributed port for which this chassisredirect
1977 port represents a particular instance.
1978 options : redirect-chassis: optional string
1980 The chassis that this chassisredirect port is bound to. This is
1981 taken from options:redirect-chassis in the OVN_Northbound data‐
1982 base’s Logical_Router_Port table.
1983 Nested Containers:
1985 These columns support containers nested within a VM. Specifically, they
1987 are used when type is empty and logical_port identifies the interface
1988 of a container spawned inside a VM. They are empty for containers or
1989 VMs that run directly on a hypervisor.
1990 parent_port: optional string
1992 This is taken from parent_name in the OVN_Northbound database’s
1993 Logical_Switch_Port table.
1994 tag: optional integer, in range 1 to 4,095
1996 Identifies the VLAN tag in the network traffic associated with
1997 that container’s network interface.
1998 This column is used for a different purpose when type is local‐
2000 net (see Localnet Options, above) or l2gateway (see L2 Gateway
2001 Options, above).
2002 Naming:
2004 external_ids : name: optional string
2006 For a logical switch port, ovn-northd copies this from exter‐
2007 nal_ids:neutron:port_name in the Logical_Switch_Port table in
2008 the OVN_Northbound database, if it is a nonempty string.
2009 For a logical switch port, ovn-northd does not currently set
2011 this key.
2012 Common Columns:
2014 external_ids: map of string-string pairs
2016 See External IDs at the beginning of this document.
2017 The ovn-northd program populates this column with all entries
2019 into the external_ids column of the Logical_Switch_Port table of
2020 the OVN_Northbound database.
2021
2023 Each row in this table specifies a binding from an IP address to an
2024 Ethernet address that has been discovered through ARP (for IPv4) or
2025 neighbor discovery (for IPv6). This table is primarily used to discover
2026 bindings on physical networks, because IP-to-MAC bindings for virtual
2027 machines are usually populated statically into the Port_Binding table.
2028 This table expresses a functional relationship: MAC_Binding(logi‐
2030 cal_port, ip) = mac.
2031 In outline, the lifetime of a logical router’s MAC binding looks like
2033 this:
2034 1.
2036 On hypervisor 1, a logical router determines that a packet
2037 should be forwarded to IP address A on one of its router
2038 ports. It uses its logical flow table to determine that A
2039 lacks a static IP-to-MAC binding and the get_arp action to
2040 determine that it lacks a dynamic IP-to-MAC binding.
2041 2.
2043 Using an OVN logical arp action, the logical router generates
2044 and sends a broadcast ARP request to the router port. It drops
2045 the IP packet.
2046 3.
2048 The logical switch attached to the router port delivers the
2049 ARP request to all of its ports. (It might make sense to
2050 deliver it only to ports that have no static IP-to-MAC bind‐
2051 ings, but this could also be surprising behavior.)
2052 4.
2054 A host or VM on hypervisor 2 (which might be the same as
2055 hypervisor 1) attached to the logical switch owns the IP
2056 address in question. It composes an ARP reply and unicasts it
2057 to the logical router port’s Ethernet address.
2058 5.
2060 The logical switch delivers the ARP reply to the logical
2061 router port.
2062 6.
2064 The logical router flow table executes a put_arp action. To
2065 record the IP-to-MAC binding, ovn-controller adds a row to the
2066 MAC_Binding table.
2067 7.
2069 On hypervisor 1, ovn-controller receives the updated MAC_Bind‐
2070 ing table from the OVN southbound database. The next packet
2071 destined to A through the logical router is sent directly to
2072 the bound Ethernet address.
2073 Summary:
2075 logical_port string
2076 ip string
2077 mac string
2078 datapath Datapath_Binding
2079 Details:
2081 logical_port: string
2082 The logical port on which the binding was discovered.
2083 ip: string
2085 The bound IP address.
2086 mac: string
2088 The Ethernet address to which the IP is bound.
2089 datapath: Datapath_Binding
2091 The logical datapath to which the logical port belongs.
2092
2094 Each row in this table stores the DHCP Options supported by native OVN
2095 DHCP. ovn-northd populates this table with the supported DHCP options.
2096 ovn-controller looks up this table to get the DHCP codes of the DHCP
2097 options defined in the "put_dhcp_opts" action. Please refer to the RFC
2098 2132 "https://tools.ietf.org/html/rfc2132" for the possible list of
2099 DHCP options that can be defined here.
2100 Summary:
2102 name string
2103 code integer, in range 0 to 254
2104 type string, one of bool, ipv4, static_routes,
2105 str, uint16, uint32, or uint8
2106 Details:
2108 name: string
2109 Name of the DHCP option.
2110 Example. name="router"
2112 code: integer, in range 0 to 254
2114 DHCP option code for the DHCP option as defined in the RFC 2132.
2115 Example. code=3
2117 type: string, one of bool, ipv4, static_routes, str, uint16, uint32, or
2119 uint8
2120 Data type of the DHCP option code.
2121 value: bool
2123 This indicates that the value of the DHCP option is a
2124 bool.
2125 Example. "name=ip_forward_enable", "code=19",
2127 "type=bool".
2128 put_dhcp_opts(..., ip_forward_enable = 1,...)
2130 value: uint8
2132 This indicates that the value of the DHCP option is an
2133 unsigned int8 (8 bits)
2134 Example. "name=default_ttl", "code=23", "type=uint8".
2136 put_dhcp_opts(..., default_ttl = 50,...)
2138 value: uint16
2140 This indicates that the value of the DHCP option is an
2141 unsigned int16 (16 bits).
2142 Example. "name=mtu", "code=26", "type=uint16".
2144 put_dhcp_opts(..., mtu = 1450,...)
2146 value: uint32
2148 This indicates that the value of the DHCP option is an
2149 unsigned int32 (32 bits).
2150 Example. "name=lease_time", "code=51", "type=uint32".
2152 put_dhcp_opts(..., lease_time = 86400,...)
2154 value: ipv4
2156 This indicates that the value of the DHCP option is an
2157 IPv4 address or addresses.
2158 Example. "name=router", "code=3", "type=ipv4".
2160 put_dhcp_opts(..., router = 10.0.0.1,...)
2162 Example. "name=dns_server", "code=6", "type=ipv4".
2164 put_dhcp_opts(..., dns_server = {8.8.8.8 7.7.7.7},...)
2166 value: static_routes
2168 This indicates that the value of the DHCP option contains
2169 a pair of IPv4 route and next hop addresses.
2170 Example. "name=classless_static_route", "code=121",
2172 "type=static_routes".
2173 put_dhcp_opts(..., classless_static_route =
2175 {30.0.0.0/24,10.0.0.4,0.0.0.0/0,10.0.0.1}...)
2176 value: str
2178 This indicates that the value of the DHCP option is a
2179 string.
2180 Example. "name=host_name", "code=12", "type=str".
2182
2184 Each row in this table stores the DHCPv6 Options supported by native
2185 OVN DHCPv6. ovn-northd populates this table with the supported DHCPv6
2186 options. ovn-controller looks up this table to get the DHCPv6 codes of
2187 the DHCPv6 options defined in the put_dhcpv6_opts action. Please refer
2188 to RFC 3315 and RFC 3646 for the list of DHCPv6 options that can be
2189 defined here.
2190 Summary:
2192 name string
2193 code integer, in range 0 to 254
2194 type string, one of ipv6, mac, or str
2195 Details:
2197 name: string
2198 Name of the DHCPv6 option.
2199 Example. name="ia_addr"
2201 code: integer, in range 0 to 254
2203 DHCPv6 option code for the DHCPv6 option as defined in the
2204 appropriate RFC.
2205 Example. code=3
2207 type: string, one of ipv6, mac, or str
2209 Data type of the DHCPv6 option code.
2210 value: ipv6
2212 This indicates that the value of the DHCPv6 option is an
2213 IPv6 address(es).
2214 Example. "name=ia_addr", "code=5", "type=ipv6".
2216 put_dhcpv6_opts(..., ia_addr = ae70::4,...)
2218 value: str
2220 This indicates that the value of the DHCPv6 option is a
2221 string.
2222 Example. "name=domain_search", "code=24", "type=str".
2224 put_dhcpv6_opts(..., domain_search = ovn.domain,...)
2226 value: mac
2228 This indicates that the value of the DHCPv6 option is a
2229 MAC address.
2230 Example. "name=server_id", "code=2", "type=mac".
2232 put_dhcpv6_opts(..., server_id = 01:02:03:04L05:06,...)
2234
2236 Configuration for a database connection to an Open vSwitch database
2237 (OVSDB) client.
2238 This table primarily configures the Open vSwitch database server
2240 (ovsdb-server).
2241 The Open vSwitch database server can initiate and maintain active con‐
2243 nections to remote clients. It can also listen for database connec‐
2244 tions.
2245 Summary:
2247 Core Features:
2248 target string (must be unique within table)
2249 read_only boolean
2250 role string
2251 Client Failure Detection and Handling:
2252 max_backoff optional integer, at least 1,000
2253 inactivity_probe optional integer
2254 Status:
2255 is_connected boolean
2256 status : last_error optional string
2257 status : state optional string, one of ACTIVE, BACKOFF,
2258 CONNECTING, IDLE, or VOID
2259 status : sec_since_connect optional string, containing an integer,
2260 at least 0
2261 status : sec_since_disconnect
2262 optional string, containing an integer,
2263 at least 0
2264 status : locks_held optional string
2265 status : locks_waiting optional string
2266 status : locks_lost optional string
2267 status : n_connections optional string, containing an integer,
2268 at least 2
2269 status : bound_port optional string, containing an integer
2270 Common Columns:
2271 external_ids map of string-string pairs
2272 other_config map of string-string pairs
2273 Details:
2275 Core Features:
2276 target: string (must be unique within table)
2278 Connection methods for clients.
2279 The following connection methods are currently supported:
2281 ssl:host[:port]
2283 The specified SSL port on the given host, which can
2284 either be a DNS name (if built with unbound library) or
2285 an IP address. A valid SSL configuration must be provided
2286 when this form is used, this configuration can be speci‐
2287 fied via command-line options or the SSL table.
2288 If port is not specified, it defaults to 6640.
2290 SSL support is an optional feature that is not always
2292 built as part of Open vSwitch.
2293 tcp:host[:port]
2295 The specified TCP port on the given host, which can
2296 either be a DNS name (if built with unbound library) or
2297 an IP address (IPv4 or IPv6). If host is an IPv6 address,
2298 wrap it in square brackets, e.g. tcp:[::1]:6640.
2299 If port is not specified, it defaults to 6640.
2301 pssl:[port][:host]
2303 Listens for SSL connections on the specified TCP port.
2304 Specify 0 for port to have the kernel automatically
2305 choose an available port. If host, which can either be a
2306 DNS name (if built with unbound library) or an IP
2307 address, is specified, then connections are restricted to
2308 the resolved or specified local IP address (either IPv4
2309 or IPv6 address). If host is an IPv6 address, wrap in
2310 square brackets, e.g. pssl:6640:[::1]. If host is not
2311 specified then it listens only on IPv4 (but not IPv6)
2312 addresses. A valid SSL configuration must be provided
2313 when this form is used, this can be specified either via
2314 command-line options or the SSL table.
2315 If port is not specified, it defaults to 6640.
2317 SSL support is an optional feature that is not always
2319 built as part of Open vSwitch.
2320 ptcp:[port][:host]
2322 Listens for connections on the specified TCP port. Spec‐
2323 ify 0 for port to have the kernel automatically choose an
2324 available port. If host, which can either be a DNS name
2325 (if built with unbound library) or an IP address, is
2326 specified, then connections are restricted to the
2327 resolved or specified local IP address (either IPv4 or
2328 IPv6 address). If host is an IPv6 address, wrap it in
2329 square brackets, e.g. ptcp:6640:[::1]. If host is not
2330 specified then it listens only on IPv4 addresses.
2331 If port is not specified, it defaults to 6640.
2333 When multiple clients are configured, the target values must be
2335 unique. Duplicate target values yield unspecified results.
2336 read_only: boolean
2338 true to restrict these connections to read-only transactions,
2339 false to allow them to modify the database.
2340 role: string
2342 String containing role name for this connection entry.
2343 Client Failure Detection and Handling:
2345 max_backoff: optional integer, at least 1,000
2347 Maximum number of milliseconds to wait between connection
2348 attempts. Default is implementation-specific.
2349 inactivity_probe: optional integer
2351 Maximum number of milliseconds of idle time on connection to the
2352 client before sending an inactivity probe message. If Open
2353 vSwitch does not communicate with the client for the specified
2354 number of seconds, it will send a probe. If a response is not
2355 received for the same additional amount of time, Open vSwitch
2356 assumes the connection has been broken and attempts to recon‐
2357 nect. Default is implementation-specific. A value of 0 disables
2358 inactivity probes.
2359 Status:
2361 Key-value pair of is_connected is always updated. Other key-value pairs
2363 in the status columns may be updated depends on the target type.
2364 When target specifies a connection method that listens for inbound con‐
2366 nections (e.g. ptcp: or punix:), both n_connections and is_connected
2367 may also be updated while the remaining key-value pairs are omitted.
2368 On the other hand, when target specifies an outbound connection, all
2370 key-value pairs may be updated, except the above-mentioned two key-
2371 value pairs associated with inbound connection targets. They are omit‐
2372 ted.
2373 is_connected: boolean
2375 true if currently connected to this client, false otherwise.
2376 status : last_error: optional string
2378 A human-readable description of the last error on the connection
2379 to the manager; i.e. strerror(errno). This key will exist only
2380 if an error has occurred.
2381 status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
2383 IDLE, or VOID
2384 The state of the connection to the manager:
2385 VOID Connection is disabled.
2387 BACKOFF
2389 Attempting to reconnect at an increasing period.
2390 CONNECTING
2392 Attempting to connect.
2393 ACTIVE Connected, remote host responsive.
2395 IDLE Connection is idle. Waiting for response to keep-alive.
2397 These values may change in the future. They are provided only
2399 for human consumption.
2400 status : sec_since_connect: optional string, containing an integer, at
2402 least 0
2403 The amount of time since this client last successfully connected
2404 to the database (in seconds). Value is empty if client has never
2405 successfully been connected.
2406 status : sec_since_disconnect: optional string, containing an integer,
2408 at least 0
2409 The amount of time since this client last disconnected from the
2410 database (in seconds). Value is empty if client has never dis‐
2411 connected.
2412 status : locks_held: optional string
2414 Space-separated list of the names of OVSDB locks that the con‐
2415 nection holds. Omitted if the connection does not hold any
2416 locks.
2417 status : locks_waiting: optional string
2419 Space-separated list of the names of OVSDB locks that the con‐
2420 nection is currently waiting to acquire. Omitted if the connec‐
2421 tion is not waiting for any locks.
2422 status : locks_lost: optional string
2424 Space-separated list of the names of OVSDB locks that the con‐
2425 nection has had stolen by another OVSDB client. Omitted if no
2426 locks have been stolen from this connection.
2427 status : n_connections: optional string, containing an integer, at
2429 least 2
2430 When target specifies a connection method that listens for
2431 inbound connections (e.g. ptcp: or pssl:) and more than one con‐
2432 nection is actually active, the value is the number of active
2433 connections. Otherwise, this key-value pair is omitted.
2434 status : bound_port: optional string, containing an integer
2436 When target is ptcp: or pssl:, this is the TCP port on which the
2437 OVSDB server is listening. (This is particularly useful when
2438 target specifies a port of 0, allowing the kernel to choose any
2439 available port.)
2440 Common Columns:
2442 The overall purpose of these columns is described under Common Columns
2444 at the beginning of this document.
2445 external_ids: map of string-string pairs
2447 other_config: map of string-string pairs
2449
2451 SSL configuration for ovn-sb database access.
2452 Summary:
2454 private_key string
2455 certificate string
2456 ca_cert string
2457 bootstrap_ca_cert boolean
2458 ssl_protocols string
2459 ssl_ciphers string
2460 Common Columns:
2461 external_ids map of string-string pairs
2462 Details:
2464 private_key: string
2465 Name of a PEM file containing the private key used as the
2466 switch’s identity for SSL connections to the controller.
2467 certificate: string
2469 Name of a PEM file containing a certificate, signed by the cer‐
2470 tificate authority (CA) used by the controller and manager, that
2471 certifies the switch’s private key, identifying a trustworthy
2472 switch.
2473 ca_cert: string
2475 Name of a PEM file containing the CA certificate used to verify
2476 that the switch is connected to a trustworthy controller.
2477 bootstrap_ca_cert: boolean
2479 If set to true, then Open vSwitch will attempt to obtain the CA
2480 certificate from the controller on its first SSL connection and
2481 save it to the named PEM file. If it is successful, it will
2482 immediately drop the connection and reconnect, and from then on
2483 all SSL connections must be authenticated by a certificate
2484 signed by the CA certificate thus obtained. This option exposes
2485 the SSL connection to a man-in-the-middle attack obtaining the
2486 initial CA certificate. It may still be useful for bootstrap‐
2487 ping.
2488 ssl_protocols: string
2490 List of SSL protocols to be enabled for SSL connections. The
2491 default when this option is omitted is TLSv1,TLSv1.1,TLSv1.2.
2492 ssl_ciphers: string
2494 List of ciphers (in OpenSSL cipher string format) to be sup‐
2495 ported for SSL connections. The default when this option is
2496 omitted is HIGH:!aNULL:!MD5.
2497 Common Columns:
2499 The overall purpose of these columns is described under Common Columns
2501 at the beginning of this document.
2502 external_ids: map of string-string pairs
2504
2506 Each row in this table stores the DNS records. The OVN action
2507 dns_lookup uses this table for DNS resolution.
2508 Summary:
2510 records map of string-string pairs
2511 datapaths set of 1 or more Datapath_Bindings
2512 Common Columns:
2513 external_ids map of string-string pairs
2514 Details:
2516 records: map of string-string pairs
2517 Key-value pair of DNS records with DNS query name as the key and
2518 a string of IP address(es) separated by comma or space as the
2519 value.
2520 Example: "vm1.ovn.org" = "10.0.0.4 aef0::4"
2522 datapaths: set of 1 or more Datapath_Bindings
2524 The DNS records defined in the column records will be applied
2525 only to the DNS queries originating from the datapaths defined
2526 in this column.
2527 Common Columns:
2529 external_ids: map of string-string pairs
2531 See External IDs at the beginning of this document.
2532
2534 Role table for role-based access controls.
2535 Summary:
2537 name string
2538 permissions map of string-weak reference to RBAC_Per‐
2539 mission pairs
2540 Details:
2542 name: string
2543 The role name, corresponding to the role column in the Connec‐
2544 tion table.
2545 permissions: map of string-weak reference to RBAC_Permission pairs
2547 A mapping of table names to rows in the RBAC_Permission table.
2548
2550 Permissions table for role-based access controls.
2551 Summary:
2553 table string
2554 authorization set of strings
2555 insert_delete boolean
2556 update set of strings
2557 Details:
2559 table: string
2560 Name of table to which this row applies.
2561 authorization: set of strings
2563 Set of strings identifying columns and column:key pairs to be
2564 compared with client ID. At least one match is required in order
2565 to be authorized. A zero-length string is treated as a special
2566 value indicating all clients should be considered authorized.
2567 insert_delete: boolean
2569 When "true", row insertions and authorized row deletions are
2570 permitted.
2571 update: set of strings
2573 Set of strings identifying columns and column:key pairs that
2574 authorized clients are allowed to modify.
2575
2577 Association of Port_Binding rows of type chassisredirect to a Chassis.
2578 The traffic going out through a specific chassisredirect port will be
2579 redirected to a chassis, or a set of them in high availability configu‐
2580 rations.
2581 Summary:
2583 name string (must be unique within table)
2584 chassis optional weak reference to Chassis
2585 priority integer, in range 0 to 32,767
2586 options map of string-string pairs
2587 Common Columns:
2588 external_ids map of string-string pairs
2589 Details:
2591 name: string (must be unique within table)
2592 Name of the Gateway_Chassis.
2593 A suggested, but not required naming convention is
2595 ${port_name}_${chassis_name}.
2596 chassis: optional weak reference to Chassis
2598 The Chassis to which we send the traffic.
2599 priority: integer, in range 0 to 32,767
2601 This is the priority the specific Chassis among all Gate‐
2602 way_Chassis belonging to the same Port_Binding.
2603 options: map of string-string pairs
2605 Reserved for future use.
2606 Common Columns:
2608 The overall purpose of these columns is described under Common Columns
2610 at the beginning of this document.
2611 external_ids: map of string-string pairs
2613Open vSwitch 2.10.1 DB Schema 1.16.0 ovn-sb(5)