1ovn-sb(5) Open vSwitch Manual ovn-sb(5)
2
6 ovn-sb - OVN_Southbound database schema
7 This database holds logical and physical configuration and state for
9 the Open Virtual Network (OVN) system to support virtual network
10 abstraction. For an introduction to OVN, please see ovn-architec‐
11 ture(7).
12 The OVN Southbound database sits at the center of the OVN architecture.
14 It is the one component that speaks both southbound directly to all the
15 hypervisors and gateways, via ovn-controller/ovn-controller-vtep, and
16 northbound to the Cloud Management System, via ovn-northd:
17 Database Structure
19 The OVN Southbound database contains classes of data with different
20 properties, as described in the sections below.
21 Physical network
23 Physical network tables contain information about the chassis nodes in
25 the system. This contains all the information necessary to wire the
26 overlay, such as IP addresses, supported tunnel types, and security
27 keys.
28 The amount of physical network data is small (O(n) in the number of
30 chassis) and it changes infrequently, so it can be replicated to every
31 chassis.
32 The Chassis and Encap tables are the physical network tables.
34 Logical Network
36 Logical network tables contain the topology of logical switches and
38 routers, ACLs, firewall rules, and everything needed to describe how
39 packets traverse a logical network, represented as logical datapath
40 flows (see Logical Datapath Flows, below).
41 Logical network data may be large (O(n) in the number of logical ports,
43 ACL rules, etc.). Thus, to improve scaling, each chassis should receive
44 only data related to logical networks in which that chassis partici‐
45 pates.
46 The logical network data is ultimately controlled by the cloud manage‐
48 ment system (CMS) running northbound of OVN. That CMS determines the
49 entire OVN logical configuration and therefore the logical network data
50 at any given time is a deterministic function of the CMS’s configura‐
51 tion, although that happens indirectly via the OVN_Northbound database
52 and ovn-northd.
53 Logical network data is likely to change more quickly than physical
55 network data. This is especially true in a container environment where
56 containers are created and destroyed (and therefore added to and
57 deleted from logical switches) quickly.
58 The Logical_Flow, Multicast_Group, Address_Group, DHCP_Options,
60 DHCPv6_Options, and DNS tables contain logical network data.
61 Logical-physical bindings
63 These tables link logical and physical components. They show the cur‐
65 rent placement of logical components (such as VMs and VIFs) onto chas‐
66 sis, and map logical entities to the values that represent them in tun‐
67 nel encapsulations.
68 These tables change frequently, at least every time a VM powers up or
70 down or migrates, and especially quickly in a container environment.
71 The amount of data per VM (or VIF) is small.
72 Each chassis is authoritative about the VMs and VIFs that it hosts at
74 any given time and can efficiently flood that state to a central loca‐
75 tion, so the consistency needs are minimal.
76 The Port_Binding and Datapath_Binding tables contain binding data.
78 MAC bindings
80 The MAC_Binding table tracks the bindings from IP addresses to Ethernet
82 addresses that are dynamically discovered using ARP (for IPv4) and
83 neighbor discovery (for IPv6). Usually, IP-to-MAC bindings for virtual
84 machines are statically populated into the Port_Binding table, so
85 MAC_Binding is primarily used to discover bindings on physical net‐
86 works.
87 Common Columns
89 Some tables contain a special column named external_ids. This column
90 has the same form and purpose each place that it appears, so we
91 describe it here to save space later.
92 external_ids: map of string-string pairs
94 Key-value pairs for use by the software that manages the
95 OVN Southbound database rather than by ovn-con‐
96 troller/ovn-controller-vtep. In particular, ovn-northd
97 can use key-value pairs in this column to relate entities
98 in the southbound database to higher-level entities (such
99 as entities in the OVN Northbound database). Individual
100 key-value pairs in this column may be documented in some
101 cases to aid in understanding and troubleshooting, but
102 the reader should not mistake such documentation as com‐
103 prehensive.
104
106 The following list summarizes the purpose of each of the tables in the
107 OVN_Southbound database. Each table is described in more detail on a
108 later page.
109 Table Purpose
111 SB_Global Southbound configuration
112 Chassis Physical Network Hypervisor and Gateway Information
113 Encap Encapsulation Types
114 Address_Set
115 Address Sets
116 Port_Group
117 Port Groups
118 Logical_Flow
119 Logical Network Flows
120 Multicast_Group
121 Logical Port Multicast Groups
122 Meter Meter entry
123 Meter_Band
124 Band for meter entries
125 Datapath_Binding
126 Physical-Logical Datapath Bindings
127 Port_Binding
128 Physical-Logical Port Bindings
129 MAC_Binding
130 IP to MAC bindings
131 DHCP_Options
132 DHCP Options supported by native OVN DHCP
133 DHCPv6_Options
134 DHCPv6 Options supported by native OVN DHCPv6
135 Connection
136 OVSDB client connections.
137 SSL SSL configuration.
138 DNS Native DNS resolution
139 RBAC_Role RBAC_Role configuration.
140 RBAC_Permission
141 RBAC_Permission configuration.
142 Gateway_Chassis
143 Gateway_Chassis configuration.
144 HA_Chassis
145 HA_Chassis configuration.
146 HA_Chassis_Group
147 HA_Chassis_Group configuration.
148
150 Southbound configuration for an OVN system. This table must have
151 exactly one row.
152 Summary:
154 Status:
155 nb_cfg integer
156 Common Columns:
157 external_ids map of string-string pairs
158 options map of string-string pairs
159 Common options:
160 options map of string-string pairs
161 Options for configuring BFD:
162 options : bfd-min-rx optional string
163 options : bfd-decay-min-rx
164 optional string
165 options : bfd-min-tx optional string
166 options : bfd-mult optional string
167 Connection Options:
168 connections set of Connections
169 ssl optional SSL
170 Security Configurations:
171 ipsec boolean
172 Details:
174 Status:
175 This column allow a client to track the overall configuration state of
177 the system.
178 nb_cfg: integer
180 Sequence number for the configuration. When a CMS or ovn-nbctl
181 updates the northbound database, it increments the nb_cfg column
182 in the NB_Global table in the northbound database. In turn, when
183 ovn-northd updates the southbound database to bring it up to
184 date with these changes, it updates this column to the same
185 value.
186 Common Columns:
188 external_ids: map of string-string pairs
190 See External IDs at the beginning of this document.
191 options: map of string-string pairs
193 Common options:
195 options: map of string-string pairs
197 This column provides general key/value settings. The supported
198 options are described individually below.
199 Options for configuring BFD:
201 These options apply when ovn-controller configures BFD on tunnels
203 interfaces.
204 options : bfd-min-rx: optional string
206 BFD option min-rx value to use when configuring BFD on tunnel
207 interfaces.
208 options : bfd-decay-min-rx: optional string
210 BFD option decay-min-rx value to use when configuring BFD on
211 tunnel interfaces.
212 options : bfd-min-tx: optional string
214 BFD option min-tx value to use when configuring BFD on tunnel
215 interfaces.
216 options : bfd-mult: optional string
218 BFD option mult value to use when configuring BFD on tunnel
219 interfaces.
220 Connection Options:
222 connections: set of Connections
224 Database clients to which the Open vSwitch database server
225 should connect or on which it should listen, along with options
226 for how these connections should be configured. See the Connec‐
227 tion table for more information.
228 ssl: optional SSL
230 Global SSL configuration.
231 Security Configurations:
233 ipsec: boolean
235 Tunnel encryption configuration. If this column is set to be
236 true, all OVN tunnels will be encrypted with IPsec.
237
239 Each row in this table represents a hypervisor or gateway (a chassis)
240 in the physical network. Each chassis, via ovn-controller/ovn-con‐
241 troller-vtep, adds and updates its own row, and keeps a copy of the
242 remaining rows to determine how to reach other hypervisors.
243 When a chassis shuts down gracefully, it should remove its own row.
245 (This is not critical because resources hosted on the chassis are
246 equally unreachable regardless of whether the row is present.) If a
247 chassis shuts down permanently without removing its row, some kind of
248 manual or automatic cleanup is eventually needed; we can devise a
249 process for that as necessary.
250 Summary:
252 name string (must be unique within table)
253 hostname string
254 nb_cfg integer
255 external_ids : ovn-bridge-mappings
256 optional string
257 external_ids : datapath-type optional string
258 external_ids : iface-types optional string
259 external_ids : ovn-cms-options
260 optional string
261 transport_zones set of strings
262 Common Columns:
263 external_ids map of string-string pairs
264 Encapsulation Configuration:
265 encaps set of 1 or more Encaps
266 Gateway Configuration:
267 vtep_logical_switches set of strings
268 Details:
270 name: string (must be unique within table)
271 OVN does not prescribe a particular format for chassis names.
272 ovn-controller populates this column using external_ids:system-
273 id in the Open_vSwitch database’s Open_vSwitch table. ovn-con‐
274 troller-vtep populates this column with name in the hard‐
275 ware_vtep database’s Physical_Switch table.
276 hostname: string
278 The hostname of the chassis, if applicable. ovn-controller will
279 populate this column with the hostname of the host it is running
280 on. ovn-controller-vtep will leave this column empty.
281 nb_cfg: integer
283 Sequence number for the configuration. When ovn-controller
284 updates the configuration of a chassis from the contents of the
285 southbound database, it copies nb_cfg from the SB_Global table
286 into this column.
287 external_ids : ovn-bridge-mappings: optional string
289 ovn-controller populates this key with the set of bridge map‐
290 pings it has been configured to use. Other applications should
291 treat this key as read-only. See ovn-controller(8) for more
292 information.
293 external_ids : datapath-type: optional string
295 ovn-controller populates this key with the datapath type config‐
296 ured in the datapath_type column of the Open_vSwitch database’s
297 Bridge table. Other applications should treat this key as read-
298 only. See ovn-controller(8) for more information.
299 external_ids : iface-types: optional string
301 ovn-controller populates this key with the interface types con‐
302 figured in the iface_types column of the Open_vSwitch database’s
303 Open_vSwitch table. Other applications should treat this key as
304 read-only. See ovn-controller(8) for more information.
305 external_ids : ovn-cms-options: optional string
307 ovn-controller populates this key with the set of options con‐
308 figured in the external_ids:ovn-cms-options column of the
309 Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
310 troller(8) for more information.
311 transport_zones: set of strings
313 ovn-controller populates this key with the transport zones con‐
314 figured in the external_ids:ovn-transport-zones column of the
315 Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
316 troller(8) for more information.
317 Common Columns:
319 The overall purpose of these columns is described under Common Columns
321 at the beginning of this document.
322 external_ids: map of string-string pairs
324 Encapsulation Configuration:
326 OVN uses encapsulation to transmit logical dataplane packets between
328 chassis.
329 encaps: set of 1 or more Encaps
331 Points to supported encapsulation configurations to transmit
332 logical dataplane packets to this chassis. Each entry is a Encap
333 record that describes the configuration.
334 Gateway Configuration:
336 A gateway is a chassis that forwards traffic between the OVN-managed
338 part of a logical network and a physical VLAN, extending a tunnel-based
339 logical network into a physical network. Gateways are typically dedi‐
340 cated nodes that do not host VMs and will be controlled by ovn-con‐
341 troller-vtep.
342 vtep_logical_switches: set of strings
344 Stores all VTEP logical switch names connected by this gateway
345 chassis. The Port_Binding table entry with options:vtep-physi‐
346 cal-switch equal Chassis name, and options:vtep-logical-switch
347 value in Chassis vtep_logical_switches, will be associated with
348 this Chassis.
349
351 The encaps column in the Chassis table refers to rows in this table to
352 identify how OVN may transmit logical dataplane packets to this chas‐
353 sis. Each chassis, via ovn-controller(8) or ovn-controller-vtep(8),
354 adds and updates its own rows and keeps a copy of the remaining rows to
355 determine how to reach other chassis.
356 Summary:
358 type string, one of geneve, stt, or vxlan
359 options map of string-string pairs
360 ip string
361 chassis_name string
362 Details:
364 type: string, one of geneve, stt, or vxlan
365 The encapsulation to use to transmit packets to this chassis.
366 Hypervisors must use either geneve or stt. Gateways may use
367 vxlan, geneve, or stt.
368 options: map of string-string pairs
370 Options for configuring the encapsulation. Currently, the only
371 option that has been defined is csum.
372 csum indicates that encapsulation checksums can be transmitted
374 and received with reasonable performance. It is a hint to
375 senders transmitting data to this chassis that they should use
376 checksums to protect OVN metadata. ovn-controller populates this
377 key with the value defined in external_ids:ovn-encap-csum column
378 of the Open_vSwitch database’s Open_vSwitch table. Other appli‐
379 cations should treat this key as read-only. See ovn-con‐
380 troller(8) for more information.
381 In terms of performance, this actually significantly increases
383 throughput in most common cases when running on Linux based
384 hosts without NICs supporting encapsulation hardware offload
385 (around 60% for bulk traffic). The reason is that generally all
386 NICs are capable of offloading transmitted and received TCP/UDP
387 checksums (viewed as ordinary data packets and not as tunnels).
388 The benefit comes on the receive side where the validated outer
389 checksum can be used to additionally validate an inner checksum
390 (such as TCP), which in turn allows aggregation of packets to be
391 more efficiently handled by the rest of the stack.
392 Not all devices see such a benefit. The most notable exception
394 is hardware VTEPs. These devices are designed to not buffer
395 entire packets in their switching engines and are therefore
396 unable to efficiently compute or validate full packet checksums.
397 In addition certain versions of the Linux kernel are not able to
398 fully take advantage of encapsulation NIC offloads in the pres‐
399 ence of checksums. (This is actually a pretty narrow corner case
400 though - earlier versions of Linux don’t support encapsulation
401 offloads at all and later versions support both offloads and
402 checksums well.)
403 csum defaults to false for hardware VTEPs and true for all other
405 cases.
406 ip: string
408 The IPv4 address of the encapsulation tunnel endpoint.
409 chassis_name: string
411 The name of the chassis that created this encap.
412
414 This table contains address sets synced from the Address_Set table in
415 the OVN_Northbound database and address sets generated from the
416 Port_Group table in the OVN_Northbound database.
417 See the documentation for the Address_Set table and Port_Group table in
419 the OVN_Northbound database for details.
420 Summary:
422 name string (must be unique within table)
423 addresses set of strings
424 Details:
426 name: string (must be unique within table)
427 addresses: set of strings
429
431 This table contains names for the logical switch ports in the
432 OVN_Northbound database that belongs to the same group that is defined
433 in Port_Group in the OVN_Northbound database.
434 Summary:
436 name string (must be unique within table)
437 ports set of strings
438 Details:
440 name: string (must be unique within table)
441 ports: set of strings
443
445 Each row in this table represents one logical flow. ovn-northd popu‐
446 lates this table with logical flows that implement the L2 and L3
447 topologies specified in the OVN_Northbound database. Each hypervisor,
448 via ovn-controller, translates the logical flows into OpenFlow flows
449 specific to its hypervisor and installs them into Open vSwitch.
450 Logical flows are expressed in an OVN-specific format, described here.
452 A logical datapath flow is much like an OpenFlow flow, except that the
453 flows are written in terms of logical ports and logical datapaths
454 instead of physical ports and physical datapaths. Translation between
455 logical and physical flows helps to ensure isolation between logical
456 datapaths. (The logical flow abstraction also allows the OVN central‐
457 ized components to do less work, since they do not have to separately
458 compute and push out physical flows to each chassis.)
459 The default action when no flow matches is to drop packets.
461 Architectural Logical Life Cycle of a Packet
463 This following description focuses on the life cycle of a packet
465 through a logical datapath, ignoring physical details of the implemen‐
466 tation. Please refer to Architectural Physical Life Cycle of a Packet
467 in ovn-architecture(7) for the physical information.
468 The description here is written as if OVN itself executes these steps,
470 but in fact OVN (that is, ovn-controller) programs Open vSwitch, via
471 OpenFlow and OVSDB, to execute them on its behalf.
472 At a high level, OVN passes each packet through the logical datapath’s
474 logical ingress pipeline, which may output the packet to one or more
475 logical port or logical multicast groups. For each such logical output
476 port, OVN passes the packet through the datapath’s logical egress pipe‐
477 line, which may either drop the packet or deliver it to the destina‐
478 tion. Between the two pipelines, outputs to logical multicast groups
479 are expanded into logical ports, so that the egress pipeline only pro‐
480 cesses a single logical output port at a time. Between the two pipe‐
481 lines is also where, when necessary, OVN encapsulates a packet in a
482 tunnel (or tunnels) to transmit to remote hypervisors.
483 In more detail, to start, OVN searches the Logical_Flow table for a row
485 with correct logical_datapath, a pipeline of ingress, a table_id of 0,
486 and a match that is true for the packet. If none is found, OVN drops
487 the packet. If OVN finds more than one, it chooses the match with the
488 highest priority. Then OVN executes each of the actions specified in
489 the row’s actions column, in the order specified. Some actions, such as
490 those to modify packet headers, require no further details. The next
491 and output actions are special.
492 The next action causes the above process to be repeated recursively,
494 except that OVN searches for table_id of 1 instead of 0. Similarly, any
495 next action in a row found in that table would cause a further search
496 for a table_id of 2, and so on. When recursive processing completes,
497 flow control returns to the action following next.
498 The output action also introduces recursion. Its effect depends on the
500 current value of the outport field. Suppose outport designates a logi‐
501 cal port. First, OVN compares inport to outport; if they are equal, it
502 treats the output as a no-op by default. In the common case, where they
503 are different, the packet enters the egress pipeline. This transition
504 to the egress pipeline discards register data, e.g. reg0 ... reg9 and
505 connection tracking state, to achieve uniform behavior regardless of
506 whether the egress pipeline is on a different hypervisor (because reg‐
507 isters aren’t preserve across tunnel encapsulation).
508 To execute the egress pipeline, OVN again searches the Logical_Flow ta‐
510 ble for a row with correct logical_datapath, a table_id of 0, a match
511 that is true for the packet, but now looking for a pipeline of egress.
512 If no matching row is found, the output becomes a no-op. Otherwise, OVN
513 executes the actions for the matching flow (which is chosen from multi‐
514 ple, if necessary, as already described).
515 In the egress pipeline, the next action acts as already described,
517 except that it, of course, searches for egress flows. The output
518 action, however, now directly outputs the packet to the output port
519 (which is now fixed, because outport is read-only within the egress
520 pipeline).
521 The description earlier assumed that outport referred to a logical
523 port. If it instead designates a logical multicast group, then the
524 description above still applies, with the addition of fan-out from the
525 logical multicast group to each logical port in the group. For each
526 member of the group, OVN executes the logical pipeline as described,
527 with the logical output port replaced by the group member.
528 Pipeline Stages
530 ovn-northd populates the Logical_Flow table with the logical flows
532 described in detail in ovn-northd(8).
533 Summary:
535 logical_datapath Datapath_Binding
536 pipeline string, either egress or ingress
537 table_id integer, in range 0 to 23
538 priority integer, in range 0 to 65,535
539 match string
540 actions string
541 external_ids : stage-name optional string
542 external_ids : stage-hint optional string, containing an uuid
543 external_ids : source optional string
544 Common Columns:
545 external_ids map of string-string pairs
546 Details:
548 logical_datapath: Datapath_Binding
549 The logical datapath to which the logical flow belongs.
550 pipeline: string, either egress or ingress
552 The primary flows used for deciding on a packet’s destination
553 are the ingress flows. The egress flows implement ACLs. See Log‐
554 ical Life Cycle of a Packet, above, for details.
555 table_id: integer, in range 0 to 23
557 The stage in the logical pipeline, analogous to an OpenFlow ta‐
558 ble number.
559 priority: integer, in range 0 to 65,535
561 The flow’s priority. Flows with numerically higher priority take
562 precedence over those with lower. If two logical datapath flows
563 with the same priority both match, then the one actually applied
564 to the packet is undefined.
565 match: string
567 A matching expression. OVN provides a superset of OpenFlow
568 matching capabilities, using a syntax similar to Boolean expres‐
569 sions in a programming language.
570 The most important components of match expression are compar‐
572 isons between symbols and constants, e.g. ip4.dst ==
573 192.168.0.1, ip.proto == 6, arp.op == 1, eth.type == 0x800. The
574 logical AND operator && and logical OR operator || can combine
575 comparisons into a larger expression.
576 Matching expressions also support parentheses for grouping, the
578 logical NOT prefix operator !, and literals 0 and 1 to express
579 ``false’’ or ``true,’’ respectively. The latter is useful by
580 itself as a catch-all expression that matches every packet.
581 Match expressions also support a kind of function syntax. The
583 following functions are supported:
584 is_chassis_resident(lport)
586 Evaluates to true on a chassis on which logical port
587 lport (a quoted string) resides, and to false elsewhere.
588 This function was introduced in OVN 2.7.
589 Symbols
591 Type. Symbols have integer or string type. Integer symbols have
593 a width in bits.
594 Kinds. There are three kinds of symbols:
596 · Fields. A field symbol represents a packet header or
598 metadata field. For example, a field named vlan.tci might
599 represent the VLAN TCI field in a packet.
600 A field symbol can have integer or string type. Integer
602 fields can be nominal or ordinal (see Level of Measure‐
603 ment, below).
604 · Subfields. A subfield represents a subset of bits from a
606 larger field. For example, a field vlan.vid might be
607 defined as an alias for vlan.tci[0..11]. Subfields are
608 provided for syntactic convenience, because it is always
609 possible to instead refer to a subset of bits from a
610 field directly.
611 Only ordinal fields (see Level of Measurement, below) may
613 have subfields. Subfields are always ordinal.
614 · Predicates. A predicate is shorthand for a Boolean
616 expression. Predicates may be used much like 1-bit
617 fields. For example, ip4 might expand to eth.type ==
618 0x800. Predicates are provided for syntactic convenience,
619 because it is always possible to instead specify the
620 underlying expression directly.
621 A predicate whose expansion refers to any nominal field
623 or predicate (see Level of Measurement, below) is nomi‐
624 nal; other predicates have Boolean level of measurement.
625 Level of Measurement. See
627 http://en.wikipedia.org/wiki/Level_of_measurement for the sta‐
628 tistical concept on which this classification is based. There
629 are three levels:
630 · Ordinal. In statistics, ordinal values can be ordered on
632 a scale. OVN considers a field (or subfield) to be ordi‐
633 nal if its bits can be examined individually. This is
634 true for the OpenFlow fields that OpenFlow or Open
635 vSwitch makes ``maskable.’’
636 Any use of a ordinal field may specify a single bit or a
638 range of bits, e.g. vlan.tci[13..15] refers to the PCP
639 field within the VLAN TCI, and eth.dst[40] refers to the
640 multicast bit in the Ethernet destination address.
641 OVN supports all the usual arithmetic relations (==, !=,
643 <, <=, >, and >=) on ordinal fields and their subfields,
644 because OVN can implement these in OpenFlow and Open
645 vSwitch as collections of bitwise tests.
646 · Nominal. In statistics, nominal values cannot be usefully
648 compared except for equality. This is true of OpenFlow
649 port numbers, Ethernet types, and IP protocols are exam‐
650 ples: all of these are just identifiers assigned arbi‐
651 trarily with no deeper meaning. In OpenFlow and Open
652 vSwitch, bits in these fields generally aren’t individu‐
653 ally addressable.
654 OVN only supports arithmetic tests for equality on nomi‐
656 nal fields, because OpenFlow and Open vSwitch provide no
657 way for a flow to efficiently implement other comparisons
658 on them. (A test for inequality can be sort of built out
659 of two flows with different priorities, but OVN matching
660 expressions always generate flows with a single prior‐
661 ity.)
662 String fields are always nominal.
664 · Boolean. A nominal field that has only two values, 0 and
666 1, is somewhat exceptional, since it is easy to support
667 both equality and inequality tests on such a field:
668 either one can be implemented as a test for 0 or 1.
669 Only predicates (see above) have a Boolean level of mea‐
671 surement.
672 This isn’t a standard level of measurement.
674 Prerequisites. Any symbol can have prerequisites, which are
676 additional condition implied by the use of the symbol. For exam‐
677 ple, For example, icmp4.type symbol might have prerequisite
678 icmp4, which would cause an expression icmp4.type == 0 to be
679 interpreted as icmp4.type == 0 && icmp4, which would in turn
680 expand to icmp4.type == 0 && eth.type == 0x800 && ip4.proto == 1
681 (assuming icmp4 is a predicate defined as suggested under Types
682 above).
683 Relational operators
685 All of the standard relational operators ==, !=, <, <=, >, and
687 >= are supported. Nominal fields support only == and !=, and
688 only in a positive sense when outer ! are taken into account,
689 e.g. given string field inport, inport == "eth0" and !(inport !=
690 "eth0") are acceptable, but not inport != "eth0".
691 The implementation of == (or != when it is negated), is more
693 efficient than that of the other relational operators.
694 Constants
696 Integer constants may be expressed in decimal, hexadecimal pre‐
698 fixed by 0x, or as dotted-quad IPv4 addresses, IPv6 addresses in
699 their standard forms, or Ethernet addresses as colon-separated
700 hex digits. A constant in any of these forms may be followed by
701 a slash and a second constant (the mask) in the same form, to
702 form a masked constant. IPv4 and IPv6 masks may be given as
703 integers, to express CIDR prefixes.
704 String constants have the same syntax as quoted strings in JSON
706 (thus, they are Unicode strings).
707 Some operators support sets of constants written inside curly
709 braces { ... }. Commas between elements of a set, and after the
710 last elements, are optional. With ==, ``field == { constant1,
711 constant2, ... }’’ is syntactic sugar for ``field == constant1
712 || field == constant2 || .... Similarly, ``field != { constant1,
713 constant2, ... }’’ is equivalent to ``field != constant1 &&
714 field != constant2 && ...’’.
715 You may refer to a set of IPv4, IPv6, or MAC addresses stored in
717 the Address_Set table by its name. An Address_Set with a name of
718 set1 can be referred to as $set1.
719 You may refer to a group of logical switch ports stored in the
721 Port_Group table by its name. An Port_Group with a name of
722 port_group1 can be referred to as @port_group1.
723 Additionally, you may refer to the set of addresses belonging to
725 a group of logical switch ports stored in the Port_Group table
726 by its name followed by a suffix ’_ip4’/’_ip6’. The IPv4 address
727 set of a Port_Group with a name of port_group1 can be referred
728 to as $port_group1_ip4, and the IPv6 address set of the same
729 Port_Group can be referred to as $port_group1_ip6
730 Miscellaneous
732 Comparisons may name the symbol or the constant first, e.g.
734 tcp.src == 80 and 80 == tcp.src are both acceptable.
735 Tests for a range may be expressed using a syntax like 1024 <=
737 tcp.src <= 49151, which is equivalent to 1024 <= tcp.src &&
738 tcp.src <= 49151.
739 For a one-bit field or predicate, a mention of its name is
741 equivalent to symobl == 1, e.g. vlan.present is equivalent to
742 vlan.present == 1. The same is true for one-bit subfields, e.g.
743 vlan.tci[12]. There is no technical limitation to implementing
744 the same for ordinal fields of all widths, but the implementa‐
745 tion is expensive enough that the syntax parser requires writing
746 an explicit comparison against zero to make mistakes less
747 likely, e.g. in tcp.src != 0 the comparison against 0 is
748 required.
749 Operator precedence is as shown below, from highest to lowest.
751 There are two exceptions where parentheses are required even
752 though the table would suggest that they are not: && and ||
753 require parentheses when used together, and ! requires parenthe‐
754 ses when applied to a relational expression. Thus, in (eth.type
755 == 0x800 || eth.type == 0x86dd) && ip.proto == 6 or !(arp.op ==
756 1), the parentheses are mandatory.
757 · ()
759 · == != < <= > >=
761 · !
763 · && ||
765 Comments may be introduced by //, which extends to the next new-
767 line. Comments within a line may be bracketed by /* and */. Mul‐
768 tiline comments are not supported.
769 Symbols
771 Most of the symbols below have integer type. Only inport and
773 outport have string type. inport names a logical port. Thus, its
774 value is a logical_port name from the Port_Binding table. out‐
775 port may name a logical port, as inport, or a logical multicast
776 group defined in the Multicast_Group table. For both symbols,
777 only names within the flow’s logical datapath may be used.
778 The regX symbols are 32-bit integers. The xxregX symbols are
780 128-bit integers, which overlay four of the 32-bit registers:
781 xxreg0 overlays reg0 through reg3, with reg0 supplying the most-
782 significant bits of xxreg0 and reg3 the least-signficant. xxreg1
783 similarly overlays reg4 through reg7.
784 · reg0...reg9
786 · xxreg0 xxreg1
788 · inport outport
790 · flags.loopback
792 · eth.src eth.dst eth.type
794 · vlan.tci vlan.vid vlan.pcp vlan.present
796 · ip.proto ip.dscp ip.ecn ip.ttl ip.frag
798 · ip4.src ip4.dst
800 · ip6.src ip6.dst ip6.label
802 · arp.op arp.spa arp.tpa arp.sha arp.tha
804 · tcp.src tcp.dst tcp.flags
806 · udp.src udp.dst
808 · sctp.src sctp.dst
810 · icmp4.type icmp4.code
812 · icmp6.type icmp6.code
814 · nd.target nd.sll nd.tll
816 · ct_mark ct_label
818 · ct_state, which has several Boolean subfields. The
820 ct_next action initializes the following subfields:
821 · ct.trk: Always set to true by ct_next to indicate
823 that connection tracking has taken place. All
824 other ct subfields have ct.trk as a prerequisite.
825 · ct.new: True for a new flow
827 · ct.est: True for an established flow
829 · ct.rel: True for a related flow
831 · ct.rpl: True for a reply flow
833 · ct.inv: True for a connection entry in a bad state
835 The ct_dnat, ct_snat, and ct_lb actions initialize the
837 following subfields:
838 · ct.dnat: True for a packet whose destination IP
840 address has been changed.
841 · ct.snat: True for a packet whose source IP address
843 has been changed.
844 The following predicates are supported:
846 · eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff
848 · eth.mcast expands to eth.dst[40]
850 · vlan.present expands to vlan.tci[12]
852 · ip4 expands to eth.type == 0x800
854 · ip4.mcast expands to ip4.dst[28..31] == 0xe
856 · ip6 expands to eth.type == 0x86dd
858 · ip expands to ip4 || ip6
860 · icmp4 expands to ip4 && ip.proto == 1
862 · icmp6 expands to ip6 && ip.proto == 58
864 · icmp expands to icmp4 || icmp6
866 · ip.is_frag expands to ip.frag[0]
868 · ip.later_frag expands to ip.frag[1]
870 · ip.first_frag expands to ip.is_frag && !ip.later_frag
872 · arp expands to eth.type == 0x806
874 · nd expands to icmp6.type == {135, 136} && icmp6.code == 0
876 && ip.ttl == 255
877 · nd_ns expands to icmp6.type == 135 && icmp6.code == 0 &&
879 ip.ttl == 255
880 · nd_na expands to icmp6.type == 136 && icmp6.code == 0 &&
882 ip.ttl == 255
883 · nd_rs expands to icmp6.type == 133 && icmp6.code == 0 &&
885 ip.ttl == 255
886 · nd_ra expands to icmp6.type == 134 && icmp6.code == 0 &&
888 ip.ttl == 255
889 · tcp expands to ip.proto == 6
891 · udp expands to ip.proto == 17
893 · sctp expands to ip.proto == 132
895 actions: string
897 Logical datapath actions, to be executed when the logical flow
898 represented by this row is the highest-priority match.
899 Actions share lexical syntax with the match column. An empty set
901 of actions (or one that contains just white space or comments),
902 or a set of actions that consists of just drop;, causes the
903 matched packets to be dropped. Otherwise, the column should con‐
904 tain a sequence of actions, each terminated by a semicolon.
905 The following actions are defined:
907 output;
909 In the ingress pipeline, this action executes the egress
910 pipeline as a subroutine. If outport names a logical
911 port, the egress pipeline executes once; if it is a mul‐
912 ticast group, the egress pipeline runs once for each log‐
913 ical port in the group.
914 In the egress pipeline, this action performs the actual
916 output to the outport logical port. (In the egress pipe‐
917 line, outport never names a multicast group.)
918 By default, output to the input port is implicitly
920 dropped, that is, output becomes a no-op if outport ==
921 inport. Occasionally it may be useful to override this
922 behavior, e.g. to send an ARP reply to an ARP request; to
923 do so, use flags.loopback = 1 to allow the packet to
924 "hair-pin" back to the input port.
925 next;
927 next(table);
928 next(pipeline=pipeline, table=table);
929 Executes the given logical datapath table in pipeline as a
930 subroutine. The default table is just after the current
931 one. If pipeline is specified, it may be ingress or egress;
932 the default pipeline is the one currently executing.
933 Actions in the ingress pipeline may not use next to jump
934 into the egress pipeline (use the output instead), but
935 transitions in the opposite direction are allowed.
936 field = constant;
938 Sets data or metadata field field to constant value con‐
939 stant, e.g. outport = "vif0"; to set the logical output
940 port. To set only a subset of bits in a field, specify a
941 subfield for field or a masked constant, e.g. one may use
942 vlan.pcp[2] = 1; or vlan.pcp = 4/4; to set the most sigifi‐
943 cant bit of the VLAN PCP.
944 Assigning to a field with prerequisites implicitly adds
946 those prerequisites to match; thus, for example, a flow
947 that sets tcp.dst applies only to TCP flows, regardless of
948 whether its match mentions any TCP field.
949 Not all fields are modifiable (e.g. eth.type and ip.proto
951 are read-only), and not all modifiable fields may be par‐
952 tially modified (e.g. ip.ttl must assigned as a whole). The
953 outport field is modifiable in the ingress pipeline but not
954 in the egress pipeline.
955 ovn_field = constant;
957 Sets OVN field ovn_field to constant value constant.
958 OVN supports setting the values of certain fields which are
960 not yet supported in OpenFlow to set or modify them.
961 Below are the supported OVN fields:
963 · icmp4.frag_mtu
965 This field sets the low-order 16 bits of the ICMP4
967 header field that is labelled "unused" in the ICMP
968 specification as defined in the RFC 1191 with the
969 value specified in constant.
970 Eg. icmp4.frag_mtu = 1500;
972 field1 = field2;
974 Sets data or metadata field field1 to the value of data or
975 metadata field field2, e.g. reg0 = ip4.src; copies ip4.src
976 into reg0. To modify only a subset of a field’s bits, spec‐
977 ify a subfield for field1 or field2 or both, e.g. vlan.pcp
978 = reg0[0..2]; copies the least-significant bits of reg0
979 into the VLAN PCP.
980 field1 and field2 must be the same type, either both string
982 or both integer fields. If they are both integer fields,
983 they must have the same width.
984 If field1 or field2 has prerequisites, they are added
986 implicitly to match. It is possible to write an assignment
987 with contradictory prerequisites, such as ip4.src =
988 ip6.src[0..31];, but the contradiction means that a logical
989 flow with such an assignment will never be matched.
990 field1 <-> field2;
992 Similar to field1 = field2; except that the two values are
993 exchanged instead of copied. Both field1 and field2 must
994 modifiable.
995 ip.ttl--;
997 Decrements the IPv4 or IPv6 TTL. If this would make the TTL
998 zero or negative, then processing of the packet halts; no
999 further actions are processed. (To properly handle such
1000 cases, a higher-priority flow should match on ip.ttl == {0,
1001 1};.)
1002 Prerequisite: ip
1004 ct_next;
1006 Apply connection tracking to the flow, initializing
1007 ct_state for matching in later tables. Automatically moves
1008 on to the next table, as if followed by next.
1009 As a side effect, IP fragments will be reassembled for
1011 matching. If a fragmented packet is output, then it will be
1012 sent with any overlapping fragments squashed. The connec‐
1013 tion tracking state is scoped by the logical port when the
1014 action is used in a flow for a logical switch, so overlap‐
1015 ping addresses may be used. To allow traffic related to the
1016 matched flow, execute ct_commit . Connection tracking state
1017 is scoped by the logical topology when the action is used
1018 in a flow for a router.
1019 It is possible to have actions follow ct_next, but they
1021 will not have access to any of its side-effects and is not
1022 generally useful.
1023 ct_commit;
1025 ct_commit(ct_mark=value[/mask]);
1026 ct_commit(ct_label=value[/mask]);
1027 ct_commit(ct_mark=value[/mask], ct_label=value[/mask]);
1028 Commit the flow to the connection tracking entry associated
1029 with it by a previous call to ct_next. When
1030 ct_mark=value[/mask] and/or ct_label=value[/mask] are sup‐
1031 plied, ct_mark and/or ct_label will be set to the values
1032 indicated by value[/mask] on the connection tracking entry.
1033 ct_mark is a 32-bit field. ct_label is a 128-bit field. The
1034 value[/mask] should be specified in hex string if more than
1035 64bits are to be used.
1036 Note that if you want processing to continue in the next
1038 table, you must execute the next action after ct_commit.
1039 You may also leave out next which will commit connection
1040 tracking state, and then drop the packet. This could be
1041 useful for setting ct_mark on a connection tracking entry
1042 before dropping a packet, for example.
1043 ct_dnat;
1045 ct_dnat(IP);
1046 ct_dnat sends the packet through the DNAT zone in connec‐
1047 tion tracking table to unDNAT any packet that was DNATed in
1048 the opposite direction. The packet is then automatically
1049 sent to to the next tables as if followed by next; action.
1050 The next tables will see the changes in the packet caused
1051 by the connection tracker.
1052 ct_dnat(IP) sends the packet through the DNAT zone to
1054 change the destination IP address of the packet to the one
1055 provided inside the parentheses and commits the connection.
1056 The packet is then automatically sent to the next tables as
1057 if followed by next; action. The next tables will see the
1058 changes in the packet caused by the connection tracker.
1059 ct_snat;
1061 ct_snat(IP);
1062 ct_snat sends the packet through the SNAT zone to unSNAT
1063 any packet that was SNATed in the opposite direction. The
1064 packet is automatically sent to the next tables as if fol‐
1065 lowed by the next; action. The next tables will see the
1066 changes in the packet caused by the connection tracker.
1067 ct_snat(IP) sends the packet through the SNAT zone to
1069 change the source IP address of the packet to the one pro‐
1070 vided inside the parenthesis and commits the connection.
1071 The packet is then automatically sent to the next tables as
1072 if followed by next; action. The next tables will see the
1073 changes in the packet caused by the connection tracker.
1074 ct_clear;
1076 Clears connection tracking state.
1077 clone { action; ... };
1079 Makes a copy of the packet being processed and executes
1080 each action on the copy. Actions following the clone
1081 action, if any, apply to the original, unmodified packet.
1082 This can be used as a way to ``save and restore’’ the
1083 packet around a set of actions that may modify it and
1084 should not persist.
1085 arp { action; ... };
1087 Temporarily replaces the IPv4 packet being processed by an
1088 ARP packet and executes each nested action on the ARP
1089 packet. Actions following the arp action, if any, apply to
1090 the original, unmodified packet.
1091 The ARP packet that this action operates on is initialized
1093 based on the IPv4 packet being processed, as follows. These
1094 are default values that the nested actions will probably
1095 want to change:
1096 · eth.src unchanged
1098 · eth.dst unchanged
1100 · eth.type = 0x0806
1102 · arp.op = 1 (ARP request)
1104 · arp.sha copied from eth.src
1106 · arp.spa copied from ip4.src
1108 · arp.tha = 00:00:00:00:00:00
1110 · arp.tpa copied from ip4.dst
1112 The ARP packet has the same VLAN header, if any, as the IP
1114 packet it replaces.
1115 Prerequisite: ip4
1117 get_arp(P, A);
1119 Parameters: logical port string field P, 32-bit IP address
1120 field A.
1121 Looks up A in P’s mac binding table. If an entry is found,
1123 stores its Ethernet address in eth.dst, otherwise stores
1124 00:00:00:00:00:00 in eth.dst.
1125 Example: get_arp(outport, ip4.dst);
1127 put_arp(P, A, E);
1129 Parameters: logical port string field P, 32-bit IP address
1130 field A, 48-bit Ethernet address field E.
1131 Adds or updates the entry for IP address A in logical port
1133 P’s mac binding table, setting its Ethernet address to E.
1134 Example: put_arp(inport, arp.spa, arp.sha);
1136 nd_ns { action; ... };
1138 Temporarily replaces the IPv6 packet being processed by an
1139 IPv6 Neighbor Solicitation packet and executes each nested
1140 action on the IPv6 NS packet. Actions following the nd_ns
1141 action, if any, apply to the original, unmodified packet.
1142 The IPv6 NS packet that this action operates on is initial‐
1144 ized based on the IPv6 packet being processed, as follows.
1145 These are default values that the nested actions will prob‐
1146 ably want to change:
1147 · eth.src unchanged
1149 · eth.dst set to IPv6 multicast MAC address
1151 · eth.type = 0x86dd
1153 · ip6.src copied from ip6.src
1155 · ip6.dst set to IPv6 Solicited-Node multicast address
1157 · icmp6.type = 135 (Neighbor Solicitation)
1159 · nd.target copied from ip6.dst
1161 The IPv6 NS packet has the same VLAN header, if any, as the
1163 IP packet it replaces.
1164 Prerequisite: ip6
1166 nd_na { action; ... };
1168 Temporarily replaces the IPv6 neighbor solicitation packet
1169 being processed by an IPv6 neighbor advertisement (NA)
1170 packet and executes each nested action on the NA packet.
1171 Actions following the nd_na action, if any, apply to the
1172 original, unmodified packet.
1173 The NA packet that this action operates on is initialized
1175 based on the IPv6 packet being processed, as follows. These
1176 are default values that the nested actions will probably
1177 want to change:
1178 · eth.dst exchanged with eth.src
1180 · eth.type = 0x86dd
1182 · ip6.dst copied from ip6.src
1184 · ip6.src copied from nd.target
1186 · icmp6.type = 136 (Neighbor Advertisement)
1188 · nd.target unchanged
1190 · nd.sll = 00:00:00:00:00:00
1192 · nd.tll copied from eth.dst
1194 The ND packet has the same VLAN header, if any, as the IPv6
1196 packet it replaces.
1197 Prerequisite: nd_ns
1199 nd_na_router { action; ... };
1201 Temporarily replaces the IPv6 neighbor solicitation packet
1202 being processed by an IPv6 neighbor advertisement (NA)
1203 packet, sets ND_NSO_ROUTER in the RSO flags and executes
1204 each nested action on the NA packet. Actions following the
1205 nd_na_router action, if any, apply to the original, unmodi‐
1206 fied packet.
1207 The NA packet that this action operates on is initialized
1209 based on the IPv6 packet being processed, as follows. These
1210 are default values that the nested actions will probably
1211 want to change:
1212 · eth.dst exchanged with eth.src
1214 · eth.type = 0x86dd
1216 · ip6.dst copied from ip6.src
1218 · ip6.src copied from nd.target
1220 · icmp6.type = 136 (Neighbor Advertisement)
1222 · nd.target unchanged
1224 · nd.sll = 00:00:00:00:00:00
1226 · nd.tll copied from eth.dst
1228 The ND packet has the same VLAN header, if any, as the IPv6
1230 packet it replaces.
1231 Prerequisite: nd_ns
1233 get_nd(P, A);
1235 Parameters: logical port string field P, 128-bit IPv6
1236 address field A.
1237 Looks up A in P’s mac binding table. If an entry is found,
1239 stores its Ethernet address in eth.dst, otherwise stores
1240 00:00:00:00:00:00 in eth.dst.
1241 Example: get_nd(outport, ip6.dst);
1243 put_nd(P, A, E);
1245 Parameters: logical port string field P, 128-bit IPv6
1246 address field A, 48-bit Ethernet address field E.
1247 Adds or updates the entry for IPv6 address A in logical
1249 port P’s mac binding table, setting its Ethernet address to
1250 E.
1251 Example: put_nd(inport, nd.target, nd.tll);
1253 R = put_dhcp_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1255 Parameters: one or more DHCP option/value pairs, which must
1256 include an offerip option (with code 0).
1257 Result: stored to a 1-bit subfield R.
1259 Valid only in the ingress pipeline.
1261 When this action is applied to a DHCP request packet
1263 (DHCPDISCOVER or DHCPREQUEST), it changes the packet into a
1264 DHCP reply (DHCPOFFER or DHCPACK, respectively), replaces
1265 the options by those specified as parameters, and stores 1
1266 in R.
1267 When this action is applied to a non-DHCP packet or a DHCP
1269 packet that is not DHCPDISCOVER or DHCPREQUEST, it leaves
1270 the packet unchanged and stores 0 in R.
1271 The contents of the DHCP_Option table control the DHCP
1273 option names and values that this action supports.
1274 Example: reg0[0] = put_dhcp_opts(offerip = 10.0.0.2, router
1276 = 10.0.0.1, netmask = 255.255.255.0, dns_server = {8.8.8.8,
1277 7.7.7.7});
1278 R = put_dhcpv6_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1280 Parameters: one or more DHCPv6 option/value pairs.
1281 Result: stored to a 1-bit subfield R.
1283 Valid only in the ingress pipeline.
1285 When this action is applied to a DHCPv6 request packet, it
1287 changes the packet into a DHCPv6 reply, replaces the
1288 options by those specified as parameters, and stores 1 in
1289 R.
1290 When this action is applied to a non-DHCPv6 packet or an
1292 invalid DHCPv6 request packet , it leaves the packet
1293 unchanged and stores 0 in R.
1294 The contents of the DHCPv6_Options table control the DHCPv6
1296 option names and values that this action supports.
1297 Example: reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4,
1299 server_id = 00:00:00:00:10:02,
1300 dns_server={ae70::1,ae70::2});
1301 set_queue(queue_number);
1303 Parameters: Queue number queue_number, in the range 0 to
1304 61440.
1305 This is a logical equivalent of the OpenFlow set_queue
1307 action. It affects packets that egress a hypervisor through
1308 a physical interface. For nonzero queue_number, it config‐
1309 ures packet queuing to match the settings configured for
1310 the Port_Binding with options:qdisc_queue_id matching
1311 queue_number. When queue_number is zero, it resets queuing
1312 to the default strategy.
1313 Example: set_queue(10);
1315 ct_lb;
1317 ct_lb(ip[:port]...);
1318 With one or more arguments, ct_lb commits the packet to the
1319 connection tracking table and DNATs the packet’s destina‐
1320 tion IP address (and port) to the IP address or addresses
1321 (and optional ports) specified in the string. If multiple
1322 comma-separated IP addresses are specified, each is given
1323 equal weight for picking the DNAT address. Processing auto‐
1324 matically moves on to the next table, as if next; were
1325 specified, and later tables act on the packet as modified
1326 by the connection tracker. Connection tracking state is
1327 scoped by the logical port when the action is used in a
1328 flow for a logical switch, so overlapping addresses may be
1329 used. Connection tracking state is scoped by the logical
1330 topology when the action is used in a flow for a router.
1331 Without arguments, ct_lb sends the packet to the connection
1333 tracking table to NAT the packets. If the packet is part of
1334 an established connection that was previously committed to
1335 the connection tracker via ct_lb(...), it will automati‐
1336 cally get DNATed to the same IP address as the first packet
1337 in that connection.
1338 R = dns_lookup();
1340 Parameters: No parameters.
1341 Result: stored to a 1-bit subfield R.
1343 Valid only in the ingress pipeline.
1345 When this action is applied to a valid DNS request (a UDP
1347 packet typically directed to port 53), it attempts to
1348 resolve the query using the contents of the DNS table. If
1349 it is successful, it changes the packet into a DNS reply
1350 and stores 1 in R. If the action is applied to a non-DNS
1351 packet, an invalid DNS request packet, or a valid DNS
1352 request for which the DNS table does not supply an answer,
1353 it leaves the packet unchanged and stores 0 in R.
1354 Regardless of success, the action does not make any of the
1356 changes to the flow that are necessary to direct the packet
1357 back to the requester. The logical pipeline can implement
1358 this behavior with matches and actions in later tables.
1359 Example: reg0[3] = dns_lookup();
1361 Prerequisite: udp
1363 R = put_nd_ra_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1365 Parameters: The following IPv6 ND Router Advertisement
1366 option/value pairs as defined in RFC 4861.
1367 · addr_mode
1369 Mandatory parameter which specifies the address mode
1371 flag to be set in the RA flag options field. The
1372 value of this option is a string and the following
1373 values can be defined - "slaac", "dhcpv6_stateful"
1374 and "dhcpv6_stateless".
1375 · slla
1377 Mandatory parameter which specifies the link-layer
1379 address of the interface from which the Router
1380 Advertisement is sent.
1381 · mtu
1383 Optional parameter which specifies the MTU.
1385 · prefix
1387 Optional parameter which should be specified if the
1389 addr_mode is "slaac" or "dhcpv6_stateless". The
1390 value should be an IPv6 prefix which will be used
1391 for stateless IPv6 address configuration. This
1392 option can be defined multiple times.
1393 Result: stored to a 1-bit subfield R.
1395 Valid only in the ingress pipeline.
1397 When this action is applied to an IPv6 Router solicitation
1399 request packet, it changes the packet into an IPv6 Router
1400 Advertisement reply and adds the options specified in the
1401 parameters, and stores 1 in R.
1402 When this action is applied to a non-IPv6 Router solicita‐
1404 tion packet or an invalid IPv6 request packet , it leaves
1405 the packet unchanged and stores 0 in R.
1406 Example: reg0[3] = put_nd_ra_opts(addr_mode = "slaac", slla
1408 = 00:00:00:00:10:02, prefix = aef0::/64, mtu = 1450);
1409 set_meter(rate);
1411 set_meter(rate, burst);
1412 Parameters: rate limit int field rate in kbps, burst rate
1413 limits int field burst in kbps.
1414 This action sets the rate limit for a flow.
1416 Example: set_meter(100, 1000);
1418 R = check_pkt_larger(L)
1420 Parameters: packet length L to check for in bytes.
1421 Result: stored to a 1-bit subfield R.
1423 This is a logical equivalent of the OpenFlow
1425 check_pkt_larger action. If the packet is larger than the
1426 length specified in L, it stores 1 in the subfield R.
1427 Example: reg0[6] = check_pkt_larger(1000);
1429 log(key=value, ...);
1431 Causes ovn-controller to log the packet on the chassis
1432 that processes it. Packet logging currently uses the same
1433 logging mechanism as other Open vSwitch and OVN messages,
1434 which means that whether and where log messages appear
1435 depends on the local logging configuration that can be
1436 configured with ovs-appctl, etc.
1437 The log action takes zero or more of the following key-
1439 value pair arguments that control what is logged:
1440 name=string
1442 An optional name for the ACL. The string is cur‐
1443 rently limited to 64 bytes.
1444 severity=level
1446 Indicates the severity of the event. The level is
1447 one of following (from more to less serious):
1448 alert, warning, notice, info, or debug. If a
1449 severity is not provided, the default is info.
1450 verdict=value
1452 The verdict for packets matching the flow. The
1453 value must be one of allow, deny, or reject.
1454 meter=string
1456 An optional rate-limiting meter to be applied to
1457 the logs. The string should reference a name entry
1458 from the Meter table. The only meter action that
1459 is appriopriate is drop.
1460 icmp4 { action; ... };
1462 icmp4_error { action; ... };
1463 Temporarily replaces the IPv4 packet being processed by an
1464 ICMPv4 packet and executes each nested action on the ICMPv4
1465 packet. Actions following these actions, if any, apply to
1466 the original, unmodified packet.
1467 The ICMPv4 packet that these actions operates on is ini‐
1469 tialized based on the IPv4 packet being processed, as fol‐
1470 lows. These are default values that the nested actions will
1471 probably want to change. Ethernet and IPv4 fields not
1472 listed here are not changed:
1473 · ip.proto = 1 (ICMPv4)
1475 · ip.frag = 0 (not a fragment)
1477 · ip.ttl = 255
1479 · icmp4.type = 3 (destination unreachable)
1481 · icmp4.code = 1 (host unreachable)
1483 icmp4_error action is expected to be used to generate an
1485 ICMPv4 packet in response to an error in original IP
1486 packet. When this action generates the ICMPv4 packet, it
1487 also copies the original IP datagram following the ICMPv4
1488 header as per RFC 1122: 3.2.2.
1489 Prerequisite: ip4
1491 icmp6 { action; ... };
1493 Temporarily replaces the IPv6 packet being processed by an
1494 ICMPv6 packet and executes each nested action on the ICMPv6
1495 packet. Actions following the icmp6 action, if any, apply
1496 to the original, unmodified packet.
1497 The ICMPv6 packet that this action operates on is initial‐
1499 ized based on the IPv6 packet being processed, as follows.
1500 These are default values that the nested actions will prob‐
1501 ably want to change. Ethernet and IPv6 fields not listed
1502 here are not changed:
1503 · ip.proto = 58 (ICMPv6)
1505 · ip.ttl = 255
1507 · icmp6.type = 1 (destination unreachable)
1509 · icmp6.code = 1 (administratively prohibited)
1511 Prerequisite: ip6
1513 tcp_reset;
1515 This action transforms the current TCP packet according to
1516 the following pseudocode:
1517 if (tcp.ack) {
1519 tcp.seq = tcp.ack;
1520 } else {
1521 tcp.ack = tcp.seq + length(tcp.payload);
1522 tcp.seq = 0;
1523 }
1524 tcp.flags = RST;
1525 Then, the action drops all TCP options and payload data,
1527 and updates the TCP checksum. IP ttl is set to 255.
1528 Prerequisite: tcp
1530 external_ids : stage-name: optional string
1532 Human-readable name for this flow’s stage in the pipeline.
1533 external_ids : stage-hint: optional string, containing an uuid
1535 UUID of a OVN_Northbound record that caused this logical flow to
1536 be created. Currently used only for attribute of logical flows
1537 to northbound ACL records.
1538 external_ids : source: optional string
1540 Source file and line number of the code that added this flow to
1541 the pipeline.
1542 Common Columns:
1544 The overall purpose of these columns is described under Common Columns
1546 at the beginning of this document.
1547 external_ids: map of string-string pairs
1549
1551 The rows in this table define multicast groups of logical ports. Multi‐
1552 cast groups allow a single packet transmitted over a tunnel to a hyper‐
1553 visor to be delivered to multiple VMs on that hypervisor, which uses
1554 bandwidth more efficiently.
1555 Each row in this table defines a logical multicast group numbered tun‐
1557 nel_key within datapath, whose logical ports are listed in the ports
1558 column.
1559 Summary:
1561 datapath Datapath_Binding
1562 tunnel_key integer, in range 32,768 to 65,535
1563 name string
1564 ports set of 1 or more weak reference to
1565 Port_Bindings
1566 Details:
1568 datapath: Datapath_Binding
1569 The logical datapath in which the multicast group resides.
1570 tunnel_key: integer, in range 32,768 to 65,535
1572 The value used to designate this logical egress port in tunnel
1573 encapsulations. An index forces the key to be unique within the
1574 datapath. The unusual range ensures that multicast group IDs do
1575 not overlap with logical port IDs.
1576 name: string
1578 The logical multicast group’s name. An index forces the name to
1579 be unique within the datapath. Logical flows in the ingress
1580 pipeline may output to the group just as for individual logical
1581 ports, by assigning the group’s name to outport and executing an
1582 output action.
1583 Multicast group names and logical port names share a single
1585 namespace and thus should not overlap (but the database schema
1586 cannot enforce this). To try to avoid conflicts, ovn-northd uses
1587 names that begin with _MC_.
1588 ports: set of 1 or more weak reference to Port_Bindings
1590 The logical ports included in the multicast group. All of these
1591 ports must be in the datapath logical datapath (but the database
1592 schema cannot enforce this).
1593
1595 Each row in this table represents a meter that can be used for QoS or
1596 rate-limiting.
1597 Summary:
1599 name string (must be unique within table)
1600 unit string, either kbps or pktps
1601 bands set of 1 or more Meter_Bands
1602 Details:
1604 name: string (must be unique within table)
1605 A name for this meter.
1606 Names that begin with "__" (two underscores) are reserved for
1608 OVN internal use and should not be added manually.
1609 unit: string, either kbps or pktps
1611 The unit for rate and burst_rate parameters in the bands entry.
1612 kbps specifies kilobits per second, and pktps specifies packets
1613 per second.
1614 bands: set of 1 or more Meter_Bands
1616 The bands associated with this meter. Each band specifies a rate
1617 above which the band is to take the action action. If multiple
1618 bands’ rates are exceeded, then the band with the highest rate
1619 among the exceeded bands is selected.
1620
1622 Each row in this table represents a meter band which specifies the rate
1623 above which the configured action should be applied. These bands are
1624 referenced by the bands column in the Meter table.
1625 Summary:
1627 action string, must be drop
1628 rate integer, in range 1 to 4,294,967,295
1629 burst_size integer, in range 0 to 4,294,967,295
1630 Details:
1632 action: string, must be drop
1633 The action to execute when this band matches. The only supported
1634 action is drop.
1635 rate: integer, in range 1 to 4,294,967,295
1637 The rate limit for this band, in kilobits per second or bits per
1638 second, depending on whether the parent Meter entry’s unit col‐
1639 umn specified kbps or pktps.
1640 burst_size: integer, in range 0 to 4,294,967,295
1642 The maximum burst allowed for the band in kilobits or packets,
1643 depending on whether kbps or pktps was selected in the parent
1644 Meter entry’s unit column. If the size is zero, the switch is
1645 free to select some reasonable value depending on its configura‐
1646 tion.
1647
1649 Each row in this table represents a logical datapath, which implements
1650 a logical pipeline among the ports in the Port_Binding table associated
1651 with it. In practice, the pipeline in a given logical datapath imple‐
1652 ments either a logical switch or a logical router.
1653 The main purpose of a row in this table is provide a physical binding
1655 for a logical datapath. A logical datapath does not have a physical
1656 location, so its physical binding information is limited: just tun‐
1657 nel_key. The rest of the data in this table does not affect packet for‐
1658 warding.
1659 Summary:
1661 tunnel_key integer, in range 1 to 16,777,215 (must
1662 be unique within table)
1663 OVN_Northbound Relationship:
1664 external_ids : logical-switch
1665 optional string, containing an uuid
1666 external_ids : logical-router
1667 optional string, containing an uuid
1668 Naming:
1669 external_ids : name optional string
1670 external_ids : name2 optional string
1671 Common Columns:
1672 external_ids map of string-string pairs
1673 Details:
1675 tunnel_key: integer, in range 1 to 16,777,215 (must be unique within
1676 table)
1677 The tunnel key value to which the logical datapath is bound. The
1678 Tunnel Encapsulation section in ovn-architecture(7) describes
1679 how tunnel keys are constructed for each supported encapsula‐
1680 tion.
1681 OVN_Northbound Relationship:
1683 Each row in Datapath_Binding is associated with some logical datapath.
1685 ovn-northd uses these keys to track the association of a logical data‐
1686 path with concepts in the OVN_Northbound database.
1687 external_ids : logical-switch: optional string, containing an uuid
1689 For a logical datapath that represents a logical switch,
1690 ovn-northd stores in this key the UUID of the corresponding Log‐
1691 ical_Switch row in the OVN_Northbound database.
1692 external_ids : logical-router: optional string, containing an uuid
1694 For a logical datapath that represents a logical router,
1695 ovn-northd stores in this key the UUID of the corresponding Log‐
1696 ical_Router row in the OVN_Northbound database.
1697 Naming:
1699 ovn-northd copies these from the name fields in the OVN_Northbound
1701 database, either from name and external_ids:neutron:router_name in the
1702 Logical_Router table or from name and external_ids:neutron:network_name
1703 in the Logical_Switch table.
1704 external_ids : name: optional string
1706 A name for the logical datapath.
1707 external_ids : name2: optional string
1709 Another name for the logical datapath.
1710 Common Columns:
1712 The overall purpose of these columns is described under Common Columns
1714 at the beginning of this document.
1715 external_ids: map of string-string pairs
1717
1719 Each row in this table binds a logical port to a realization. For most
1720 logical ports, this means binding to some physical location, for exam‐
1721 ple by binding a logical port to a VIF that belongs to a VM running on
1722 a particular hypervisor. Other logical ports, such as logical patch
1723 ports, can be realized without a specific physical location, but their
1724 bindings are still expressed through rows in this table.
1725 For every Logical_Switch_Port record in OVN_Northbound database,
1727 ovn-northd creates a record in this table. ovn-northd populates and
1728 maintains every column except the chassis column, which it leaves empty
1729 in new records.
1730 ovn-controller/ovn-controller-vtep populates the chassis column for the
1732 records that identify the logical ports that are located on its hyper‐
1733 visor/gateway, which ovn-controller/ovn-controller-vtep in turn finds
1734 out by monitoring the local hypervisor’s Open_vSwitch database, which
1735 identifies logical ports via the conventions described in Integra‐
1736 tionGuide.rst. (The exceptions are for Port_Binding records with type
1737 of l3gateway, whose locations are identified by ovn-northd via the
1738 options:l3gateway-chassis column in this table. ovn-controller is still
1739 responsible to populate the chassis column.)
1740 When a chassis shuts down gracefully, it should clean up the chassis
1742 column that it previously had populated. (This is not critical because
1743 resources hosted on the chassis are equally unreachable regardless of
1744 whether their rows are present.) To handle the case where a VM is shut
1745 down abruptly on one chassis, then brought up again on a different one,
1746 ovn-controller/ovn-controller-vtep must overwrite the chassis column
1747 with new information.
1748 Summary:
1750 Core Features:
1751 datapath Datapath_Binding
1752 logical_port string (must be unique within table)
1753 encap optional weak reference to Encap
1754 chassis optional weak reference to Chassis
1755 gateway_chassis set of Gateway_Chassiss
1756 ha_chassis_group optional HA_Chassis_Group
1757 tunnel_key integer, in range 1 to 32,767
1758 mac set of strings
1759 type string
1760 Patch Options:
1761 options : peer optional string
1762 nat_addresses set of strings
1763 L3 Gateway Options:
1764 options : peer optional string
1765 options : l3gateway-chassis
1766 optional string
1767 options : nat-addresses optional string
1768 nat_addresses set of strings
1769 Localnet Options:
1770 options : network_name optional string
1771 tag optional integer, in range 1 to 4,095
1772 L2 Gateway Options:
1773 options : network_name optional string
1774 options : l2gateway-chassis
1775 optional string
1776 tag optional integer, in range 1 to 4,095
1777 VTEP Options:
1778 options : vtep-physical-switch
1779 optional string
1780 options : vtep-logical-switch
1781 optional string
1782 VMI (or VIF) Options:
1783 options : requested-chassis
1784 optional string
1785 options : qos_max_rate optional string
1786 options : qos_burst optional string
1787 options : qdisc_queue_id optional string, containing an integer,
1788 in range 1 to 61,440
1789 Chassis Redirect Options:
1790 options : distributed-port optional string
1791 options : redirect-chassis optional string
1792 Nested Containers:
1793 parent_port optional string
1794 tag optional integer, in range 1 to 4,095
1795 Naming:
1796 external_ids : name optional string
1797 Common Columns:
1798 external_ids map of string-string pairs
1799 Details:
1801 Core Features:
1802 datapath: Datapath_Binding
1804 The logical datapath to which the logical port belongs.
1805 logical_port: string (must be unique within table)
1807 A logical port, taken from name in the OVN_Northbound database’s
1808 Logical_Switch_Port table. OVN does not prescribe a particular
1809 format for the logical port ID.
1810 encap: optional weak reference to Encap
1812 Points to supported encapsulation configurations to transmit
1813 logical dataplane packets to this chassis. Each entry is a Encap
1814 record that describes the configuration.
1815 chassis: optional weak reference to Chassis
1817 The meaning of this column depends on the value of the type col‐
1818 umn. This is the meaning for each type
1819 (empty string)
1821 The physical location of the logical port. To success‐
1822 fully identify a chassis, this column must be a Chassis
1823 record. This is populated by ovn-controller.
1824 vtep The physical location of the hardware_vtep gateway. To
1826 successfully identify a chassis, this column must be a
1827 Chassis record. This is populated by ovn-controller-vtep.
1828 localnet
1830 Always empty. A localnet port is realized on every chas‐
1831 sis that has connectivity to the corresponding physical
1832 network.
1833 localport
1835 Always empty. A localport port is present on every chas‐
1836 sis.
1837 l3gateway
1839 The physical location of the L3 gateway. To successfully
1840 identify a chassis, this column must be a Chassis record.
1841 This is populated by ovn-controller based on the value of
1842 the options:l3gateway-chassis column in this table.
1843 l2gateway
1845 The physical location of this L2 gateway. To successfully
1846 identify a chassis, this column must be a Chassis record.
1847 This is populated by ovn-controller based on the value of
1848 the options:l2gateway-chassis column in this table.
1849 gateway_chassis: set of Gateway_Chassiss
1851 A list of Gateway_Chassis.
1852 This should only be populated for ports with type set to chas‐
1854 sisredirect. This column defines the list of chassis used as
1855 gateways where traffic will be redirected through.
1856 ha_chassis_group: optional HA_Chassis_Group
1858 This should only be populated for ports with type set to chas‐
1859 sisredirect. This column defines the HA chassis group with a
1860 list of HA chassis used as gateways where traffic will be redi‐
1861 rected through.
1862 tunnel_key: integer, in range 1 to 32,767
1864 A number that represents the logical port in the key (e.g. STT
1865 key or Geneve TLV) field carried within tunnel protocol packets.
1866 The tunnel ID must be unique within the scope of a logical data‐
1868 path.
1869 mac: set of strings
1871 The Ethernet address or addresses used as a source address on
1872 the logical port, each in the form xx:xx:xx:xx:xx:xx. The string
1873 unknown is also allowed to indicate that the logical port has an
1874 unknown set of (additional) source addresses.
1875 A VM interface would ordinarily have a single Ethernet address.
1877 A gateway port might initially only have unknown, and then add
1878 MAC addresses to the set as it learns new source addresses.
1879 type: string
1881 A type for this logical port. Logical ports can be used to model
1882 other types of connectivity into an OVN logical switch. The fol‐
1883 lowing types are defined:
1884 (empty string)
1886 VM (or VIF) interface.
1887 patch One of a pair of logical ports that act as if connected
1889 by a patch cable. Useful for connecting two logical data‐
1890 paths, e.g. to connect a logical router to a logical
1891 switch or to another logical router.
1892 l3gateway
1894 One of a pair of logical ports that act as if connected
1895 by a patch cable across multiple chassis. Useful for con‐
1896 necting a logical switch with a Gateway router (which is
1897 only resident on a particular chassis).
1898 localnet
1900 A connection to a locally accessible network from each
1901 ovn-controller instance. A logical switch can only have a
1902 single localnet port attached. This is used to model
1903 direct connectivity to an existing network.
1904 localport
1906 A connection to a local VIF. Traffic that arrives on a
1907 localport is never forwarded over a tunnel to another
1908 chassis. These ports are present on every chassis and
1909 have the same address in all of them. This is used to
1910 model connectivity to local services that run on every
1911 hypervisor.
1912 l2gateway
1914 An L2 connection to a physical network. The chassis this
1915 Port_Binding is bound to will serve as an L2 gateway to
1916 the network named by options:network_name.
1917 vtep A port to a logical switch on a VTEP gateway chassis. In
1919 order to get this port correctly recognized by the OVN
1920 controller, the options:vtep-physical-switch and
1921 options:vtep-logical-switch must also be defined.
1922 chassisredirect
1924 A logical port that represents a particular instance,
1925 bound to a specific chassis, of an otherwise distributed
1926 parent port (e.g. of type patch). A chassisredirect port
1927 should never be used as an inport. When an ingress pipe‐
1928 line sets the outport, it may set the value to a logical
1929 port of type chassisredirect. This will cause the packet
1930 to be directed to a specific chassis to carry out the
1931 egress pipeline. At the beginning of the egress pipeline,
1932 the outport will be reset to the value of the distributed
1933 port.
1934 Patch Options:
1936 These options apply to logical ports with type of patch.
1938 options : peer: optional string
1940 The logical_port in the Port_Binding record for the other side
1941 of the patch. The named logical_port must specify this logi‐
1942 cal_port in its own peer option. That is, the two patch logical
1943 ports must have reversed logical_port and peer values.
1944 nat_addresses: set of strings
1946 MAC address followed by a list of SNAT and DNAT external IP
1947 addresses, followed by is_chassis_resident("lport"), where lport
1948 is the name of a logical port on the same chassis where the cor‐
1949 responding NAT rules are applied. This is used to send gratu‐
1950 itous ARPs for SNAT and DNAT external IP addresses via localnet,
1951 from the chassis where lport resides. Example: 80:fa:5b:06:72:b7
1952 158.36.44.22 158.36.44.24 is_chassis_resident("foo1"). This
1953 would result in generation of gratuitous ARPs for IP addresses
1954 158.36.44.22 and 158.36.44.24 with a MAC address of
1955 80:fa:5b:06:72:b7 from the chassis where the logical port "foo1"
1956 resides.
1957 L3 Gateway Options:
1959 These options apply to logical ports with type of l3gateway.
1961 options : peer: optional string
1963 The logical_port in the Port_Binding record for the other side
1964 of the ’l3gateway’ port. The named logical_port must specify
1965 this logical_port in its own peer option. That is, the two
1966 ’l3gateway’ logical ports must have reversed logical_port and
1967 peer values.
1968 options : l3gateway-chassis: optional string
1970 The chassis in which the port resides.
1971 options : nat-addresses: optional string
1973 MAC address of the l3gateway port followed by a list of SNAT and
1974 DNAT external IP addresses. This is used to send gratuitous ARPs
1975 for SNAT and DNAT external IP addresses via localnet. Example:
1976 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
1977 in generation of gratuitous ARPs for IP addresses 158.36.44.22
1978 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
1979 is used in OVS versions prior to 2.8.
1980 nat_addresses: set of strings
1982 MAC address of the l3gateway port followed by a list of SNAT and
1983 DNAT external IP addresses. This is used to send gratuitous ARPs
1984 for SNAT and DNAT external IP addresses via localnet. Example:
1985 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
1986 in generation of gratuitous ARPs for IP addresses 158.36.44.22
1987 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
1988 is used in OVS version 2.8 and later versions.
1989 Localnet Options:
1991 These options apply to logical ports with type of localnet.
1993 options : network_name: optional string
1995 Required. ovn-controller uses the configuration entry
1996 ovn-bridge-mappings to determine how to connect to this network.
1997 ovn-bridge-mappings is a list of network names mapped to a local
1998 OVS bridge that provides access to that network. An example of
1999 configuring ovn-bridge-mappings would be: .IP
2000 $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
2001 When a logical switch has a localnet port attached, every chas‐
2003 sis that may have a local vif attached to that logical switch
2004 must have a bridge mapping configured to reach that localnet.
2005 Traffic that arrives on a localnet port is never forwarded over
2006 a tunnel to another chassis.
2007 tag: optional integer, in range 1 to 4,095
2009 If set, indicates that the port represents a connection to a
2010 specific VLAN on a locally accessible network. The VLAN ID is
2011 used to match incoming traffic and is also added to outgoing
2012 traffic.
2013 L2 Gateway Options:
2015 These options apply to logical ports with type of l2gateway.
2017 options : network_name: optional string
2019 Required. ovn-controller uses the configuration entry
2020 ovn-bridge-mappings to determine how to connect to this network.
2021 ovn-bridge-mappings is a list of network names mapped to a local
2022 OVS bridge that provides access to that network. An example of
2023 configuring ovn-bridge-mappings would be: .IP
2024 $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
2025 When a logical switch has a l2gateway port attached, the chassis
2027 that the l2gateway port is bound to must have a bridge mapping
2028 configured to reach the network identified by network_name.
2029 options : l2gateway-chassis: optional string
2031 Required. The chassis in which the port resides.
2032 tag: optional integer, in range 1 to 4,095
2034 If set, indicates that the gateway is connected to a specific
2035 VLAN on the physical network. The VLAN ID is used to match
2036 incoming traffic and is also added to outgoing traffic.
2037 VTEP Options:
2039 These options apply to logical ports with type of vtep.
2041 options : vtep-physical-switch: optional string
2043 Required. The name of the VTEP gateway.
2044 options : vtep-logical-switch: optional string
2046 Required. A logical switch name connected by the VTEP gateway.
2047 Must be set when type is vtep.
2048 VMI (or VIF) Options:
2050 These options apply to logical ports with type having (empty string)
2052 options : requested-chassis: optional string
2054 If set, identifies a specific chassis (by name or hostname) that
2055 is allowed to bind this port. Using this option will prevent
2056 thrashing between two chassis trying to bind the same port dur‐
2057 ing a live migration. It can also prevent similar thrashing due
2058 to a mis-configuration, if a port is accidentally created on
2059 more than one chassis.
2060 options : qos_max_rate: optional string
2062 If set, indicates the maximum rate for data sent from this
2063 interface, in bit/s. The traffic will be shaped according to
2064 this limit.
2065 options : qos_burst: optional string
2067 If set, indicates the maximum burst size for data sent from this
2068 interface, in bits.
2069 options : qdisc_queue_id: optional string, containing an integer, in
2071 range 1 to 61,440
2072 Indicates the queue number on the physical device. This is same
2073 as the queue_id used in OpenFlow in struct ofp_action_enqueue.
2074 Chassis Redirect Options:
2076 These options apply to logical ports with type of chassisredirect.
2078 options : distributed-port: optional string
2080 The name of the distributed port for which this chassisredirect
2081 port represents a particular instance.
2082 options : redirect-chassis: optional string
2084 The chassis that this chassisredirect port is bound to. This is
2085 taken from options:redirect-chassis in the OVN_Northbound data‐
2086 base’s Logical_Router_Port table.
2087 Nested Containers:
2089 These columns support containers nested within a VM. Specifically, they
2091 are used when type is empty and logical_port identifies the interface
2092 of a container spawned inside a VM. They are empty for containers or
2093 VMs that run directly on a hypervisor.
2094 parent_port: optional string
2096 This is taken from parent_name in the OVN_Northbound database’s
2097 Logical_Switch_Port table.
2098 tag: optional integer, in range 1 to 4,095
2100 Identifies the VLAN tag in the network traffic associated with
2101 that container’s network interface.
2102 This column is used for a different purpose when type is local‐
2104 net (see Localnet Options, above) or l2gateway (see L2 Gateway
2105 Options, above).
2106 Naming:
2108 external_ids : name: optional string
2110 For a logical switch port, ovn-northd copies this from exter‐
2111 nal_ids:neutron:port_name in the Logical_Switch_Port table in
2112 the OVN_Northbound database, if it is a nonempty string.
2113 For a logical switch port, ovn-northd does not currently set
2115 this key.
2116 Common Columns:
2118 external_ids: map of string-string pairs
2120 See External IDs at the beginning of this document.
2121 The ovn-northd program populates this column with all entries
2123 into the external_ids column of the Logical_Switch_Port table of
2124 the OVN_Northbound database.
2125
2127 Each row in this table specifies a binding from an IP address to an
2128 Ethernet address that has been discovered through ARP (for IPv4) or
2129 neighbor discovery (for IPv6). This table is primarily used to discover
2130 bindings on physical networks, because IP-to-MAC bindings for virtual
2131 machines are usually populated statically into the Port_Binding table.
2132 This table expresses a functional relationship: MAC_Binding(logi‐
2134 cal_port, ip) = mac.
2135 In outline, the lifetime of a logical router’s MAC binding looks like
2137 this:
2138 1. On hypervisor 1, a logical router determines that a packet
2140 should be forwarded to IP address A on one of its router
2141 ports. It uses its logical flow table to determine that A
2142 lacks a static IP-to-MAC binding and the get_arp action to
2143 determine that it lacks a dynamic IP-to-MAC binding.
2144 2. Using an OVN logical arp action, the logical router gener‐
2146 ates and sends a broadcast ARP request to the router port.
2147 It drops the IP packet.
2148 3. The logical switch attached to the router port delivers the
2150 ARP request to all of its ports. (It might make sense to
2151 deliver it only to ports that have no static IP-to-MAC bind‐
2152 ings, but this could also be surprising behavior.)
2153 4. A host or VM on hypervisor 2 (which might be the same as
2155 hypervisor 1) attached to the logical switch owns the IP
2156 address in question. It composes an ARP reply and unicasts
2157 it to the logical router port’s Ethernet address.
2158 5. The logical switch delivers the ARP reply to the logical
2160 router port.
2161 6. The logical router flow table executes a put_arp action. To
2163 record the IP-to-MAC binding, ovn-controller adds a row to
2164 the MAC_Binding table.
2165 7. On hypervisor 1, ovn-controller receives the updated
2167 MAC_Binding table from the OVN southbound database. The next
2168 packet destined to A through the logical router is sent
2169 directly to the bound Ethernet address.
2170 Summary:
2172 logical_port string
2173 ip string
2174 mac string
2175 datapath Datapath_Binding
2176 Details:
2178 logical_port: string
2179 The logical port on which the binding was discovered.
2180 ip: string
2182 The bound IP address.
2183 mac: string
2185 The Ethernet address to which the IP is bound.
2186 datapath: Datapath_Binding
2188 The logical datapath to which the logical port belongs.
2189
2191 Each row in this table stores the DHCP Options supported by native OVN
2192 DHCP. ovn-northd populates this table with the supported DHCP options.
2193 ovn-controller looks up this table to get the DHCP codes of the DHCP
2194 options defined in the "put_dhcp_opts" action. Please refer to the RFC
2195 2132 "https://tools.ietf.org/html/rfc2132" for the possible list of
2196 DHCP options that can be defined here.
2197 Summary:
2199 name string
2200 code integer, in range 0 to 254
2201 type string, one of bool, ipv4, static_routes,
2202 str, uint16, uint32, or uint8
2203 Details:
2205 name: string
2206 Name of the DHCP option.
2207 Example. name="router"
2209 code: integer, in range 0 to 254
2211 DHCP option code for the DHCP option as defined in the RFC 2132.
2212 Example. code=3
2214 type: string, one of bool, ipv4, static_routes, str, uint16, uint32, or
2216 uint8
2217 Data type of the DHCP option code.
2218 value: bool
2220 This indicates that the value of the DHCP option is a
2221 bool.
2222 Example. "name=ip_forward_enable", "code=19",
2224 "type=bool".
2225 put_dhcp_opts(..., ip_forward_enable = 1,...)
2227 value: uint8
2229 This indicates that the value of the DHCP option is an
2230 unsigned int8 (8 bits)
2231 Example. "name=default_ttl", "code=23", "type=uint8".
2233 put_dhcp_opts(..., default_ttl = 50,...)
2235 value: uint16
2237 This indicates that the value of the DHCP option is an
2238 unsigned int16 (16 bits).
2239 Example. "name=mtu", "code=26", "type=uint16".
2241 put_dhcp_opts(..., mtu = 1450,...)
2243 value: uint32
2245 This indicates that the value of the DHCP option is an
2246 unsigned int32 (32 bits).
2247 Example. "name=lease_time", "code=51", "type=uint32".
2249 put_dhcp_opts(..., lease_time = 86400,...)
2251 value: ipv4
2253 This indicates that the value of the DHCP option is an
2254 IPv4 address or addresses.
2255 Example. "name=router", "code=3", "type=ipv4".
2257 put_dhcp_opts(..., router = 10.0.0.1,...)
2259 Example. "name=dns_server", "code=6", "type=ipv4".
2261 put_dhcp_opts(..., dns_server = {8.8.8.8 7.7.7.7},...)
2263 value: static_routes
2265 This indicates that the value of the DHCP option contains
2266 a pair of IPv4 route and next hop addresses.
2267 Example. "name=classless_static_route", "code=121",
2269 "type=static_routes".
2270 put_dhcp_opts(..., classless_static_route =
2272 {30.0.0.0/24,10.0.0.4,0.0.0.0/0,10.0.0.1}...)
2273 value: str
2275 This indicates that the value of the DHCP option is a
2276 string.
2277 Example. "name=host_name", "code=12", "type=str".
2279
2281 Each row in this table stores the DHCPv6 Options supported by native
2282 OVN DHCPv6. ovn-northd populates this table with the supported DHCPv6
2283 options. ovn-controller looks up this table to get the DHCPv6 codes of
2284 the DHCPv6 options defined in the put_dhcpv6_opts action. Please refer
2285 to RFC 3315 and RFC 3646 for the list of DHCPv6 options that can be
2286 defined here.
2287 Summary:
2289 name string
2290 code integer, in range 0 to 254
2291 type string, one of ipv6, mac, or str
2292 Details:
2294 name: string
2295 Name of the DHCPv6 option.
2296 Example. name="ia_addr"
2298 code: integer, in range 0 to 254
2300 DHCPv6 option code for the DHCPv6 option as defined in the
2301 appropriate RFC.
2302 Example. code=3
2304 type: string, one of ipv6, mac, or str
2306 Data type of the DHCPv6 option code.
2307 value: ipv6
2309 This indicates that the value of the DHCPv6 option is an
2310 IPv6 address(es).
2311 Example. "name=ia_addr", "code=5", "type=ipv6".
2313 put_dhcpv6_opts(..., ia_addr = ae70::4,...)
2315 value: str
2317 This indicates that the value of the DHCPv6 option is a
2318 string.
2319 Example. "name=domain_search", "code=24", "type=str".
2321 put_dhcpv6_opts(..., domain_search = ovn.domain,...)
2323 value: mac
2325 This indicates that the value of the DHCPv6 option is a
2326 MAC address.
2327 Example. "name=server_id", "code=2", "type=mac".
2329 put_dhcpv6_opts(..., server_id = 01:02:03:04L05:06,...)
2331
2333 Configuration for a database connection to an Open vSwitch database
2334 (OVSDB) client.
2335 This table primarily configures the Open vSwitch database server
2337 (ovsdb-server).
2338 The Open vSwitch database server can initiate and maintain active con‐
2340 nections to remote clients. It can also listen for database connec‐
2341 tions.
2342 Summary:
2344 Core Features:
2345 target string (must be unique within table)
2346 read_only boolean
2347 role string
2348 Client Failure Detection and Handling:
2349 max_backoff optional integer, at least 1,000
2350 inactivity_probe optional integer
2351 Status:
2352 is_connected boolean
2353 status : last_error optional string
2354 status : state optional string, one of ACTIVE, BACKOFF,
2355 CONNECTING, IDLE, or VOID
2356 status : sec_since_connect optional string, containing an integer,
2357 at least 0
2358 status : sec_since_disconnect
2359 optional string, containing an integer,
2360 at least 0
2361 status : locks_held optional string
2362 status : locks_waiting optional string
2363 status : locks_lost optional string
2364 status : n_connections optional string, containing an integer,
2365 at least 2
2366 status : bound_port optional string, containing an integer
2367 Common Columns:
2368 external_ids map of string-string pairs
2369 other_config map of string-string pairs
2370 Details:
2372 Core Features:
2373 target: string (must be unique within table)
2375 Connection methods for clients.
2376 The following connection methods are currently supported:
2378 ssl:host[:port]
2380 The specified SSL port on the given host, which can
2381 either be a DNS name (if built with unbound library) or
2382 an IP address. A valid SSL configuration must be provided
2383 when this form is used, this configuration can be speci‐
2384 fied via command-line options or the SSL table.
2385 If port is not specified, it defaults to 6640.
2387 SSL support is an optional feature that is not always
2389 built as part of Open vSwitch.
2390 tcp:host[:port]
2392 The specified TCP port on the given host, which can
2393 either be a DNS name (if built with unbound library) or
2394 an IP address (IPv4 or IPv6). If host is an IPv6 address,
2395 wrap it in square brackets, e.g. tcp:[::1]:6640.
2396 If port is not specified, it defaults to 6640.
2398 pssl:[port][:host]
2400 Listens for SSL connections on the specified TCP port.
2401 Specify 0 for port to have the kernel automatically
2402 choose an available port. If host, which can either be a
2403 DNS name (if built with unbound library) or an IP
2404 address, is specified, then connections are restricted to
2405 the resolved or specified local IP address (either IPv4
2406 or IPv6 address). If host is an IPv6 address, wrap in
2407 square brackets, e.g. pssl:6640:[::1]. If host is not
2408 specified then it listens only on IPv4 (but not IPv6)
2409 addresses. A valid SSL configuration must be provided
2410 when this form is used, this can be specified either via
2411 command-line options or the SSL table.
2412 If port is not specified, it defaults to 6640.
2414 SSL support is an optional feature that is not always
2416 built as part of Open vSwitch.
2417 ptcp:[port][:host]
2419 Listens for connections on the specified TCP port. Spec‐
2420 ify 0 for port to have the kernel automatically choose an
2421 available port. If host, which can either be a DNS name
2422 (if built with unbound library) or an IP address, is
2423 specified, then connections are restricted to the
2424 resolved or specified local IP address (either IPv4 or
2425 IPv6 address). If host is an IPv6 address, wrap it in
2426 square brackets, e.g. ptcp:6640:[::1]. If host is not
2427 specified then it listens only on IPv4 addresses.
2428 If port is not specified, it defaults to 6640.
2430 When multiple clients are configured, the target values must be
2432 unique. Duplicate target values yield unspecified results.
2433 read_only: boolean
2435 true to restrict these connections to read-only transactions,
2436 false to allow them to modify the database.
2437 role: string
2439 String containing role name for this connection entry.
2440 Client Failure Detection and Handling:
2442 max_backoff: optional integer, at least 1,000
2444 Maximum number of milliseconds to wait between connection
2445 attempts. Default is implementation-specific.
2446 inactivity_probe: optional integer
2448 Maximum number of milliseconds of idle time on connection to the
2449 client before sending an inactivity probe message. If Open
2450 vSwitch does not communicate with the client for the specified
2451 number of seconds, it will send a probe. If a response is not
2452 received for the same additional amount of time, Open vSwitch
2453 assumes the connection has been broken and attempts to recon‐
2454 nect. Default is implementation-specific. A value of 0 disables
2455 inactivity probes.
2456 Status:
2458 Key-value pair of is_connected is always updated. Other key-value pairs
2460 in the status columns may be updated depends on the target type.
2461 When target specifies a connection method that listens for inbound con‐
2463 nections (e.g. ptcp: or punix:), both n_connections and is_connected
2464 may also be updated while the remaining key-value pairs are omitted.
2465 On the other hand, when target specifies an outbound connection, all
2467 key-value pairs may be updated, except the above-mentioned two key-
2468 value pairs associated with inbound connection targets. They are omit‐
2469 ted.
2470 is_connected: boolean
2472 true if currently connected to this client, false otherwise.
2473 status : last_error: optional string
2475 A human-readable description of the last error on the connection
2476 to the manager; i.e. strerror(errno). This key will exist only
2477 if an error has occurred.
2478 status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
2480 IDLE, or VOID
2481 The state of the connection to the manager:
2482 VOID Connection is disabled.
2484 BACKOFF
2486 Attempting to reconnect at an increasing period.
2487 CONNECTING
2489 Attempting to connect.
2490 ACTIVE Connected, remote host responsive.
2492 IDLE Connection is idle. Waiting for response to keep-alive.
2494 These values may change in the future. They are provided only
2496 for human consumption.
2497 status : sec_since_connect: optional string, containing an integer, at
2499 least 0
2500 The amount of time since this client last successfully connected
2501 to the database (in seconds). Value is empty if client has never
2502 successfully been connected.
2503 status : sec_since_disconnect: optional string, containing an integer,
2505 at least 0
2506 The amount of time since this client last disconnected from the
2507 database (in seconds). Value is empty if client has never dis‐
2508 connected.
2509 status : locks_held: optional string
2511 Space-separated list of the names of OVSDB locks that the con‐
2512 nection holds. Omitted if the connection does not hold any
2513 locks.
2514 status : locks_waiting: optional string
2516 Space-separated list of the names of OVSDB locks that the con‐
2517 nection is currently waiting to acquire. Omitted if the connec‐
2518 tion is not waiting for any locks.
2519 status : locks_lost: optional string
2521 Space-separated list of the names of OVSDB locks that the con‐
2522 nection has had stolen by another OVSDB client. Omitted if no
2523 locks have been stolen from this connection.
2524 status : n_connections: optional string, containing an integer, at
2526 least 2
2527 When target specifies a connection method that listens for
2528 inbound connections (e.g. ptcp: or pssl:) and more than one con‐
2529 nection is actually active, the value is the number of active
2530 connections. Otherwise, this key-value pair is omitted.
2531 status : bound_port: optional string, containing an integer
2533 When target is ptcp: or pssl:, this is the TCP port on which the
2534 OVSDB server is listening. (This is particularly useful when
2535 target specifies a port of 0, allowing the kernel to choose any
2536 available port.)
2537 Common Columns:
2539 The overall purpose of these columns is described under Common Columns
2541 at the beginning of this document.
2542 external_ids: map of string-string pairs
2544 other_config: map of string-string pairs
2546
2548 SSL configuration for ovn-sb database access.
2549 Summary:
2551 private_key string
2552 certificate string
2553 ca_cert string
2554 bootstrap_ca_cert boolean
2555 ssl_protocols string
2556 ssl_ciphers string
2557 Common Columns:
2558 external_ids map of string-string pairs
2559 Details:
2561 private_key: string
2562 Name of a PEM file containing the private key used as the
2563 switch’s identity for SSL connections to the controller.
2564 certificate: string
2566 Name of a PEM file containing a certificate, signed by the cer‐
2567 tificate authority (CA) used by the controller and manager, that
2568 certifies the switch’s private key, identifying a trustworthy
2569 switch.
2570 ca_cert: string
2572 Name of a PEM file containing the CA certificate used to verify
2573 that the switch is connected to a trustworthy controller.
2574 bootstrap_ca_cert: boolean
2576 If set to true, then Open vSwitch will attempt to obtain the CA
2577 certificate from the controller on its first SSL connection and
2578 save it to the named PEM file. If it is successful, it will
2579 immediately drop the connection and reconnect, and from then on
2580 all SSL connections must be authenticated by a certificate
2581 signed by the CA certificate thus obtained. This option exposes
2582 the SSL connection to a man-in-the-middle attack obtaining the
2583 initial CA certificate. It may still be useful for bootstrap‐
2584 ping.
2585 ssl_protocols: string
2587 List of SSL protocols to be enabled for SSL connections. The
2588 default when this option is omitted is TLSv1,TLSv1.1,TLSv1.2.
2589 ssl_ciphers: string
2591 List of ciphers (in OpenSSL cipher string format) to be sup‐
2592 ported for SSL connections. The default when this option is
2593 omitted is HIGH:!aNULL:!MD5.
2594 Common Columns:
2596 The overall purpose of these columns is described under Common Columns
2598 at the beginning of this document.
2599 external_ids: map of string-string pairs
2601
2603 Each row in this table stores the DNS records. The OVN action
2604 dns_lookup uses this table for DNS resolution.
2605 Summary:
2607 records map of string-string pairs
2608 datapaths set of 1 or more Datapath_Bindings
2609 Common Columns:
2610 external_ids map of string-string pairs
2611 Details:
2613 records: map of string-string pairs
2614 Key-value pair of DNS records with DNS query name as the key and
2615 a string of IP address(es) separated by comma or space as the
2616 value.
2617 Example: "vm1.ovn.org" = "10.0.0.4 aef0::4"
2619 datapaths: set of 1 or more Datapath_Bindings
2621 The DNS records defined in the column records will be applied
2622 only to the DNS queries originating from the datapaths defined
2623 in this column.
2624 Common Columns:
2626 external_ids: map of string-string pairs
2628 See External IDs at the beginning of this document.
2629
2631 Role table for role-based access controls.
2632 Summary:
2634 name string
2635 permissions map of string-weak reference to RBAC_Per‐
2636 mission pairs
2637 Details:
2639 name: string
2640 The role name, corresponding to the role column in the Connec‐
2641 tion table.
2642 permissions: map of string-weak reference to RBAC_Permission pairs
2644 A mapping of table names to rows in the RBAC_Permission table.
2645
2647 Permissions table for role-based access controls.
2648 Summary:
2650 table string
2651 authorization set of strings
2652 insert_delete boolean
2653 update set of strings
2654 Details:
2656 table: string
2657 Name of table to which this row applies.
2658 authorization: set of strings
2660 Set of strings identifying columns and column:key pairs to be
2661 compared with client ID. At least one match is required in order
2662 to be authorized. A zero-length string is treated as a special
2663 value indicating all clients should be considered authorized.
2664 insert_delete: boolean
2666 When "true", row insertions and authorized row deletions are
2667 permitted.
2668 update: set of strings
2670 Set of strings identifying columns and column:key pairs that
2671 authorized clients are allowed to modify.
2672
2674 Association of Port_Binding rows of type chassisredirect to a Chassis.
2675 The traffic going out through a specific chassisredirect port will be
2676 redirected to a chassis, or a set of them in high availability configu‐
2677 rations.
2678 Summary:
2680 name string (must be unique within table)
2681 chassis optional weak reference to Chassis
2682 priority integer, in range 0 to 32,767
2683 options map of string-string pairs
2684 Common Columns:
2685 external_ids map of string-string pairs
2686 Details:
2688 name: string (must be unique within table)
2689 Name of the Gateway_Chassis.
2690 A suggested, but not required naming convention is
2692 ${port_name}_${chassis_name}.
2693 chassis: optional weak reference to Chassis
2695 The Chassis to which we send the traffic.
2696 priority: integer, in range 0 to 32,767
2698 This is the priority the specific Chassis among all Gate‐
2699 way_Chassis belonging to the same Port_Binding.
2700 options: map of string-string pairs
2702 Reserved for future use.
2703 Common Columns:
2705 The overall purpose of these columns is described under Common Columns
2707 at the beginning of this document.
2708 external_ids: map of string-string pairs
2710
2712 Summary:
2713 chassis optional weak reference to Chassis
2714 priority integer, in range 0 to 32,767
2715 Common Columns:
2716 external_ids map of string-string pairs
2717 Details:
2719 chassis: optional weak reference to Chassis
2720 The Chassis which provides the HA functionality.
2721 priority: integer, in range 0 to 32,767
2723 Priority of the HA chassis. Chassis with highest priority will
2724 be the master in the HA chassis group.
2725 Common Columns:
2727 external_ids: map of string-string pairs
2729 See External IDs at the beginning of this document.
2730
2732 Table representing a group of chassis which can provide High availabil‐
2733 ity services. Each chassis in the group is represented by the table
2734 HA_Chassis. The HA chassis with highest priority will be the master of
2735 this group. If the master chassis failover is detected, the HA chassis
2736 with the next higher priority takes over the responsibility of provid‐
2737 ing the HA. If ha_chassis_group column of the table Port_Binding refer‐
2738 ences this table, then this HA chassis group provides the gateway func‐
2739 tionality and redirects the gateway traffic to the master of this
2740 group.
2741 Summary:
2743 name string (must be unique within table)
2744 ha_chassis set of HA_Chassiss
2745 ref_chassis set of weak reference to Chassiss
2746 Common Columns:
2747 external_ids map of string-string pairs
2748 Details:
2750 name: string (must be unique within table)
2751 Name of the HA_Chassis_Group. Name should be unique.
2752 ha_chassis: set of HA_Chassiss
2754 A list of HA_Chassis which belongs to this group.
2755 ref_chassis: set of weak reference to Chassiss
2757 A list of chassis which references this HA chassis group.
2758 Common Columns:
2760 external_ids: map of string-string pairs
2762 See External IDs at the beginning of this document.
2763Open vSwitch 2.11.1 DB Schema 2.3.0 ovn-sb(5)