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 ab‐
10 straction. For an introduction to OVN, please see ovn-architecture(7).
11 The OVN Southbound database sits at the center of the OVN architecture.
13 It is the one component that speaks both southbound directly to all the
14 hypervisors and gateways, via ovn-controller/ovn-controller-vtep, and
15 northbound to the Cloud Management System, via ovn-northd:
16 Database Structure
18 The OVN Southbound database contains classes of data with different
19 properties, as described in the sections below.
20 Physical network
22 Physical network tables contain information about the chassis nodes in
24 the system. This contains all the information necessary to wire the
25 overlay, such as IP addresses, supported tunnel types, and security
26 keys.
27 The amount of physical network data is small (O(n) in the number of
29 chassis) and it changes infrequently, so it can be replicated to every
30 chassis.
31 The Chassis and Encap tables are the physical network tables.
33 Logical Network
35 Logical network tables contain the topology of logical switches and
37 routers, ACLs, firewall rules, and everything needed to describe how
38 packets traverse a logical network, represented as logical datapath
39 flows (see Logical Datapath Flows, below).
40 Logical network data may be large (O(n) in the number of logical ports,
42 ACL rules, etc.). Thus, to improve scaling, each chassis should receive
43 only data related to logical networks in which that chassis partici‐
44 pates.
45 The logical network data is ultimately controlled by the cloud manage‐
47 ment system (CMS) running northbound of OVN. That CMS determines the
48 entire OVN logical configuration and therefore the logical network data
49 at any given time is a deterministic function of the CMS’s configura‐
50 tion, although that happens indirectly via the OVN_Northbound database
51 and ovn-northd.
52 Logical network data is likely to change more quickly than physical
54 network data. This is especially true in a container environment where
55 containers are created and destroyed (and therefore added to and
56 deleted from logical switches) quickly.
57 The Logical_Flow, Multicast_Group, Address_Group, DHCP_Options,
59 DHCPv6_Options, and DNS tables contain logical network data.
60 Logical-physical bindings
62 These tables link logical and physical components. They show the cur‐
64 rent placement of logical components (such as VMs and VIFs) onto chas‐
65 sis, and map logical entities to the values that represent them in tun‐
66 nel encapsulations.
67 These tables change frequently, at least every time a VM powers up or
69 down or migrates, and especially quickly in a container environment.
70 The amount of data per VM (or VIF) is small.
71 Each chassis is authoritative about the VMs and VIFs that it hosts at
73 any given time and can efficiently flood that state to a central loca‐
74 tion, so the consistency needs are minimal.
75 The Port_Binding and Datapath_Binding tables contain binding data.
77 MAC bindings
79 The MAC_Binding table tracks the bindings from IP addresses to Ethernet
81 addresses that are dynamically discovered using ARP (for IPv4) and
82 neighbor discovery (for IPv6). Usually, IP-to-MAC bindings for virtual
83 machines are statically populated into the Port_Binding table, so
84 MAC_Binding is primarily used to discover bindings on physical net‐
85 works.
86 Common Columns
88 Some tables contain a special column named external_ids. This column
89 has the same form and purpose each place that it appears, so we de‐
90 scribe it here to save space later.
91 external_ids: map of string-string pairs
93 Key-value pairs for use by the software that manages the
94 OVN Southbound database rather than by ovn-con‐
95 troller/ovn-controller-vtep. In particular, ovn-northd
96 can use key-value pairs in this column to relate entities
97 in the southbound database to higher-level entities (such
98 as entities in the OVN Northbound database). Individual
99 key-value pairs in this column may be documented in some
100 cases to aid in understanding and troubleshooting, but
101 the reader should not mistake such documentation as com‐
102 prehensive.
103
105 The following list summarizes the purpose of each of the tables in the
106 OVN_Southbound database. Each table is described in more detail on a
107 later page.
108 Table Purpose
110 SB_Global Southbound configuration
111 Chassis Physical Network Hypervisor and Gateway Information
112 Chassis_Private
113 Chassis Private
114 Encap Encapsulation Types
115 Address_Set
116 Address Sets
117 Port_Group
118 Port Groups
119 Logical_Flow
120 Logical Network Flows
121 Logical_DP_Group
122 Logical Datapath Groups
123 Multicast_Group
124 Logical Port Multicast Groups
125 Meter Meter entry
126 Meter_Band
127 Band for meter entries
128 Datapath_Binding
129 Physical-Logical Datapath Bindings
130 Port_Binding
131 Physical-Logical Port Bindings
132 MAC_Binding
133 IP to MAC bindings
134 DHCP_Options
135 DHCP Options supported by native OVN DHCP
136 DHCPv6_Options
137 DHCPv6 Options supported by native OVN DHCPv6
138 Connection
139 OVSDB client connections.
140 SSL SSL configuration.
141 DNS Native DNS resolution
142 RBAC_Role RBAC_Role configuration.
143 RBAC_Permission
144 RBAC_Permission configuration.
145 Gateway_Chassis
146 Gateway_Chassis configuration.
147 HA_Chassis
148 HA_Chassis configuration.
149 HA_Chassis_Group
150 HA_Chassis_Group configuration.
151 Controller_Event
152 Controller Event table
153 IP_Multicast
154 IP_Multicast configuration.
155 IGMP_Group
156 IGMP_Group configuration.
157 Service_Monitor
158 Service_Monitor configuration.
159 Load_Balancer
160 Load_Balancer configuration.
161 BFD BFD configuration.
162 FDB Port to MAC bindings
163
165 Southbound configuration for an OVN system. This table must have ex‐
166 actly one row.
167 Summary:
169 Status:
170 nb_cfg integer
171 Common Columns:
172 external_ids map of string-string pairs
173 options map of string-string pairs
174 Common options:
175 options map of string-string pairs
176 Options for configuring BFD:
177 options : bfd-min-rx optional string
178 options : bfd-decay-min-rx
179 optional string
180 options : bfd-min-tx optional string
181 options : bfd-mult optional string
182 Connection Options:
183 connections set of Connections
184 ssl optional SSL
185 Security Configurations:
186 ipsec boolean
187 Details:
189 Status:
190 This column allow a client to track the overall configuration state of
192 the system.
193 nb_cfg: integer
195 Sequence number for the configuration. When a CMS or ovn-nbctl
196 updates the northbound database, it increments the nb_cfg column
197 in the NB_Global table in the northbound database. In turn, when
198 ovn-northd updates the southbound database to bring it up to
199 date with these changes, it updates this column to the same
200 value.
201 Common Columns:
203 external_ids: map of string-string pairs
205 See External IDs at the beginning of this document.
206 options: map of string-string pairs
208 Common options:
210 options: map of string-string pairs
212 This column provides general key/value settings. The supported
213 options are described individually below.
214 Options for configuring BFD:
216 These options apply when ovn-controller configures BFD on tunnels in‐
218 terfaces.
219 options : bfd-min-rx: optional string
221 BFD option min-rx value to use when configuring BFD on tunnel
222 interfaces.
223 options : bfd-decay-min-rx: optional string
225 BFD option decay-min-rx value to use when configuring BFD on
226 tunnel interfaces.
227 options : bfd-min-tx: optional string
229 BFD option min-tx value to use when configuring BFD on tunnel
230 interfaces.
231 options : bfd-mult: optional string
233 BFD option mult value to use when configuring BFD on tunnel in‐
234 terfaces.
235 Connection Options:
237 connections: set of Connections
239 Database clients to which the Open vSwitch database server
240 should connect or on which it should listen, along with options
241 for how these connections should be configured. See the Connec‐
242 tion table for more information.
243 ssl: optional SSL
245 Global SSL configuration.
246 Security Configurations:
248 ipsec: boolean
250 Tunnel encryption configuration. If this column is set to be
251 true, all OVN tunnels will be encrypted with IPsec.
252
254 Each row in this table represents a hypervisor or gateway (a chassis)
255 in the physical network. Each chassis, via ovn-controller/ovn-con‐
256 troller-vtep, adds and updates its own row, and keeps a copy of the re‐
257 maining rows to determine how to reach other hypervisors.
258 When a chassis shuts down gracefully, it should remove its own row.
260 (This is not critical because resources hosted on the chassis are
261 equally unreachable regardless of whether the row is present.) If a
262 chassis shuts down permanently without removing its row, some kind of
263 manual or automatic cleanup is eventually needed; we can devise a
264 process for that as necessary.
265 Summary:
267 name string (must be unique within table)
268 hostname string
269 nb_cfg integer
270 other_config : ovn-bridge-mappings
271 optional string
272 other_config : datapath-type optional string
273 other_config : iface-types optional string
274 other_config : ovn-cms-options
275 optional string
276 other_config : is-interconn optional string
277 other_config : is-remote optional string
278 transport_zones set of strings
279 other_config : ovn-chassis-mac-mappings
280 optional string
281 other_config : port-up-notif optional string
282 Common Columns:
283 external_ids map of string-string pairs
284 Encapsulation Configuration:
285 encaps set of 1 or more Encaps
286 Gateway Configuration:
287 vtep_logical_switches set of strings
288 Details:
290 name: string (must be unique within table)
291 OVN does not prescribe a particular format for chassis names.
292 ovn-controller populates this column using external_ids:system-
293 id in the Open_vSwitch database’s Open_vSwitch table. ovn-con‐
294 troller-vtep populates this column with name in the hard‐
295 ware_vtep database’s Physical_Switch table.
296 hostname: string
298 The hostname of the chassis, if applicable. ovn-controller will
299 populate this column with the hostname of the host it is running
300 on. ovn-controller-vtep will leave this column empty.
301 nb_cfg: integer
303 Deprecated. This column is replaced by the nb_cfg column of the
304 Chassis_Private table.
305 other_config : ovn-bridge-mappings: optional string
307 ovn-controller populates this key with the set of bridge map‐
308 pings it has been configured to use. Other applications should
309 treat this key as read-only. See ovn-controller(8) for more in‐
310 formation.
311 other_config : datapath-type: optional string
313 ovn-controller populates this key with the datapath type config‐
314 ured in the datapath_type column of the Open_vSwitch database’s
315 Bridge table. Other applications should treat this key as read-
316 only. See ovn-controller(8) for more information.
317 other_config : iface-types: optional string
319 ovn-controller populates this key with the interface types con‐
320 figured in the iface_types column of the Open_vSwitch database’s
321 Open_vSwitch table. Other applications should treat this key as
322 read-only. See ovn-controller(8) for more information.
323 other_config : ovn-cms-options: optional string
325 ovn-controller populates this key with the set of options con‐
326 figured in the external_ids:ovn-cms-options column of the
327 Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
328 troller(8) for more information.
329 other_config : is-interconn: optional string
331 ovn-controller populates this key with the setting configured in
332 the external_ids:ovn-is-interconn column of the Open_vSwitch
333 database’s Open_vSwitch table. If set to true, the chassis is
334 used as an interconnection gateway. See ovn-controller(8) for
335 more information.
336 other_config : is-remote: optional string
338 ovn-ic set this key to true for remote interconnection gateway
339 chassises learned from the interconnection southbound database.
340 See ovn-ic(8) for more information.
341 transport_zones: set of strings
343 ovn-controller populates this key with the transport zones con‐
344 figured in the external_ids:ovn-transport-zones column of the
345 Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
346 troller(8) for more information.
347 other_config : ovn-chassis-mac-mappings: optional string
349 ovn-controller populates this key with the set of options con‐
350 figured in the external_ids:ovn-chassis-mac-mappings column of
351 the Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
352 troller(8) for more information.
353 other_config : port-up-notif: optional string
355 ovn-controller populates this key with true when it supports
356 Port_Binding.up.
357 Common Columns:
359 The overall purpose of these columns is described under Common Columns
361 at the beginning of this document.
362 external_ids: map of string-string pairs
364 Encapsulation Configuration:
366 OVN uses encapsulation to transmit logical dataplane packets between
368 chassis.
369 encaps: set of 1 or more Encaps
371 Points to supported encapsulation configurations to transmit
372 logical dataplane packets to this chassis. Each entry is a Encap
373 record that describes the configuration.
374 Gateway Configuration:
376 A gateway is a chassis that forwards traffic between the OVN-managed
378 part of a logical network and a physical VLAN, extending a tunnel-based
379 logical network into a physical network. Gateways are typically dedi‐
380 cated nodes that do not host VMs and will be controlled by ovn-con‐
381 troller-vtep.
382 vtep_logical_switches: set of strings
384 Stores all VTEP logical switch names connected by this gateway
385 chassis. The Port_Binding table entry with options:vtep-physi‐
386 cal-switch equal Chassis name, and options:vtep-logical-switch
387 value in Chassis vtep_logical_switches, will be associated with
388 this Chassis.
389
391 Each row in this table maintains per chassis private data that are ac‐
392 cessed only by the owning chassis (write only) and ovn-northd, not by
393 any other chassis. These data are stored in this separate table instead
394 of the Chassis table for performance considerations: the rows in this
395 table can be conditionally monitored by chassises so that each chassis
396 only get update notifications for its own row, to avoid unnecessary
397 chassis private data update flooding in a large scale deployment.
398 Summary:
400 name string (must be unique within table)
401 chassis optional weak reference to Chassis
402 nb_cfg integer
403 nb_cfg_timestamp integer
404 Common Columns:
405 external_ids map of string-string pairs
406 Details:
408 name: string (must be unique within table)
409 The name of the chassis that owns these chassis-private data.
410 chassis: optional weak reference to Chassis
412 The reference to Chassis table for the chassis that owns these
413 chassis-private data.
414 nb_cfg: integer
416 Sequence number for the configuration. When ovn-controller up‐
417 dates the configuration of a chassis from the contents of the
418 southbound database, it copies nb_cfg from the SB_Global table
419 into this column.
420 nb_cfg_timestamp: integer
422 The timestamp when ovn-controller finishes processing the change
423 corresponding to nb_cfg.
424 Common Columns:
426 The overall purpose of these columns is described under Common Columns
428 at the beginning of this document.
429 external_ids: map of string-string pairs
431
433 The encaps column in the Chassis table refers to rows in this table to
434 identify how OVN may transmit logical dataplane packets to this chas‐
435 sis. Each chassis, via ovn-controller(8) or ovn-controller-vtep(8),
436 adds and updates its own rows and keeps a copy of the remaining rows to
437 determine how to reach other chassis.
438 Summary:
440 type string, one of geneve, stt, or vxlan
441 options map of string-string pairs
442 options : csum optional string, either true or false
443 options : dst_port optional string, containing an integer
444 ip string
445 chassis_name string
446 Details:
448 type: string, one of geneve, stt, or vxlan
449 The encapsulation to use to transmit packets to this chassis.
450 Hypervisors must use either geneve or stt. Gateways may use
451 vxlan, geneve, or stt.
452 options: map of string-string pairs
454 Options for configuring the encapsulation, which may be type
455 specific.
456 options : csum: optional string, either true or false
458 csum indicates whether this chassis can transmit and receive
459 packets that include checksums with reasonable performance. It
460 hints to senders transmitting data to this chassis that they
461 should use checksums to protect OVN metadata. ovn-controller
462 populates this key with the value defined in external_ids:ovn-
463 encap-csum column of the Open_vSwitch database’s Open_vSwitch
464 table. Other applications should treat this key as read-only.
465 See ovn-controller(8) for more information.
466 In terms of performance, checksumming actually significantly in‐
468 creases throughput in most common cases when running on Linux
469 based hosts without NICs supporting encapsulation hardware off‐
470 load (around 60% for bulk traffic). The reason is that generally
471 all NICs are capable of offloading transmitted and received
472 TCP/UDP checksums (viewed as ordinary data packets and not as
473 tunnels). The benefit comes on the receive side where the vali‐
474 dated outer checksum can be used to additionally validate an in‐
475 ner checksum (such as TCP), which in turn allows aggregation of
476 packets to be more efficiently handled by the rest of the stack.
477 Not all devices see such a benefit. The most notable exception
479 is hardware VTEPs. These devices are designed to not buffer en‐
480 tire packets in their switching engines and are therefore unable
481 to efficiently compute or validate full packet checksums. In ad‐
482 dition certain versions of the Linux kernel are not able to
483 fully take advantage of encapsulation NIC offloads in the pres‐
484 ence of checksums. (This is actually a pretty narrow corner case
485 though: earlier versions of Linux don’t support encapsulation
486 offloads at all and later versions support both offloads and
487 checksums well.)
488 csum defaults to false for hardware VTEPs and true for all other
490 cases.
491 This option applies to geneve and vxlan encapsulations.
493 options : dst_port: optional string, containing an integer
495 If set, overrides the UDP (for geneve and vxlan) or TCP (for
496 stt) destination port.
497 ip: string
499 The IPv4 address of the encapsulation tunnel endpoint.
500 chassis_name: string
502 The name of the chassis that created this encap.
503
505 This table contains address sets synced from the Address_Set table in
506 the OVN_Northbound database and address sets generated from the
507 Port_Group table in the OVN_Northbound database.
508 See the documentation for the Address_Set table and Port_Group table in
510 the OVN_Northbound database for details.
511 Summary:
513 name string (must be unique within table)
514 addresses set of strings
515 Details:
517 name: string (must be unique within table)
518 addresses: set of strings
520
522 This table contains names for the logical switch ports in the
523 OVN_Northbound database that belongs to the same group that is defined
524 in Port_Group in the OVN_Northbound database.
525 Summary:
527 name string (must be unique within table)
528 ports set of strings
529 Details:
531 name: string (must be unique within table)
532 ports: set of strings
534
536 Each row in this table represents one logical flow. ovn-northd popu‐
537 lates this table with logical flows that implement the L2 and L3
538 topologies specified in the OVN_Northbound database. Each hypervisor,
539 via ovn-controller, translates the logical flows into OpenFlow flows
540 specific to its hypervisor and installs them into Open vSwitch.
541 Logical flows are expressed in an OVN-specific format, described here.
543 A logical datapath flow is much like an OpenFlow flow, except that the
544 flows are written in terms of logical ports and logical datapaths in‐
545 stead of physical ports and physical datapaths. Translation between
546 logical and physical flows helps to ensure isolation between logical
547 datapaths. (The logical flow abstraction also allows the OVN central‐
548 ized components to do less work, since they do not have to separately
549 compute and push out physical flows to each chassis.)
550 The default action when no flow matches is to drop packets.
552 Architectural Logical Life Cycle of a Packet
554 This following description focuses on the life cycle of a packet
556 through a logical datapath, ignoring physical details of the implemen‐
557 tation. Please refer to Architectural Physical Life Cycle of a Packet
558 in ovn-architecture(7) for the physical information.
559 The description here is written as if OVN itself executes these steps,
561 but in fact OVN (that is, ovn-controller) programs Open vSwitch, via
562 OpenFlow and OVSDB, to execute them on its behalf.
563 At a high level, OVN passes each packet through the logical datapath’s
565 logical ingress pipeline, which may output the packet to one or more
566 logical port or logical multicast groups. For each such logical output
567 port, OVN passes the packet through the datapath’s logical egress pipe‐
568 line, which may either drop the packet or deliver it to the destina‐
569 tion. Between the two pipelines, outputs to logical multicast groups
570 are expanded into logical ports, so that the egress pipeline only pro‐
571 cesses a single logical output port at a time. Between the two pipe‐
572 lines is also where, when necessary, OVN encapsulates a packet in a
573 tunnel (or tunnels) to transmit to remote hypervisors.
574 In more detail, to start, OVN searches the Logical_Flow table for a row
576 with correct logical_datapath or a logical_dp_group, a pipeline of
577 ingress, a table_id of 0, and a match that is true for the packet. If
578 none is found, OVN drops the packet. If OVN finds more than one, it
579 chooses the match with the highest priority. Then OVN executes each of
580 the actions specified in the row’s actions column, in the order speci‐
581 fied. Some actions, such as those to modify packet headers, require no
582 further details. The next and output actions are special.
583 The next action causes the above process to be repeated recursively,
585 except that OVN searches for table_id of 1 instead of 0. Similarly, any
586 next action in a row found in that table would cause a further search
587 for a table_id of 2, and so on. When recursive processing completes,
588 flow control returns to the action following next.
589 The output action also introduces recursion. Its effect depends on the
591 current value of the outport field. Suppose outport designates a logi‐
592 cal port. First, OVN compares inport to outport; if they are equal, it
593 treats the output as a no-op by default. In the common case, where they
594 are different, the packet enters the egress pipeline. This transition
595 to the egress pipeline discards register data, e.g. reg0 ... reg9 and
596 connection tracking state, to achieve uniform behavior regardless of
597 whether the egress pipeline is on a different hypervisor (because reg‐
598 isters aren’t preserve across tunnel encapsulation).
599 To execute the egress pipeline, OVN again searches the Logical_Flow ta‐
601 ble for a row with correct logical_datapath or a logical_dp_group, a
602 table_id of 0, a match that is true for the packet, but now looking for
603 a pipeline of egress. If no matching row is found, the output becomes a
604 no-op. Otherwise, OVN executes the actions for the matching flow (which
605 is chosen from multiple, if necessary, as already described).
606 In the egress pipeline, the next action acts as already described, ex‐
608 cept that it, of course, searches for egress flows. The output action,
609 however, now directly outputs the packet to the output port (which is
610 now fixed, because outport is read-only within the egress pipeline).
611 The description earlier assumed that outport referred to a logical
613 port. If it instead designates a logical multicast group, then the de‐
614 scription above still applies, with the addition of fan-out from the
615 logical multicast group to each logical port in the group. For each
616 member of the group, OVN executes the logical pipeline as described,
617 with the logical output port replaced by the group member.
618 Pipeline Stages
620 ovn-northd populates the Logical_Flow table with the logical flows de‐
622 scribed in detail in ovn-northd(8).
623 Summary:
625 logical_datapath optional Datapath_Binding
626 logical_dp_group optional Logical_DP_Group
627 pipeline string, either egress or ingress
628 table_id integer, in range 0 to 32
629 priority integer, in range 0 to 65,535
630 match string
631 actions string
632 external_ids : stage-name optional string
633 external_ids : stage-hint optional string, containing an uuid
634 external_ids : source optional string
635 Common Columns:
636 external_ids map of string-string pairs
637 Details:
639 logical_datapath: optional Datapath_Binding
640 The logical datapath to which the logical flow belongs.
641 logical_dp_group: optional Logical_DP_Group
643 The group of logical datapaths to which the logical flow be‐
644 longs. This means that the same logical flow belongs to all
645 datapaths in a group.
646 pipeline: string, either egress or ingress
648 The primary flows used for deciding on a packet’s destination
649 are the ingress flows. The egress flows implement ACLs. See Log‐
650 ical Life Cycle of a Packet, above, for details.
651 table_id: integer, in range 0 to 32
653 The stage in the logical pipeline, analogous to an OpenFlow ta‐
654 ble number.
655 priority: integer, in range 0 to 65,535
657 The flow’s priority. Flows with numerically higher priority take
658 precedence over those with lower. If two logical datapath flows
659 with the same priority both match, then the one actually applied
660 to the packet is undefined.
661 match: string
663 A matching expression. OVN provides a superset of OpenFlow
664 matching capabilities, using a syntax similar to Boolean expres‐
665 sions in a programming language.
666 The most important components of match expression are compar‐
668 isons between symbols and constants, e.g. ip4.dst ==
669 192.168.0.1, ip.proto == 6, arp.op == 1, eth.type == 0x800. The
670 logical AND operator && and logical OR operator || can combine
671 comparisons into a larger expression.
672 Matching expressions also support parentheses for grouping, the
674 logical NOT prefix operator !, and literals 0 and 1 to express
675 ``false’’ or ``true,’’ respectively. The latter is useful by it‐
676 self as a catch-all expression that matches every packet.
677 Match expressions also support a kind of function syntax. The
679 following functions are supported:
680 is_chassis_resident(lport)
682 Evaluates to true on a chassis on which logical port
683 lport (a quoted string) resides, and to false elsewhere.
684 This function was introduced in OVN 2.7.
685 Symbols
687 Type. Symbols have integer or string type. Integer symbols have
689 a width in bits.
690 Kinds. There are three kinds of symbols:
692 • Fields. A field symbol represents a packet header or
694 metadata field. For example, a field named vlan.tci might
695 represent the VLAN TCI field in a packet.
696 A field symbol can have integer or string type. Integer
698 fields can be nominal or ordinal (see Level of Measure‐
699 ment, below).
700 • Subfields. A subfield represents a subset of bits from a
702 larger field. For example, a field vlan.vid might be de‐
703 fined as an alias for vlan.tci[0..11]. Subfields are pro‐
704 vided for syntactic convenience, because it is always
705 possible to instead refer to a subset of bits from a
706 field directly.
707 Only ordinal fields (see Level of Measurement, below) may
709 have subfields. Subfields are always ordinal.
710 • Predicates. A predicate is shorthand for a Boolean ex‐
712 pression. Predicates may be used much like 1-bit fields.
713 For example, ip4 might expand to eth.type == 0x800. Pred‐
714 icates are provided for syntactic convenience, because it
715 is always possible to instead specify the underlying ex‐
716 pression directly.
717 A predicate whose expansion refers to any nominal field
719 or predicate (see Level of Measurement, below) is nomi‐
720 nal; other predicates have Boolean level of measurement.
721 Level of Measurement. See
723 http://en.wikipedia.org/wiki/Level_of_measurement for the sta‐
724 tistical concept on which this classification is based. There
725 are three levels:
726 • Ordinal. In statistics, ordinal values can be ordered on
728 a scale. OVN considers a field (or subfield) to be ordi‐
729 nal if its bits can be examined individually. This is
730 true for the OpenFlow fields that OpenFlow or Open
731 vSwitch makes ``maskable.’’
732 Any use of a ordinal field may specify a single bit or a
734 range of bits, e.g. vlan.tci[13..15] refers to the PCP
735 field within the VLAN TCI, and eth.dst[40] refers to the
736 multicast bit in the Ethernet destination address.
737 OVN supports all the usual arithmetic relations (==, !=,
739 <, <=, >, and >=) on ordinal fields and their subfields,
740 because OVN can implement these in OpenFlow and Open
741 vSwitch as collections of bitwise tests.
742 • Nominal. In statistics, nominal values cannot be usefully
744 compared except for equality. This is true of OpenFlow
745 port numbers, Ethernet types, and IP protocols are exam‐
746 ples: all of these are just identifiers assigned arbi‐
747 trarily with no deeper meaning. In OpenFlow and Open
748 vSwitch, bits in these fields generally aren’t individu‐
749 ally addressable.
750 OVN only supports arithmetic tests for equality on nomi‐
752 nal fields, because OpenFlow and Open vSwitch provide no
753 way for a flow to efficiently implement other comparisons
754 on them. (A test for inequality can be sort of built out
755 of two flows with different priorities, but OVN matching
756 expressions always generate flows with a single prior‐
757 ity.)
758 String fields are always nominal.
760 • Boolean. A nominal field that has only two values, 0 and
762 1, is somewhat exceptional, since it is easy to support
763 both equality and inequality tests on such a field: ei‐
764 ther one can be implemented as a test for 0 or 1.
765 Only predicates (see above) have a Boolean level of mea‐
767 surement.
768 This isn’t a standard level of measurement.
770 Prerequisites. Any symbol can have prerequisites, which are ad‐
772 ditional condition implied by the use of the symbol. For exam‐
773 ple, For example, icmp4.type symbol might have prerequisite
774 icmp4, which would cause an expression icmp4.type == 0 to be in‐
775 terpreted as icmp4.type == 0 && icmp4, which would in turn ex‐
776 pand to icmp4.type == 0 && eth.type == 0x800 && ip4.proto == 1
777 (assuming icmp4 is a predicate defined as suggested under Types
778 above).
779 Relational operators
781 All of the standard relational operators ==, !=, <, <=, >, and
783 >= are supported. Nominal fields support only == and !=, and
784 only in a positive sense when outer ! are taken into account,
785 e.g. given string field inport, inport == "eth0" and !(inport !=
786 "eth0") are acceptable, but not inport != "eth0".
787 The implementation of == (or != when it is negated), is more ef‐
789 ficient than that of the other relational operators.
790 Constants
792 Integer constants may be expressed in decimal, hexadecimal pre‐
794 fixed by 0x, or as dotted-quad IPv4 addresses, IPv6 addresses in
795 their standard forms, or Ethernet addresses as colon-separated
796 hex digits. A constant in any of these forms may be followed by
797 a slash and a second constant (the mask) in the same form, to
798 form a masked constant. IPv4 and IPv6 masks may be given as in‐
799 tegers, to express CIDR prefixes.
800 String constants have the same syntax as quoted strings in JSON
802 (thus, they are Unicode strings).
803 Some operators support sets of constants written inside curly
805 braces { ... }. Commas between elements of a set, and after the
806 last elements, are optional. With ==, ``field == { constant1,
807 constant2, ... }’’ is syntactic sugar for ``field == constant1
808 || field == constant2 || .... Similarly, ``field != { constant1,
809 constant2, ... }’’ is equivalent to ``field != constant1 &&
810 field != constant2 && ...’’.
811 You may refer to a set of IPv4, IPv6, or MAC addresses stored in
813 the Address_Set table by its name. An Address_Set with a name of
814 set1 can be referred to as $set1.
815 You may refer to a group of logical switch ports stored in the
817 Port_Group table by its name. An Port_Group with a name of
818 port_group1 can be referred to as @port_group1.
819 Additionally, you may refer to the set of addresses belonging to
821 a group of logical switch ports stored in the Port_Group table
822 by its name followed by a suffix ’_ip4’/’_ip6’. The IPv4 address
823 set of a Port_Group with a name of port_group1 can be referred
824 to as $port_group1_ip4, and the IPv6 address set of the same
825 Port_Group can be referred to as $port_group1_ip6
826 Miscellaneous
828 Comparisons may name the symbol or the constant first, e.g.
830 tcp.src == 80 and 80 == tcp.src are both acceptable.
831 Tests for a range may be expressed using a syntax like 1024 <=
833 tcp.src <= 49151, which is equivalent to 1024 <= tcp.src &&
834 tcp.src <= 49151.
835 For a one-bit field or predicate, a mention of its name is
837 equivalent to symobl == 1, e.g. vlan.present is equivalent to
838 vlan.present == 1. The same is true for one-bit subfields, e.g.
839 vlan.tci[12]. There is no technical limitation to implementing
840 the same for ordinal fields of all widths, but the implementa‐
841 tion is expensive enough that the syntax parser requires writing
842 an explicit comparison against zero to make mistakes less
843 likely, e.g. in tcp.src != 0 the comparison against 0 is re‐
844 quired.
845 Operator precedence is as shown below, from highest to lowest.
847 There are two exceptions where parentheses are required even
848 though the table would suggest that they are not: && and || re‐
849 quire parentheses when used together, and ! requires parentheses
850 when applied to a relational expression. Thus, in (eth.type ==
851 0x800 || eth.type == 0x86dd) && ip.proto == 6 or !(arp.op == 1),
852 the parentheses are mandatory.
853 • ()
855 • == != < <= > >=
857 • !
859 • && ||
861 Comments may be introduced by //, which extends to the next new-
863 line. Comments within a line may be bracketed by /* and */. Mul‐
864 tiline comments are not supported.
865 Symbols
867 Most of the symbols below have integer type. Only inport and
869 outport have string type. inport names a logical port. Thus, its
870 value is a logical_port name from the Port_Binding table. out‐
871 port may name a logical port, as inport, or a logical multicast
872 group defined in the Multicast_Group table. For both symbols,
873 only names within the flow’s logical datapath may be used.
874 The regX symbols are 32-bit integers. The xxregX symbols are
876 128-bit integers, which overlay four of the 32-bit registers:
877 xxreg0 overlays reg0 through reg3, with reg0 supplying the most-
878 significant bits of xxreg0 and reg3 the least-signficant. xxreg1
879 similarly overlays reg4 through reg7.
880 • reg0...reg9
882 • xxreg0 xxreg1
884 • inport outport
886 • flags.loopback
888 • pkt.mark
890 • eth.src eth.dst eth.type
892 • vlan.tci vlan.vid vlan.pcp vlan.present
894 • ip.proto ip.dscp ip.ecn ip.ttl ip.frag
896 • ip4.src ip4.dst
898 • ip6.src ip6.dst ip6.label
900 • arp.op arp.spa arp.tpa arp.sha arp.tha
902 • tcp.src tcp.dst tcp.flags
904 • udp.src udp.dst
906 • sctp.src sctp.dst
908 • icmp4.type icmp4.code
910 • icmp6.type icmp6.code
912 • nd.target nd.sll nd.tll
914 • ct_mark ct_label
916 • ct_state, which has several Boolean subfields. The
918 ct_next action initializes the following subfields:
919 • ct.trk: Always set to true by ct_next to indicate
921 that connection tracking has taken place. All
922 other ct subfields have ct.trk as a prerequisite.
923 • ct.new: True for a new flow
925 • ct.est: True for an established flow
927 • ct.rel: True for a related flow
929 • ct.rpl: True for a reply flow
931 • ct.inv: True for a connection entry in a bad state
933 The ct_dnat, ct_snat, and ct_lb actions initialize the
935 following subfields:
936 • ct.dnat: True for a packet whose destination IP
938 address has been changed.
939 • ct.snat: True for a packet whose source IP address
941 has been changed.
942 The following predicates are supported:
944 • eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff
946 • eth.mcast expands to eth.dst[40]
948 • vlan.present expands to vlan.tci[12]
950 • ip4 expands to eth.type == 0x800
952 • ip4.src_mcast expands to ip4.src[28..31] == 0xe
954 • ip4.mcast expands to ip4.dst[28..31] == 0xe
956 • ip6 expands to eth.type == 0x86dd
958 • ip expands to ip4 || ip6
960 • icmp4 expands to ip4 && ip.proto == 1
962 • icmp6 expands to ip6 && ip.proto == 58
964 • icmp expands to icmp4 || icmp6
966 • ip.is_frag expands to ip.frag[0]
968 • ip.later_frag expands to ip.frag[1]
970 • ip.first_frag expands to ip.is_frag && !ip.later_frag
972 • arp expands to eth.type == 0x806
974 • nd expands to icmp6.type == {135, 136} && icmp6.code == 0
976 && ip.ttl == 255
977 • nd_ns expands to icmp6.type == 135 && icmp6.code == 0 &&
979 ip.ttl == 255
980 • nd_na expands to icmp6.type == 136 && icmp6.code == 0 &&
982 ip.ttl == 255
983 • nd_rs expands to icmp6.type == 133 && icmp6.code == 0 &&
985 ip.ttl == 255
986 • nd_ra expands to icmp6.type == 134 && icmp6.code == 0 &&
988 ip.ttl == 255
989 • tcp expands to ip.proto == 6
991 • udp expands to ip.proto == 17
993 • sctp expands to ip.proto == 132
995 actions: string
997 Logical datapath actions, to be executed when the logical flow
998 represented by this row is the highest-priority match.
999 Actions share lexical syntax with the match column. An empty set
1001 of actions (or one that contains just white space or comments),
1002 or a set of actions that consists of just drop;, causes the
1003 matched packets to be dropped. Otherwise, the column should con‐
1004 tain a sequence of actions, each terminated by a semicolon.
1005 The following actions are defined:
1007 output;
1009 In the ingress pipeline, this action executes the egress
1010 pipeline as a subroutine. If outport names a logical
1011 port, the egress pipeline executes once; if it is a mul‐
1012 ticast group, the egress pipeline runs once for each log‐
1013 ical port in the group.
1014 In the egress pipeline, this action performs the actual
1016 output to the outport logical port. (In the egress pipe‐
1017 line, outport never names a multicast group.)
1018 By default, output to the input port is implicitly
1020 dropped, that is, output becomes a no-op if outport ==
1021 inport. Occasionally it may be useful to override this
1022 behavior, e.g. to send an ARP reply to an ARP request; to
1023 do so, use flags.loopback = 1 to allow the packet to
1024 "hair-pin" back to the input port.
1025 next;
1027 next(table);
1028 next(pipeline=pipeline, table=table);
1029 Executes the given logical datapath table in pipeline as a
1030 subroutine. The default table is just after the current
1031 one. If pipeline is specified, it may be ingress or egress;
1032 the default pipeline is the one currently executing. Ac‐
1033 tions in the both ingress and egress pipeline can use next
1034 to jump across the other pipeline. Actions in the ingress
1035 pipeline should use next to jump into the specific table of
1036 egress pipeline only if it is certain that the packets are
1037 local and not tunnelled and wants to skip certain stages in
1038 the packet processing.
1039 field = constant;
1041 Sets data or metadata field field to constant value con‐
1042 stant, e.g. outport = "vif0"; to set the logical output
1043 port. To set only a subset of bits in a field, specify a
1044 subfield for field or a masked constant, e.g. one may use
1045 vlan.pcp[2] = 1; or vlan.pcp = 4/4; to set the most sigifi‐
1046 cant bit of the VLAN PCP.
1047 Assigning to a field with prerequisites implicitly adds
1049 those prerequisites to match; thus, for example, a flow
1050 that sets tcp.dst applies only to TCP flows, regardless of
1051 whether its match mentions any TCP field.
1052 Not all fields are modifiable (e.g. eth.type and ip.proto
1054 are read-only), and not all modifiable fields may be par‐
1055 tially modified (e.g. ip.ttl must assigned as a whole). The
1056 outport field is modifiable in the ingress pipeline but not
1057 in the egress pipeline.
1058 ovn_field = constant;
1060 Sets OVN field ovn_field to constant value constant.
1061 OVN supports setting the values of certain fields which are
1063 not yet supported in OpenFlow to set or modify them.
1064 Below are the supported OVN fields:
1066 • icmp4.frag_mtu icmp6.frag_mtu
1068 This field sets the low-order 16 bits of the
1070 ICMP{4,6} header field that is labelled "unused" in
1071 the ICMP specification as defined in the RFC 1191
1072 with the value specified in constant.
1073 Eg. icmp4.frag_mtu = 1500;
1075 field1 = field2;
1077 Sets data or metadata field field1 to the value of data or
1078 metadata field field2, e.g. reg0 = ip4.src; copies ip4.src
1079 into reg0. To modify only a subset of a field’s bits, spec‐
1080 ify a subfield for field1 or field2 or both, e.g. vlan.pcp
1081 = reg0[0..2]; copies the least-significant bits of reg0
1082 into the VLAN PCP.
1083 field1 and field2 must be the same type, either both string
1085 or both integer fields. If they are both integer fields,
1086 they must have the same width.
1087 If field1 or field2 has prerequisites, they are added im‐
1089 plicitly to match. It is possible to write an assignment
1090 with contradictory prerequisites, such as ip4.src =
1091 ip6.src[0..31];, but the contradiction means that a logical
1092 flow with such an assignment will never be matched.
1093 field1 <-> field2;
1095 Similar to field1 = field2; except that the two values are
1096 exchanged instead of copied. Both field1 and field2 must
1097 modifiable.
1098 ip.ttl--;
1100 Decrements the IPv4 or IPv6 TTL. If this would make the TTL
1101 zero or negative, then processing of the packet halts; no
1102 further actions are processed. (To properly handle such
1103 cases, a higher-priority flow should match on ip.ttl == {0,
1104 1};.)
1105 Prerequisite: ip
1107 ct_next;
1109 Apply connection tracking to the flow, initializing
1110 ct_state for matching in later tables. Automatically moves
1111 on to the next table, as if followed by next.
1112 As a side effect, IP fragments will be reassembled for
1114 matching. If a fragmented packet is output, then it will be
1115 sent with any overlapping fragments squashed. The connec‐
1116 tion tracking state is scoped by the logical port when the
1117 action is used in a flow for a logical switch, so overlap‐
1118 ping addresses may be used. To allow traffic related to the
1119 matched flow, execute ct_commit . Connection tracking state
1120 is scoped by the logical topology when the action is used
1121 in a flow for a router.
1122 It is possible to have actions follow ct_next, but they
1124 will not have access to any of its side-effects and is not
1125 generally useful.
1126 ct_commit { };
1128 ct_commit { ct_mark=value[/mask]; };
1129 ct_commit { ct_label=value[/mask]; };
1130 ct_commit { ct_mark=value[/mask]; ct_label=value[/mask]; };
1131 Commit the flow to the connection tracking entry associated
1132 with it by a previous call to ct_next. When
1133 ct_mark=value[/mask] and/or ct_label=value[/mask] are sup‐
1134 plied, ct_mark and/or ct_label will be set to the values
1135 indicated by value[/mask] on the connection tracking entry.
1136 ct_mark is a 32-bit field. ct_label is a 128-bit field. The
1137 value[/mask] should be specified in hex string if more than
1138 64bits are to be used. Registers and other named fields can
1139 be used for value. ct_mark and ct_label may be sub-ad‐
1140 dressed in order to have specific bits set.
1141 Note that if you want processing to continue in the next
1143 table, you must execute the next action after ct_commit.
1144 You may also leave out next which will commit connection
1145 tracking state, and then drop the packet. This could be
1146 useful for setting ct_mark on a connection tracking entry
1147 before dropping a packet, for example.
1148 ct_dnat;
1150 ct_dnat(IP);
1151 ct_dnat sends the packet through the DNAT zone in connec‐
1152 tion tracking table to unDNAT any packet that was DNATed in
1153 the opposite direction. The packet is then automatically
1154 sent to to the next tables as if followed by next; action.
1155 The next tables will see the changes in the packet caused
1156 by the connection tracker.
1157 ct_dnat(IP) sends the packet through the DNAT zone to
1159 change the destination IP address of the packet to the one
1160 provided inside the parentheses and commits the connection.
1161 The packet is then automatically sent to the next tables as
1162 if followed by next; action. The next tables will see the
1163 changes in the packet caused by the connection tracker.
1164 ct_snat;
1166 ct_snat(IP);
1167 ct_snat sends the packet through the SNAT zone to unSNAT
1168 any packet that was SNATed in the opposite direction. The
1169 packet is automatically sent to the next tables as if fol‐
1170 lowed by the next; action. The next tables will see the
1171 changes in the packet caused by the connection tracker.
1172 ct_snat(IP) sends the packet through the SNAT zone to
1174 change the source IP address of the packet to the one pro‐
1175 vided inside the parenthesis and commits the connection.
1176 The packet is then automatically sent to the next tables as
1177 if followed by next; action. The next tables will see the
1178 changes in the packet caused by the connection tracker.
1179 ct_clear;
1181 Clears connection tracking state.
1182 clone { action; ... };
1184 Makes a copy of the packet being processed and executes
1185 each action on the copy. Actions following the clone ac‐
1186 tion, if any, apply to the original, unmodified packet.
1187 This can be used as a way to ``save and restore’’ the
1188 packet around a set of actions that may modify it and
1189 should not persist.
1190 arp { action; ... };
1192 Temporarily replaces the IPv4 packet being processed by an
1193 ARP packet and executes each nested action on the ARP
1194 packet. Actions following the arp action, if any, apply to
1195 the original, unmodified packet.
1196 The ARP packet that this action operates on is initialized
1198 based on the IPv4 packet being processed, as follows. These
1199 are default values that the nested actions will probably
1200 want to change:
1201 • eth.src unchanged
1203 • eth.dst unchanged
1205 • eth.type = 0x0806
1207 • arp.op = 1 (ARP request)
1209 • arp.sha copied from eth.src
1211 • arp.spa copied from ip4.src
1213 • arp.tha = 00:00:00:00:00:00
1215 • arp.tpa copied from ip4.dst
1217 The ARP packet has the same VLAN header, if any, as the IP
1219 packet it replaces.
1220 Prerequisite: ip4
1222 get_arp(P, A);
1224 Parameters: logical port string field P, 32-bit IP address
1225 field A.
1226 Looks up A in P’s mac binding table. If an entry is found,
1228 stores its Ethernet address in eth.dst, otherwise stores
1229 00:00:00:00:00:00 in eth.dst.
1230 Example: get_arp(outport, ip4.dst);
1232 put_arp(P, A, E);
1234 Parameters: logical port string field P, 32-bit IP address
1235 field A, 48-bit Ethernet address field E.
1236 Adds or updates the entry for IP address A in logical port
1238 P’s mac binding table, setting its Ethernet address to E.
1239 Example: put_arp(inport, arp.spa, arp.sha);
1241 R = lookup_arp(P, A, M);
1243 Parameters: logical port string field P, 32-bit IP address
1244 field A, 48-bit MAC address field M.
1245 Result: stored to a 1-bit subfield R.
1247 Looks up A and M in P’s mac binding table. If an entry is
1249 found, stores 1 in the 1-bit subfield R, else 0.
1250 Example: reg0[0] = lookup_arp(inport, arp.spa, arp.sha);
1252 R = lookup_arp_ip(P, A);
1254 Parameters: logical port string field P, 32-bit IP address
1255 field A.
1256 Result: stored to a 1-bit subfield R.
1258 Looks up A in P’s mac binding table. If an entry is found,
1260 stores 1 in the 1-bit subfield R, else 0.
1261 Example: reg0[0] = lookup_arp_ip(inport, arp.spa);
1263 P = get_fdb(A);
1265 Parameters:48-bit MAC address field A.
1266 Looks up A in fdb table. If an entry is found, stores the
1268 logical port key to the out parameter P.
1269 Example: outport = get_fdb(eth.src);
1271 put_fdb(P, A);
1273 Parameters: logical port string field P, 48-bit MAC address
1274 field A.
1275 Adds or updates the entry for Ethernet address A in fdb ta‐
1277 ble, setting its logical port key to P.
1278 Example: put_fdb(inport, arp.spa);
1280 R = lookup_fdb(P, A);
1282 Parameters: 48-bit MAC address field M, logical port string
1283 field P.
1284 Result: stored to a 1-bit subfield R.
1286 Looks up A in fdb table. If an entry is found and the the
1288 logical port key is P, P, stores 1 in the 1-bit subfield R,
1289 else 0.
1290 Example: reg0[0] = lookup_fdb(inport, eth.src);
1292 nd_ns { action; ... };
1294 Temporarily replaces the IPv6 packet being processed by an
1295 IPv6 Neighbor Solicitation packet and executes each nested
1296 action on the IPv6 NS packet. Actions following the nd_ns
1297 action, if any, apply to the original, unmodified packet.
1298 The IPv6 NS packet that this action operates on is initial‐
1300 ized based on the IPv6 packet being processed, as follows.
1301 These are default values that the nested actions will prob‐
1302 ably want to change:
1303 • eth.src unchanged
1305 • eth.dst set to IPv6 multicast MAC address
1307 • eth.type = 0x86dd
1309 • ip6.src copied from ip6.src
1311 • ip6.dst set to IPv6 Solicited-Node multicast address
1313 • icmp6.type = 135 (Neighbor Solicitation)
1315 • nd.target copied from ip6.dst
1317 The IPv6 NS packet has the same VLAN header, if any, as the
1319 IP packet it replaces.
1320 Prerequisite: ip6
1322 nd_na { action; ... };
1324 Temporarily replaces the IPv6 neighbor solicitation packet
1325 being processed by an IPv6 neighbor advertisement (NA)
1326 packet and executes each nested action on the NA packet.
1327 Actions following the nd_na action, if any, apply to the
1328 original, unmodified packet.
1329 The NA packet that this action operates on is initialized
1331 based on the IPv6 packet being processed, as follows. These
1332 are default values that the nested actions will probably
1333 want to change:
1334 • eth.dst exchanged with eth.src
1336 • eth.type = 0x86dd
1338 • ip6.dst copied from ip6.src
1340 • ip6.src copied from nd.target
1342 • icmp6.type = 136 (Neighbor Advertisement)
1344 • nd.target unchanged
1346 • nd.sll = 00:00:00:00:00:00
1348 • nd.tll copied from eth.dst
1350 The ND packet has the same VLAN header, if any, as the IPv6
1352 packet it replaces.
1353 Prerequisite: nd_ns
1355 nd_na_router { action; ... };
1357 Temporarily replaces the IPv6 neighbor solicitation packet
1358 being processed by an IPv6 neighbor advertisement (NA)
1359 packet, sets ND_NSO_ROUTER in the RSO flags and executes
1360 each nested action on the NA packet. Actions following the
1361 nd_na_router action, if any, apply to the original, unmodi‐
1362 fied packet.
1363 The NA packet that this action operates on is initialized
1365 based on the IPv6 packet being processed, as follows. These
1366 are default values that the nested actions will probably
1367 want to change:
1368 • eth.dst exchanged with eth.src
1370 • eth.type = 0x86dd
1372 • ip6.dst copied from ip6.src
1374 • ip6.src copied from nd.target
1376 • icmp6.type = 136 (Neighbor Advertisement)
1378 • nd.target unchanged
1380 • nd.sll = 00:00:00:00:00:00
1382 • nd.tll copied from eth.dst
1384 The ND packet has the same VLAN header, if any, as the IPv6
1386 packet it replaces.
1387 Prerequisite: nd_ns
1389 get_nd(P, A);
1391 Parameters: logical port string field P, 128-bit IPv6 ad‐
1392 dress field A.
1393 Looks up A in P’s mac binding table. If an entry is found,
1395 stores its Ethernet address in eth.dst, otherwise stores
1396 00:00:00:00:00:00 in eth.dst.
1397 Example: get_nd(outport, ip6.dst);
1399 put_nd(P, A, E);
1401 Parameters: logical port string field P, 128-bit IPv6 ad‐
1402 dress field A, 48-bit Ethernet address field E.
1403 Adds or updates the entry for IPv6 address A in logical
1405 port P’s mac binding table, setting its Ethernet address to
1406 E.
1407 Example: put_nd(inport, nd.target, nd.tll);
1409 R = lookup_nd(P, A, M);
1411 Parameters: logical port string field P, 128-bit IP address
1412 field A, 48-bit MAC address field M.
1413 Result: stored to a 1-bit subfield R.
1415 Looks up A and M in P’s mac binding table. If an entry is
1417 found, stores 1 in the 1-bit subfield R, else 0.
1418 Example: reg0[0] = lookup_nd(inport, ip6.src, eth.src);
1420 R = lookup_nd_ip(P, A);
1422 Parameters: logical port string field P, 128-bit IP address
1423 field A.
1424 Result: stored to a 1-bit subfield R.
1426 Looks up A in P’s mac binding table. If an entry is found,
1428 stores 1 in the 1-bit subfield R, else 0.
1429 Example: reg0[0] = lookup_nd_ip(inport, ip6.src);
1431 R = put_dhcp_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1433 Parameters: one or more DHCP option/value pairs, which must
1434 include an offerip option (with code 0).
1435 Result: stored to a 1-bit subfield R.
1437 Valid only in the ingress pipeline.
1439 When this action is applied to a DHCP request packet
1441 (DHCPDISCOVER or DHCPREQUEST), it changes the packet into a
1442 DHCP reply (DHCPOFFER or DHCPACK, respectively), replaces
1443 the options by those specified as parameters, and stores 1
1444 in R.
1445 When this action is applied to a non-DHCP packet or a DHCP
1447 packet that is not DHCPDISCOVER or DHCPREQUEST, it leaves
1448 the packet unchanged and stores 0 in R.
1449 The contents of the DHCP_Option table control the DHCP op‐
1451 tion names and values that this action supports.
1452 Example: reg0[0] = put_dhcp_opts(offerip = 10.0.0.2, router
1454 = 10.0.0.1, netmask = 255.255.255.0, dns_server = {8.8.8.8,
1455 7.7.7.7});
1456 R = put_dhcpv6_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1458 Parameters: one or more DHCPv6 option/value pairs.
1459 Result: stored to a 1-bit subfield R.
1461 Valid only in the ingress pipeline.
1463 When this action is applied to a DHCPv6 request packet, it
1465 changes the packet into a DHCPv6 reply, replaces the op‐
1466 tions by those specified as parameters, and stores 1 in R.
1467 When this action is applied to a non-DHCPv6 packet or an
1469 invalid DHCPv6 request packet , it leaves the packet un‐
1470 changed and stores 0 in R.
1471 The contents of the DHCPv6_Options table control the DHCPv6
1473 option names and values that this action supports.
1474 Example: reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4,
1476 server_id = 00:00:00:00:10:02,
1477 dns_server={ae70::1,ae70::2});
1478 set_queue(queue_number);
1480 Parameters: Queue number queue_number, in the range 0 to
1481 61440.
1482 This is a logical equivalent of the OpenFlow set_queue ac‐
1484 tion. It affects packets that egress a hypervisor through a
1485 physical interface. For nonzero queue_number, it configures
1486 packet queuing to match the settings configured for the
1487 Port_Binding with options:qdisc_queue_id matching
1488 queue_number. When queue_number is zero, it resets queuing
1489 to the default strategy.
1490 Example: set_queue(10);
1492 ct_lb;
1494 ct_lb(ip[:port]...);
1495 With one or more arguments, ct_lb commits the packet to the
1496 connection tracking table and DNATs the packet’s destina‐
1497 tion IP address (and port) to the IP address or addresses
1498 (and optional ports) specified in the string. If multiple
1499 comma-separated IP addresses are specified, each is given
1500 equal weight for picking the DNAT address. Processing auto‐
1501 matically moves on to the next table, as if next; were
1502 specified, and later tables act on the packet as modified
1503 by the connection tracker. Connection tracking state is
1504 scoped by the logical port when the action is used in a
1505 flow for a logical switch, so overlapping addresses may be
1506 used. Connection tracking state is scoped by the logical
1507 topology when the action is used in a flow for a router.
1508 Without arguments, ct_lb sends the packet to the connection
1510 tracking table to NAT the packets. If the packet is part of
1511 an established connection that was previously committed to
1512 the connection tracker via ct_lb(...), it will automati‐
1513 cally get DNATed to the same IP address as the first packet
1514 in that connection.
1515 R = dns_lookup();
1517 Parameters: No parameters.
1518 Result: stored to a 1-bit subfield R.
1520 Valid only in the ingress pipeline.
1522 When this action is applied to a valid DNS request (a UDP
1524 packet typically directed to port 53), it attempts to re‐
1525 solve the query using the contents of the DNS table. If it
1526 is successful, it changes the packet into a DNS reply and
1527 stores 1 in R. If the action is applied to a non-DNS
1528 packet, an invalid DNS request packet, or a valid DNS re‐
1529 quest for which the DNS table does not supply an answer, it
1530 leaves the packet unchanged and stores 0 in R.
1531 Regardless of success, the action does not make any of the
1533 changes to the flow that are necessary to direct the packet
1534 back to the requester. The logical pipeline can implement
1535 this behavior with matches and actions in later tables.
1536 Example: reg0[3] = dns_lookup();
1538 Prerequisite: udp
1540 R = put_nd_ra_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1542 Parameters: The following IPv6 ND Router Advertisement op‐
1543 tion/value pairs as defined in RFC 4861.
1544 • addr_mode
1546 Mandatory parameter which specifies the address mode
1548 flag to be set in the RA flag options field. The
1549 value of this option is a string and the following
1550 values can be defined - "slaac", "dhcpv6_stateful"
1551 and "dhcpv6_stateless".
1552 • slla
1554 Mandatory parameter which specifies the link-layer
1556 address of the interface from which the Router Ad‐
1557 vertisement is sent.
1558 • mtu
1560 Optional parameter which specifies the MTU.
1562 • prefix
1564 Optional parameter which should be specified if the
1566 addr_mode is "slaac" or "dhcpv6_stateless". The
1567 value should be an IPv6 prefix which will be used
1568 for stateless IPv6 address configuration. This op‐
1569 tion can be defined multiple times.
1570 Result: stored to a 1-bit subfield R.
1572 Valid only in the ingress pipeline.
1574 When this action is applied to an IPv6 Router solicitation
1576 request packet, it changes the packet into an IPv6 Router
1577 Advertisement reply and adds the options specified in the
1578 parameters, and stores 1 in R.
1579 When this action is applied to a non-IPv6 Router solicita‐
1581 tion packet or an invalid IPv6 request packet , it leaves
1582 the packet unchanged and stores 0 in R.
1583 Example: reg0[3] = put_nd_ra_opts(addr_mode = "slaac", slla
1585 = 00:00:00:00:10:02, prefix = aef0::/64, mtu = 1450);
1586 set_meter(rate);
1588 set_meter(rate, burst);
1589 Parameters: rate limit int field rate in kbps, burst rate
1590 limits int field burst in kbps.
1591 This action sets the rate limit for a flow.
1593 Example: set_meter(100, 1000);
1595 R = check_pkt_larger(L)
1597 Parameters: packet length L to check for in bytes.
1598 Result: stored to a 1-bit subfield R.
1600 This is a logical equivalent of the OpenFlow
1602 check_pkt_larger action. If the packet is larger than the
1603 length specified in L, it stores 1 in the subfield R.
1604 Example: reg0[6] = check_pkt_larger(1000);
1606 log(key=value, ...);
1608 Causes ovn-controller to log the packet on the chassis
1609 that processes it. Packet logging currently uses the same
1610 logging mechanism as other Open vSwitch and OVN messages,
1611 which means that whether and where log messages appear
1612 depends on the local logging configuration that can be
1613 configured with ovs-appctl, etc.
1614 The log action takes zero or more of the following key-
1616 value pair arguments that control what is logged:
1617 name=string
1619 An optional name for the ACL. The string is cur‐
1620 rently limited to 64 bytes.
1621 severity=level
1623 Indicates the severity of the event. The level is
1624 one of following (from more to less serious):
1625 alert, warning, notice, info, or debug. If a
1626 severity is not provided, the default is info.
1627 verdict=value
1629 The verdict for packets matching the flow. The
1630 value must be one of allow, deny, or reject.
1631 meter=string
1633 An optional rate-limiting meter to be applied to
1634 the logs. The string should reference a name entry
1635 from the Meter table. The only meter action that
1636 is appropriate is drop.
1637 fwd_group(liveness=bool, childports=port, ...);
1639 Parameters: optional liveness, either true or false, de‐
1640 faulting to false; childports, a comma-delimited list of
1641 strings denoting logical ports to load balance across.
1642 Load balance traffic to one or more child ports in a log‐
1644 ical switch. ovn-controller translates the fwd_group into
1645 an OpenFlow group with one bucket for each child port. If
1646 liveness=true is specified, it also integrates the bucket
1647 selection with BFD status on the tunnel interface corre‐
1648 sponding to child port.
1649 Example: fwd_group(liveness=true, childports="p1", "p2");
1651 icmp4 { action; ... };
1653 icmp4_error { action; ... };
1654 Temporarily replaces the IPv4 packet being processed by an
1655 ICMPv4 packet and executes each nested action on the ICMPv4
1656 packet. Actions following these actions, if any, apply to
1657 the original, unmodified packet.
1658 The ICMPv4 packet that these actions operates on is ini‐
1660 tialized based on the IPv4 packet being processed, as fol‐
1661 lows. These are default values that the nested actions will
1662 probably want to change. Ethernet and IPv4 fields not
1663 listed here are not changed:
1664 • ip.proto = 1 (ICMPv4)
1666 • ip.frag = 0 (not a fragment)
1668 • ip.ttl = 255
1670 • icmp4.type = 3 (destination unreachable)
1672 • icmp4.code = 1 (host unreachable)
1674 icmp4_error action is expected to be used to generate an
1676 ICMPv4 packet in response to an error in original IP
1677 packet. When this action generates the ICMPv4 packet, it
1678 also copies the original IP datagram following the ICMPv4
1679 header as per RFC 1122: 3.2.2.
1680 Prerequisite: ip4
1682 icmp6 { action; ... };
1684 icmp6_error { action; ... };
1685 Temporarily replaces the IPv6 packet being processed by an
1686 ICMPv6 packet and executes each nested action on the ICMPv6
1687 packet. Actions following the icmp6 action, if any, apply
1688 to the original, unmodified packet.
1689 The ICMPv6 packet that this action operates on is initial‐
1691 ized based on the IPv6 packet being processed, as follows.
1692 These are default values that the nested actions will prob‐
1693 ably want to change. Ethernet and IPv6 fields not listed
1694 here are not changed:
1695 • ip.proto = 58 (ICMPv6)
1697 • ip.ttl = 255
1699 • icmp6.type = 1 (destination unreachable)
1701 • icmp6.code = 1 (administratively prohibited)
1703 icmp6_error action is expected to be used to generate an
1705 ICMPv6 packet in response to an error in original IPv6
1706 packet.
1707 Prerequisite: ip6
1709 tcp_reset;
1711 This action transforms the current TCP packet according to
1712 the following pseudocode:
1713 if (tcp.ack) {
1715 tcp.seq = tcp.ack;
1716 } else {
1717 tcp.ack = tcp.seq + length(tcp.payload);
1718 tcp.seq = 0;
1719 }
1720 tcp.flags = RST;
1721 Then, the action drops all TCP options and payload data,
1723 and updates the TCP checksum. IP ttl is set to 255.
1724 Prerequisite: tcp
1726 reject { action; ... };
1728 If the original packet is IPv4 or IPv6 TCP packet, it re‐
1729 places it with IPv4 or IPv6 TCP RST packet and executes the
1730 inner actions. Otherwise it replaces it with an ICMPv4 or
1731 ICMPv6 packet and executes the inner actions.
1732 The inner actions should not attempt to swap eth source
1734 with eth destination and IP source with IP destination as
1735 this action implicitly does that.
1736 trigger_event;
1738 This action is used to allow ovs-vswitchd to report CMS re‐
1739 lated events writing them in Controller_Event table. It is
1740 possible to associate a meter to a each event in order to
1741 not overload pinctrl thread under heavy load; each meter is
1742 identified though a defined naming convention. Supported
1743 events:
1744 • empty_lb_backends. This event is raised if a re‐
1746 ceived packet is destined for a load balancer VIP
1747 that has no configured backend destinations. For
1748 this event, the event info includes the load bal‐
1749 ancer VIP, the load balancer UUID, and the transport
1750 protocol. Associated meter: event-elb
1751 igmp;
1753 This action sends the packet to ovn-controller for multi‐
1754 cast snooping.
1755 Prerequisite: igmp
1757 bind_vport(V, P);
1759 Parameters: logical port string field V of type virtual,
1760 logical port string field P.
1761 Binds the virtual logical port V and sets the chassis col‐
1763 umn and virtual_parent of the table Port_Binding. vir‐
1764 tual_parent is set to P.
1765 handle_svc_check(P);
1767 Parameters: logical port string field P.
1768 Handles the service monitor reply received from the VIF of
1770 the logical port P. ovn-controller periodically sends out
1771 the service monitor packets for the services configured in
1772 the Service_Monitor table and this action updates the sta‐
1773 tus of those services.
1774 Example: handle_svc_check(inport);
1776 handle_dhcpv6_reply;
1778 Handle DHCPv6 prefix delegation advertisements/replies from
1779 a IPv6 delegation server. ovn-controller will add an entry
1780 ipv6_ra_pd_list in the options table for each prefix re‐
1781 ceived from the delegation server
1782 R = select(N1[=W1], N2[=W2], ...);
1784 Parameters: Integer N1, N2..., with optional weight W1, W2,
1785 ...
1786 Result: stored to a logical field or subfield R.
1788 Select from a list of integers N1, N2..., each within the
1790 range 0 ~ 65535, and store the selected one in the field R.
1791 There must be 2 or more integers listed, each with an op‐
1792 tional weight, which is an integer within the range 1 ~
1793 65535. If weight is not specified, it defaults to 100. The
1794 selection method is based on the 5-tuple hash of packet
1795 header.
1796 Processing automatically moves on to the next table, as if
1798 next; were specified. The select action must be put as the
1799 last action of the logical flow when there are multiple ac‐
1800 tions (actions put after select will not take effect).
1801 Example: reg8[16..31] = select(1=20, 2=30, 3=50);
1803 handle_dhcpv6_reply;
1805 This action is used to parse DHCPv6 replies from IPv6 Dele‐
1806 gation Router and managed IPv6 Prefix delegation state ma‐
1807 chine
1808 R = chk_lb_hairpin();
1810 This action checks if the packet under consideration was
1811 destined to a load balancer VIP and it is hairpinned, i.e.,
1812 after load balancing the destination IP matches the source
1813 IP. If it is so, then the 1-bit destination register R is
1814 set to 1.
1815 R = chk_lb_hairpin_reply();
1817 This action checks if the packet under consideration is
1818 from one of the backend IP of a load balancer VIP and the
1819 destination IP is the load balancer VIP. If it is so, then
1820 the 1-bit destination register R is set to 1.
1821 R = ct_snat_to_vip;
1823 This action sends the packet through the SNAT zone to
1824 change the source IP address of the packet to the load bal‐
1825 ancer VIP if the original destination IP was load balancer
1826 VIP and commits the connection. This action applies suc‐
1827 cessfully only for the hairpinned traffic i.e if the action
1828 chk_lb_hairpin returned success. This action doesn’t take
1829 any arguments and it determines the SNAT IP internally. The
1830 packet is not automatically sent to the next table. The
1831 caller has to execute the next; action explicitly after
1832 this action to advance the packet to the next stage.
1833 external_ids : stage-name: optional string
1835 Human-readable name for this flow’s stage in the pipeline.
1836 external_ids : stage-hint: optional string, containing an uuid
1838 UUID of a OVN_Northbound record that caused this logical flow to
1839 be created. Currently used only for attribute of logical flows
1840 to northbound ACL records.
1841 external_ids : source: optional string
1843 Source file and line number of the code that added this flow to
1844 the pipeline.
1845 Common Columns:
1847 The overall purpose of these columns is described under Common Columns
1849 at the beginning of this document.
1850 external_ids: map of string-string pairs
1852
1854 Each row in this table represents a group of logical datapaths refer‐
1855 enced by the logical_dp_group column in the Logical_Flow table.
1856 Summary:
1858 datapaths set of weak reference to Datapath_Bind‐
1859 ings
1860 Details:
1862 datapaths: set of weak reference to Datapath_Bindings
1863 List of Datapath_Binding entries.
1864
1866 The rows in this table define multicast groups of logical ports. Multi‐
1867 cast groups allow a single packet transmitted over a tunnel to a hyper‐
1868 visor to be delivered to multiple VMs on that hypervisor, which uses
1869 bandwidth more efficiently.
1870 Each row in this table defines a logical multicast group numbered tun‐
1872 nel_key within datapath, whose logical ports are listed in the ports
1873 column.
1874 Summary:
1876 datapath Datapath_Binding
1877 tunnel_key integer, in range 32,768 to 65,535
1878 name string
1879 ports set of 1 or more weak reference to
1880 Port_Bindings
1881 Details:
1883 datapath: Datapath_Binding
1884 The logical datapath in which the multicast group resides.
1885 tunnel_key: integer, in range 32,768 to 65,535
1887 The value used to designate this logical egress port in tunnel
1888 encapsulations. An index forces the key to be unique within the
1889 datapath. The unusual range ensures that multicast group IDs do
1890 not overlap with logical port IDs.
1891 name: string
1893 The logical multicast group’s name. An index forces the name to
1894 be unique within the datapath. Logical flows in the ingress
1895 pipeline may output to the group just as for individual logical
1896 ports, by assigning the group’s name to outport and executing an
1897 output action.
1898 Multicast group names and logical port names share a single
1900 namespace and thus should not overlap (but the database schema
1901 cannot enforce this). To try to avoid conflicts, ovn-northd uses
1902 names that begin with _MC_.
1903 ports: set of 1 or more weak reference to Port_Bindings
1905 The logical ports included in the multicast group. All of these
1906 ports must be in the datapath logical datapath (but the database
1907 schema cannot enforce this).
1908
1910 Each row in this table represents a meter that can be used for QoS or
1911 rate-limiting.
1912 Summary:
1914 name string (must be unique within table)
1915 unit string, either kbps or pktps
1916 bands set of 1 or more Meter_Bands
1917 Details:
1919 name: string (must be unique within table)
1920 A name for this meter.
1921 Names that begin with "__" (two underscores) are reserved for
1923 OVN internal use and should not be added manually.
1924 unit: string, either kbps or pktps
1926 The unit for rate and burst_rate parameters in the bands entry.
1927 kbps specifies kilobits per second, and pktps specifies packets
1928 per second.
1929 bands: set of 1 or more Meter_Bands
1931 The bands associated with this meter. Each band specifies a rate
1932 above which the band is to take the action action. If multiple
1933 bands’ rates are exceeded, then the band with the highest rate
1934 among the exceeded bands is selected.
1935
1937 Each row in this table represents a meter band which specifies the rate
1938 above which the configured action should be applied. These bands are
1939 referenced by the bands column in the Meter table.
1940 Summary:
1942 action string, must be drop
1943 rate integer, in range 1 to 4,294,967,295
1944 burst_size integer, in range 0 to 4,294,967,295
1945 Details:
1947 action: string, must be drop
1948 The action to execute when this band matches. The only supported
1949 action is drop.
1950 rate: integer, in range 1 to 4,294,967,295
1952 The rate limit for this band, in kilobits per second or bits per
1953 second, depending on whether the parent Meter entry’s unit col‐
1954 umn specified kbps or pktps.
1955 burst_size: integer, in range 0 to 4,294,967,295
1957 The maximum burst allowed for the band in kilobits or packets,
1958 depending on whether kbps or pktps was selected in the parent
1959 Meter entry’s unit column. If the size is zero, the switch is
1960 free to select some reasonable value depending on its configura‐
1961 tion.
1962
1964 Each row in this table represents a logical datapath, which implements
1965 a logical pipeline among the ports in the Port_Binding table associated
1966 with it. In practice, the pipeline in a given logical datapath imple‐
1967 ments either a logical switch or a logical router.
1968 The main purpose of a row in this table is provide a physical binding
1970 for a logical datapath. A logical datapath does not have a physical lo‐
1971 cation, so its physical binding information is limited: just tun‐
1972 nel_key. The rest of the data in this table does not affect packet for‐
1973 warding.
1974 Summary:
1976 tunnel_key integer, in range 1 to 16,777,215 (must
1977 be unique within table)
1978 load_balancers set of weak reference to Load_Balancers
1979 OVN_Northbound Relationship:
1980 external_ids : logical-switch
1981 optional string, containing an uuid
1982 external_ids : logical-router
1983 optional string, containing an uuid
1984 external_ids : interconn-ts
1985 optional string
1986 Naming:
1987 external_ids : name optional string
1988 external_ids : name2 optional string
1989 Common Columns:
1990 external_ids map of string-string pairs
1991 Details:
1993 tunnel_key: integer, in range 1 to 16,777,215 (must be unique within
1994 table)
1995 The tunnel key value to which the logical datapath is bound. The
1996 Tunnel Encapsulation section in ovn-architecture(7) describes
1997 how tunnel keys are constructed for each supported encapsula‐
1998 tion.
1999 load_balancers: set of weak reference to Load_Balancers
2001 Load balancers associated with the datapath.
2002 OVN_Northbound Relationship:
2004 Each row in Datapath_Binding is associated with some logical datapath.
2006 ovn-northd uses these keys to track the association of a logical data‐
2007 path with concepts in the OVN_Northbound database.
2008 external_ids : logical-switch: optional string, containing an uuid
2010 For a logical datapath that represents a logical switch,
2011 ovn-northd stores in this key the UUID of the corresponding Log‐
2012 ical_Switch row in the OVN_Northbound database.
2013 external_ids : logical-router: optional string, containing an uuid
2015 For a logical datapath that represents a logical router,
2016 ovn-northd stores in this key the UUID of the corresponding Log‐
2017 ical_Router row in the OVN_Northbound database.
2018 external_ids : interconn-ts: optional string
2020 For a logical datapath that represents a logical switch that
2021 represents a transit switch for interconnection, ovn-northd
2022 stores in this key the value of the same interconn-ts key of the
2023 external_ids column of the corresponding Logical_Switch row in
2024 the OVN_Northbound database.
2025 Naming:
2027 ovn-northd copies these from the name fields in the OVN_Northbound
2029 database, either from name and external_ids:neutron:router_name in the
2030 Logical_Router table or from name and external_ids:neutron:network_name
2031 in the Logical_Switch table.
2032 external_ids : name: optional string
2034 A name for the logical datapath.
2035 external_ids : name2: optional string
2037 Another name for the logical datapath.
2038 Common Columns:
2040 The overall purpose of these columns is described under Common Columns
2042 at the beginning of this document.
2043 external_ids: map of string-string pairs
2045
2047 Each row in this table binds a logical port to a realization. For most
2048 logical ports, this means binding to some physical location, for exam‐
2049 ple by binding a logical port to a VIF that belongs to a VM running on
2050 a particular hypervisor. Other logical ports, such as logical patch
2051 ports, can be realized without a specific physical location, but their
2052 bindings are still expressed through rows in this table.
2053 For every Logical_Switch_Port record in OVN_Northbound database,
2055 ovn-northd creates a record in this table. ovn-northd populates and
2056 maintains every column except the chassis and virtual_parent columns,
2057 which it leaves empty in new records.
2058 ovn-controller/ovn-controller-vtep populates the chassis column for the
2060 records that identify the logical ports that are located on its hyper‐
2061 visor/gateway, which ovn-controller/ovn-controller-vtep in turn finds
2062 out by monitoring the local hypervisor’s Open_vSwitch database, which
2063 identifies logical ports via the conventions described in Integra‐
2064 tionGuide.rst. (The exceptions are for Port_Binding records with type
2065 of l3gateway, whose locations are identified by ovn-northd via the op‐
2066 tions:l3gateway-chassis column in this table. ovn-controller is still
2067 responsible to populate the chassis column.)
2068 ovn-controller also populates the virtual_parent column of records
2070 whose type is virtual.
2071 When a chassis shuts down gracefully, it should clean up the chassis
2073 column that it previously had populated. (This is not critical because
2074 resources hosted on the chassis are equally unreachable regardless of
2075 whether their rows are present.) To handle the case where a VM is shut
2076 down abruptly on one chassis, then brought up again on a different one,
2077 ovn-controller/ovn-controller-vtep must overwrite the chassis column
2078 with new information.
2079 Summary:
2081 Core Features:
2082 datapath Datapath_Binding
2083 logical_port string (must be unique within table)
2084 encap optional weak reference to Encap
2085 chassis optional weak reference to Chassis
2086 gateway_chassis set of Gateway_Chassises
2087 ha_chassis_group optional HA_Chassis_Group
2088 up optional boolean
2089 tunnel_key integer, in range 1 to 32,767
2090 mac set of strings
2091 type string
2092 Patch Options:
2093 options : peer optional string
2094 nat_addresses set of strings
2095 L3 Gateway Options:
2096 options : peer optional string
2097 options : l3gateway-chassis
2098 optional string
2099 options : nat-addresses optional string
2100 nat_addresses set of strings
2101 Localnet Options:
2102 options : network_name optional string
2103 tag optional integer, in range 1 to 4,095
2104 L2 Gateway Options:
2105 options : network_name optional string
2106 options : l2gateway-chassis
2107 optional string
2108 tag optional integer, in range 1 to 4,095
2109 VTEP Options:
2110 options : vtep-physical-switch
2111 optional string
2112 options : vtep-logical-switch
2113 optional string
2114 VMI (or VIF) Options:
2115 options : requested-chassis
2116 optional string
2117 options : qos_max_rate optional string
2118 options : qos_burst optional string
2119 options : qdisc_queue_id optional string, containing an integer,
2120 in range 1 to 61,440
2121 Chassis Redirect Options:
2122 options : distributed-port optional string
2123 Nested Containers:
2124 parent_port optional string
2125 tag optional integer, in range 1 to 4,095
2126 Virtual ports:
2127 virtual_parent optional string
2128 Naming:
2129 external_ids : name optional string
2130 Common Columns:
2131 external_ids map of string-string pairs
2132 Details:
2134 Core Features:
2135 datapath: Datapath_Binding
2137 The logical datapath to which the logical port belongs.
2138 logical_port: string (must be unique within table)
2140 A logical port. For a logical switch port, this is taken from
2141 name in the OVN_Northbound database’s Logical_Switch_Port table.
2142 For a logical router port, this is taken from name in the
2143 OVN_Northbound database’s Logical_Router_port table. (This means
2144 that logical switch ports and router port names must share names
2145 in an OVN deployment.) OVN does not prescribe a particular for‐
2146 mat for the logical port ID.
2147 encap: optional weak reference to Encap
2149 Points to supported encapsulation configurations to transmit
2150 logical dataplane packets to this chassis. Each entry is a Encap
2151 record that describes the configuration.
2152 chassis: optional weak reference to Chassis
2154 The meaning of this column depends on the value of the type col‐
2155 umn. This is the meaning for each type
2156 (empty string)
2158 The physical location of the logical port. To success‐
2159 fully identify a chassis, this column must be a Chassis
2160 record. This is populated by ovn-controller.
2161 vtep The physical location of the hardware_vtep gateway. To
2163 successfully identify a chassis, this column must be a
2164 Chassis record. This is populated by ovn-controller-vtep.
2165 localnet
2167 Always empty. A localnet port is realized on every chas‐
2168 sis that has connectivity to the corresponding physical
2169 network.
2170 localport
2172 Always empty. A localport port is present on every chas‐
2173 sis.
2174 l3gateway
2176 The physical location of the L3 gateway. To successfully
2177 identify a chassis, this column must be a Chassis record.
2178 This is populated by ovn-controller based on the value of
2179 the options:l3gateway-chassis column in this table.
2180 l2gateway
2182 The physical location of this L2 gateway. To successfully
2183 identify a chassis, this column must be a Chassis record.
2184 This is populated by ovn-controller based on the value of
2185 the options:l2gateway-chassis column in this table.
2186 gateway_chassis: set of Gateway_Chassises
2188 A list of Gateway_Chassis.
2189 This should only be populated for ports with type set to chas‐
2191 sisredirect. This column defines the list of chassis used as
2192 gateways where traffic will be redirected through.
2193 ha_chassis_group: optional HA_Chassis_Group
2195 This should only be populated for ports with type set to chas‐
2196 sisredirect. This column defines the HA chassis group with a
2197 list of HA chassis used as gateways where traffic will be redi‐
2198 rected through.
2199 up: optional boolean
2201 This is set to true whenever all OVS flows required by this
2202 Port_Binding have been installed. This is populated by ovn-con‐
2203 troller.
2204 tunnel_key: integer, in range 1 to 32,767
2206 A number that represents the logical port in the key (e.g. STT
2207 key or Geneve TLV) field carried within tunnel protocol packets.
2208 The tunnel ID must be unique within the scope of a logical data‐
2210 path.
2211 mac: set of strings
2213 The Ethernet address or addresses used as a source address on
2214 the logical port, each in the form xx:xx:xx:xx:xx:xx. The string
2215 unknown is also allowed to indicate that the logical port has an
2216 unknown set of (additional) source addresses.
2217 A VM interface would ordinarily have a single Ethernet address.
2219 A gateway port might initially only have unknown, and then add
2220 MAC addresses to the set as it learns new source addresses.
2221 type: string
2223 A type for this logical port. Logical ports can be used to model
2224 other types of connectivity into an OVN logical switch. The fol‐
2225 lowing types are defined:
2226 (empty string)
2228 VM (or VIF) interface.
2229 patch One of a pair of logical ports that act as if connected
2231 by a patch cable. Useful for connecting two logical data‐
2232 paths, e.g. to connect a logical router to a logical
2233 switch or to another logical router.
2234 l3gateway
2236 One of a pair of logical ports that act as if connected
2237 by a patch cable across multiple chassis. Useful for con‐
2238 necting a logical switch with a Gateway router (which is
2239 only resident on a particular chassis).
2240 localnet
2242 A connection to a locally accessible network from
2243 ovn-controller instances that have a corresponding bridge
2244 mapping. A logical switch can have multiple localnet
2245 ports attached. This type is used to model direct connec‐
2246 tivity to existing networks. In this case, each chassis
2247 should have a mapping for one of the physical networks
2248 only. Note: nothing said above implies that a chassis
2249 cannot be plugged to multiple physical networks as long
2250 as they belong to different switches.
2251 localport
2253 A connection to a local VIF. Traffic that arrives on a
2254 localport is never forwarded over a tunnel to another
2255 chassis. These ports are present on every chassis and
2256 have the same address in all of them. This is used to
2257 model connectivity to local services that run on every
2258 hypervisor.
2259 l2gateway
2261 An L2 connection to a physical network. The chassis this
2262 Port_Binding is bound to will serve as an L2 gateway to
2263 the network named by options:network_name.
2264 vtep A port to a logical switch on a VTEP gateway chassis. In
2266 order to get this port correctly recognized by the OVN
2267 controller, the options:vtep-physical-switch and op‐
2268 tions:vtep-logical-switch must also be defined.
2269 chassisredirect
2271 A logical port that represents a particular instance,
2272 bound to a specific chassis, of an otherwise distributed
2273 parent port (e.g. of type patch). A chassisredirect port
2274 should never be used as an inport. When an ingress pipe‐
2275 line sets the outport, it may set the value to a logical
2276 port of type chassisredirect. This will cause the packet
2277 to be directed to a specific chassis to carry out the
2278 egress pipeline. At the beginning of the egress pipeline,
2279 the outport will be reset to the value of the distributed
2280 port.
2281 virtual
2283 Represents a logical port with an virtual ip. This vir‐
2284 tual ip can be configured on a logical port (which is
2285 refered as virtual parent).
2286 Patch Options:
2288 These options apply to logical ports with type of patch.
2290 options : peer: optional string
2292 The logical_port in the Port_Binding record for the other side
2293 of the patch. The named logical_port must specify this logi‐
2294 cal_port in its own peer option. That is, the two patch logical
2295 ports must have reversed logical_port and peer values.
2296 nat_addresses: set of strings
2298 MAC address followed by a list of SNAT and DNAT external IP ad‐
2299 dresses, followed by is_chassis_resident("lport"), where lport
2300 is the name of a logical port on the same chassis where the cor‐
2301 responding NAT rules are applied. This is used to send gratu‐
2302 itous ARPs for SNAT and DNAT external IP addresses via localnet,
2303 from the chassis where lport resides. Example: 80:fa:5b:06:72:b7
2304 158.36.44.22 158.36.44.24 is_chassis_resident("foo1"). This
2305 would result in generation of gratuitous ARPs for IP addresses
2306 158.36.44.22 and 158.36.44.24 with a MAC address of
2307 80:fa:5b:06:72:b7 from the chassis where the logical port "foo1"
2308 resides.
2309 L3 Gateway Options:
2311 These options apply to logical ports with type of l3gateway.
2313 options : peer: optional string
2315 The logical_port in the Port_Binding record for the other side
2316 of the ’l3gateway’ port. The named logical_port must specify
2317 this logical_port in its own peer option. That is, the two
2318 ’l3gateway’ logical ports must have reversed logical_port and
2319 peer values.
2320 options : l3gateway-chassis: optional string
2322 The chassis in which the port resides.
2323 options : nat-addresses: optional string
2325 MAC address of the l3gateway port followed by a list of SNAT and
2326 DNAT external IP addresses. This is used to send gratuitous ARPs
2327 for SNAT and DNAT external IP addresses via localnet. Example:
2328 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
2329 in generation of gratuitous ARPs for IP addresses 158.36.44.22
2330 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
2331 is used in OVS versions prior to 2.8.
2332 nat_addresses: set of strings
2334 MAC address of the l3gateway port followed by a list of SNAT and
2335 DNAT external IP addresses. This is used to send gratuitous ARPs
2336 for SNAT and DNAT external IP addresses via localnet. Example:
2337 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
2338 in generation of gratuitous ARPs for IP addresses 158.36.44.22
2339 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
2340 is used in OVS version 2.8 and later versions.
2341 Localnet Options:
2343 These options apply to logical ports with type of localnet.
2345 options : network_name: optional string
2347 Required. ovn-controller uses the configuration entry
2348 ovn-bridge-mappings to determine how to connect to this network.
2349 ovn-bridge-mappings is a list of network names mapped to a local
2350 OVS bridge that provides access to that network. An example of
2351 configuring ovn-bridge-mappings would be: .IP
2352 $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
2353 When a logical switch has a localnet port attached, every chas‐
2355 sis that may have a local vif attached to that logical switch
2356 must have a bridge mapping configured to reach that localnet.
2357 Traffic that arrives on a localnet port is never forwarded over
2358 a tunnel to another chassis. If there are multiple localnet
2359 ports in a logical switch, each chassis should only have a sin‐
2360 gle bridge mapping for one of the physical networks. Note: In
2361 case of multiple localnet ports, to provide interconnectivity
2362 between all VIFs located on different chassis with different
2363 fabric connectivity, the fabric should implement some form of
2364 routing between the segments.
2365 tag: optional integer, in range 1 to 4,095
2367 If set, indicates that the port represents a connection to a
2368 specific VLAN on a locally accessible network. The VLAN ID is
2369 used to match incoming traffic and is also added to outgoing
2370 traffic.
2371 L2 Gateway Options:
2373 These options apply to logical ports with type of l2gateway.
2375 options : network_name: optional string
2377 Required. ovn-controller uses the configuration entry
2378 ovn-bridge-mappings to determine how to connect to this network.
2379 ovn-bridge-mappings is a list of network names mapped to a local
2380 OVS bridge that provides access to that network. An example of
2381 configuring ovn-bridge-mappings would be: .IP
2382 $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
2383 When a logical switch has a l2gateway port attached, the chassis
2385 that the l2gateway port is bound to must have a bridge mapping
2386 configured to reach the network identified by network_name.
2387 options : l2gateway-chassis: optional string
2389 Required. The chassis in which the port resides.
2390 tag: optional integer, in range 1 to 4,095
2392 If set, indicates that the gateway is connected to a specific
2393 VLAN on the physical network. The VLAN ID is used to match in‐
2394 coming traffic and is also added to outgoing traffic.
2395 VTEP Options:
2397 These options apply to logical ports with type of vtep.
2399 options : vtep-physical-switch: optional string
2401 Required. The name of the VTEP gateway.
2402 options : vtep-logical-switch: optional string
2404 Required. A logical switch name connected by the VTEP gateway.
2405 Must be set when type is vtep.
2406 VMI (or VIF) Options:
2408 These options apply to logical ports with type having (empty string)
2410 options : requested-chassis: optional string
2412 If set, identifies a specific chassis (by name or hostname) that
2413 is allowed to bind this port. Using this option will prevent
2414 thrashing between two chassis trying to bind the same port dur‐
2415 ing a live migration. It can also prevent similar thrashing due
2416 to a mis-configuration, if a port is accidentally created on
2417 more than one chassis.
2418 options : qos_max_rate: optional string
2420 If set, indicates the maximum rate for data sent from this in‐
2421 terface, in bit/s. The traffic will be shaped according to this
2422 limit.
2423 options : qos_burst: optional string
2425 If set, indicates the maximum burst size for data sent from this
2426 interface, in bits.
2427 options : qdisc_queue_id: optional string, containing an integer, in
2429 range 1 to 61,440
2430 Indicates the queue number on the physical device. This is same
2431 as the queue_id used in OpenFlow in struct ofp_action_enqueue.
2432 Chassis Redirect Options:
2434 These options apply to logical ports with type of chassisredirect.
2436 options : distributed-port: optional string
2438 The name of the distributed port for which this chassisredirect
2439 port represents a particular instance.
2440 Nested Containers:
2442 These columns support containers nested within a VM. Specifically, they
2444 are used when type is empty and logical_port identifies the interface
2445 of a container spawned inside a VM. They are empty for containers or
2446 VMs that run directly on a hypervisor.
2447 parent_port: optional string
2449 This is taken from parent_name in the OVN_Northbound database’s
2450 Logical_Switch_Port table.
2451 tag: optional integer, in range 1 to 4,095
2453 Identifies the VLAN tag in the network traffic associated with
2454 that container’s network interface.
2455 This column is used for a different purpose when type is local‐
2457 net (see Localnet Options, above) or l2gateway (see L2 Gateway
2458 Options, above).
2459 Virtual ports:
2461 virtual_parent: optional string
2463 This column is set by ovn-controller with one of the value from
2464 the options:virtual-parents in the OVN_Northbound database’s
2465 Logical_Switch_Port table when the OVN action bind_vport is exe‐
2466 cuted. ovn-controller also sets the chassis column when it exe‐
2467 cutes this action with its chassis id.
2468 ovn-controller sets this column only if the type is "virtual".
2470 Naming:
2472 external_ids : name: optional string
2474 For a logical switch port, ovn-northd copies this from exter‐
2475 nal_ids:neutron:port_name in the Logical_Switch_Port table in
2476 the OVN_Northbound database, if it is a nonempty string.
2477 For a logical switch port, ovn-northd does not currently set
2479 this key.
2480 Common Columns:
2482 external_ids: map of string-string pairs
2484 See External IDs at the beginning of this document.
2485 The ovn-northd program populates this column with all entries
2487 into the external_ids column of the Logical_Switch_Port table of
2488 the OVN_Northbound database.
2489
2491 Each row in this table specifies a binding from an IP address to an
2492 Ethernet address that has been discovered through ARP (for IPv4) or
2493 neighbor discovery (for IPv6). This table is primarily used to discover
2494 bindings on physical networks, because IP-to-MAC bindings for virtual
2495 machines are usually populated statically into the Port_Binding table.
2496 This table expresses a functional relationship: MAC_Binding(logi‐
2498 cal_port, ip) = mac.
2499 In outline, the lifetime of a logical router’s MAC binding looks like
2501 this:
2502 1. On hypervisor 1, a logical router determines that a packet
2504 should be forwarded to IP address A on one of its router
2505 ports. It uses its logical flow table to determine that A
2506 lacks a static IP-to-MAC binding and the get_arp action to
2507 determine that it lacks a dynamic IP-to-MAC binding.
2508 2. Using an OVN logical arp action, the logical router gener‐
2510 ates and sends a broadcast ARP request to the router port.
2511 It drops the IP packet.
2512 3. The logical switch attached to the router port delivers the
2514 ARP request to all of its ports. (It might make sense to de‐
2515 liver it only to ports that have no static IP-to-MAC bind‐
2516 ings, but this could also be surprising behavior.)
2517 4. A host or VM on hypervisor 2 (which might be the same as hy‐
2519 pervisor 1) attached to the logical switch owns the IP ad‐
2520 dress in question. It composes an ARP reply and unicasts it
2521 to the logical router port’s Ethernet address.
2522 5. The logical switch delivers the ARP reply to the logical
2524 router port.
2525 6. The logical router flow table executes a put_arp action. To
2527 record the IP-to-MAC binding, ovn-controller adds a row to
2528 the MAC_Binding table.
2529 7. On hypervisor 1, ovn-controller receives the updated
2531 MAC_Binding table from the OVN southbound database. The next
2532 packet destined to A through the logical router is sent di‐
2533 rectly to the bound Ethernet address.
2534 Summary:
2536 logical_port string
2537 ip string
2538 mac string
2539 datapath Datapath_Binding
2540 Details:
2542 logical_port: string
2543 The logical port on which the binding was discovered.
2544 ip: string
2546 The bound IP address.
2547 mac: string
2549 The Ethernet address to which the IP is bound.
2550 datapath: Datapath_Binding
2552 The logical datapath to which the logical port belongs.
2553
2555 Each row in this table stores the DHCP Options supported by native OVN
2556 DHCP. ovn-northd populates this table with the supported DHCP options.
2557 ovn-controller looks up this table to get the DHCP codes of the DHCP
2558 options defined in the "put_dhcp_opts" action. Please refer to the RFC
2559 2132 "https://tools.ietf.org/html/rfc2132" for the possible list of
2560 DHCP options that can be defined here.
2561 Summary:
2563 name string
2564 code integer, in range 0 to 254
2565 type string, one of bool, domains, host_id,
2566 ipv4, static_routes, str, uint16, uint32,
2567 or uint8
2568 Details:
2570 name: string
2571 Name of the DHCP option.
2572 Example. name="router"
2574 code: integer, in range 0 to 254
2576 DHCP option code for the DHCP option as defined in the RFC 2132.
2577 Example. code=3
2579 type: string, one of bool, domains, host_id, ipv4, static_routes, str,
2581 uint16, uint32, or uint8
2582 Data type of the DHCP option code.
2583 value: bool
2585 This indicates that the value of the DHCP option is a
2586 bool.
2587 Example. "name=ip_forward_enable", "code=19",
2589 "type=bool".
2590 put_dhcp_opts(..., ip_forward_enable = 1,...)
2592 value: uint8
2594 This indicates that the value of the DHCP option is an
2595 unsigned int8 (8 bits)
2596 Example. "name=default_ttl", "code=23", "type=uint8".
2598 put_dhcp_opts(..., default_ttl = 50,...)
2600 value: uint16
2602 This indicates that the value of the DHCP option is an
2603 unsigned int16 (16 bits).
2604 Example. "name=mtu", "code=26", "type=uint16".
2606 put_dhcp_opts(..., mtu = 1450,...)
2608 value: uint32
2610 This indicates that the value of the DHCP option is an
2611 unsigned int32 (32 bits).
2612 Example. "name=lease_time", "code=51", "type=uint32".
2614 put_dhcp_opts(..., lease_time = 86400,...)
2616 value: ipv4
2618 This indicates that the value of the DHCP option is an
2619 IPv4 address or addresses.
2620 Example. "name=router", "code=3", "type=ipv4".
2622 put_dhcp_opts(..., router = 10.0.0.1,...)
2624 Example. "name=dns_server", "code=6", "type=ipv4".
2626 put_dhcp_opts(..., dns_server = {8.8.8.8 7.7.7.7},...)
2628 value: static_routes
2630 This indicates that the value of the DHCP option contains
2631 a pair of IPv4 route and next hop addresses.
2632 Example. "name=classless_static_route", "code=121",
2634 "type=static_routes".
2635 put_dhcp_opts(..., classless_static_route =
2637 {30.0.0.0/24,10.0.0.4,0.0.0.0/0,10.0.0.1}...)
2638 value: str
2640 This indicates that the value of the DHCP option is a
2641 string.
2642 Example. "name=host_name", "code=12", "type=str".
2644 value: host_id
2646 This indicates that the value of the DHCP option is a
2647 host_id. It can either be a host_name or an IP address.
2648 Example. "name=tftp_server", "code=66", "type=host_id".
2650 value: domains
2652 This indicates that the value of the DHCP option is a do‐
2653 main name or a comma separated list of domain names.
2654 Example. "name=domain_search_list", "code=119", "type=do‐
2656 mains".
2657
2659 Each row in this table stores the DHCPv6 Options supported by native
2660 OVN DHCPv6. ovn-northd populates this table with the supported DHCPv6
2661 options. ovn-controller looks up this table to get the DHCPv6 codes of
2662 the DHCPv6 options defined in the put_dhcpv6_opts action. Please refer
2663 to RFC 3315 and RFC 3646 for the list of DHCPv6 options that can be de‐
2664 fined here.
2665 Summary:
2667 name string
2668 code integer, in range 0 to 254
2669 type string, one of ipv6, mac, or str
2670 Details:
2672 name: string
2673 Name of the DHCPv6 option.
2674 Example. name="ia_addr"
2676 code: integer, in range 0 to 254
2678 DHCPv6 option code for the DHCPv6 option as defined in the ap‐
2679 propriate RFC.
2680 Example. code=3
2682 type: string, one of ipv6, mac, or str
2684 Data type of the DHCPv6 option code.
2685 value: ipv6
2687 This indicates that the value of the DHCPv6 option is an
2688 IPv6 address(es).
2689 Example. "name=ia_addr", "code=5", "type=ipv6".
2691 put_dhcpv6_opts(..., ia_addr = ae70::4,...)
2693 value: str
2695 This indicates that the value of the DHCPv6 option is a
2696 string.
2697 Example. "name=domain_search", "code=24", "type=str".
2699 put_dhcpv6_opts(..., domain_search = ovn.domain,...)
2701 value: mac
2703 This indicates that the value of the DHCPv6 option is a
2704 MAC address.
2705 Example. "name=server_id", "code=2", "type=mac".
2707 put_dhcpv6_opts(..., server_id = 01:02:03:04L05:06,...)
2709
2711 Configuration for a database connection to an Open vSwitch database
2712 (OVSDB) client.
2713 This table primarily configures the Open vSwitch database server
2715 (ovsdb-server).
2716 The Open vSwitch database server can initiate and maintain active con‐
2718 nections to remote clients. It can also listen for database connec‐
2719 tions.
2720 Summary:
2722 Core Features:
2723 target string (must be unique within table)
2724 read_only boolean
2725 role string
2726 Client Failure Detection and Handling:
2727 max_backoff optional integer, at least 1,000
2728 inactivity_probe optional integer
2729 Status:
2730 is_connected boolean
2731 status : last_error optional string
2732 status : state optional string, one of ACTIVE, BACKOFF,
2733 CONNECTING, IDLE, or VOID
2734 status : sec_since_connect optional string, containing an integer,
2735 at least 0
2736 status : sec_since_disconnect
2737 optional string, containing an integer,
2738 at least 0
2739 status : locks_held optional string
2740 status : locks_waiting optional string
2741 status : locks_lost optional string
2742 status : n_connections optional string, containing an integer,
2743 at least 2
2744 status : bound_port optional string, containing an integer
2745 Common Columns:
2746 external_ids map of string-string pairs
2747 other_config map of string-string pairs
2748 Details:
2750 Core Features:
2751 target: string (must be unique within table)
2753 Connection methods for clients.
2754 The following connection methods are currently supported:
2756 ssl:host[:port]
2758 The specified SSL port on the given host, which can ei‐
2759 ther be a DNS name (if built with unbound library) or an
2760 IP address. A valid SSL configuration must be provided
2761 when this form is used, this configuration can be speci‐
2762 fied via command-line options or the SSL table.
2763 If port is not specified, it defaults to 6640.
2765 SSL support is an optional feature that is not always
2767 built as part of Open vSwitch.
2768 tcp:host[:port]
2770 The specified TCP port on the given host, which can ei‐
2771 ther be a DNS name (if built with unbound library) or an
2772 IP address (IPv4 or IPv6). If host is an IPv6 address,
2773 wrap it in square brackets, e.g. tcp:[::1]:6640.
2774 If port is not specified, it defaults to 6640.
2776 pssl:[port][:host]
2778 Listens for SSL connections on the specified TCP port.
2779 Specify 0 for port to have the kernel automatically
2780 choose an available port. If host, which can either be a
2781 DNS name (if built with unbound library) or an IP ad‐
2782 dress, is specified, then connections are restricted to
2783 the resolved or specified local IP address (either IPv4
2784 or IPv6 address). If host is an IPv6 address, wrap in
2785 square brackets, e.g. pssl:6640:[::1]. If host is not
2786 specified then it listens only on IPv4 (but not IPv6) ad‐
2787 dresses. A valid SSL configuration must be provided when
2788 this form is used, this can be specified either via com‐
2789 mand-line options or the SSL table.
2790 If port is not specified, it defaults to 6640.
2792 SSL support is an optional feature that is not always
2794 built as part of Open vSwitch.
2795 ptcp:[port][:host]
2797 Listens for connections on the specified TCP port. Spec‐
2798 ify 0 for port to have the kernel automatically choose an
2799 available port. If host, which can either be a DNS name
2800 (if built with unbound library) or an IP address, is
2801 specified, then connections are restricted to the re‐
2802 solved or specified local IP address (either IPv4 or IPv6
2803 address). If host is an IPv6 address, wrap it in square
2804 brackets, e.g. ptcp:6640:[::1]. If host is not specified
2805 then it listens only on IPv4 addresses.
2806 If port is not specified, it defaults to 6640.
2808 When multiple clients are configured, the target values must be
2810 unique. Duplicate target values yield unspecified results.
2811 read_only: boolean
2813 true to restrict these connections to read-only transactions,
2814 false to allow them to modify the database.
2815 role: string
2817 String containing role name for this connection entry.
2818 Client Failure Detection and Handling:
2820 max_backoff: optional integer, at least 1,000
2822 Maximum number of milliseconds to wait between connection at‐
2823 tempts. Default is implementation-specific.
2824 inactivity_probe: optional integer
2826 Maximum number of milliseconds of idle time on connection to the
2827 client before sending an inactivity probe message. If Open
2828 vSwitch does not communicate with the client for the specified
2829 number of seconds, it will send a probe. If a response is not
2830 received for the same additional amount of time, Open vSwitch
2831 assumes the connection has been broken and attempts to recon‐
2832 nect. Default is implementation-specific. A value of 0 disables
2833 inactivity probes.
2834 Status:
2836 Key-value pair of is_connected is always updated. Other key-value pairs
2838 in the status columns may be updated depends on the target type.
2839 When target specifies a connection method that listens for inbound con‐
2841 nections (e.g. ptcp: or punix:), both n_connections and is_connected
2842 may also be updated while the remaining key-value pairs are omitted.
2843 On the other hand, when target specifies an outbound connection, all
2845 key-value pairs may be updated, except the above-mentioned two key-
2846 value pairs associated with inbound connection targets. They are omit‐
2847 ted.
2848 is_connected: boolean
2850 true if currently connected to this client, false otherwise.
2851 status : last_error: optional string
2853 A human-readable description of the last error on the connection
2854 to the manager; i.e. strerror(errno). This key will exist only
2855 if an error has occurred.
2856 status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
2858 IDLE, or VOID
2859 The state of the connection to the manager:
2860 VOID Connection is disabled.
2862 BACKOFF
2864 Attempting to reconnect at an increasing period.
2865 CONNECTING
2867 Attempting to connect.
2868 ACTIVE Connected, remote host responsive.
2870 IDLE Connection is idle. Waiting for response to keep-alive.
2872 These values may change in the future. They are provided only
2874 for human consumption.
2875 status : sec_since_connect: optional string, containing an integer, at
2877 least 0
2878 The amount of time since this client last successfully connected
2879 to the database (in seconds). Value is empty if client has never
2880 successfully been connected.
2881 status : sec_since_disconnect: optional string, containing an integer,
2883 at least 0
2884 The amount of time since this client last disconnected from the
2885 database (in seconds). Value is empty if client has never dis‐
2886 connected.
2887 status : locks_held: optional string
2889 Space-separated list of the names of OVSDB locks that the con‐
2890 nection holds. Omitted if the connection does not hold any
2891 locks.
2892 status : locks_waiting: optional string
2894 Space-separated list of the names of OVSDB locks that the con‐
2895 nection is currently waiting to acquire. Omitted if the connec‐
2896 tion is not waiting for any locks.
2897 status : locks_lost: optional string
2899 Space-separated list of the names of OVSDB locks that the con‐
2900 nection has had stolen by another OVSDB client. Omitted if no
2901 locks have been stolen from this connection.
2902 status : n_connections: optional string, containing an integer, at
2904 least 2
2905 When target specifies a connection method that listens for in‐
2906 bound connections (e.g. ptcp: or pssl:) and more than one con‐
2907 nection is actually active, the value is the number of active
2908 connections. Otherwise, this key-value pair is omitted.
2909 status : bound_port: optional string, containing an integer
2911 When target is ptcp: or pssl:, this is the TCP port on which the
2912 OVSDB server is listening. (This is particularly useful when
2913 target specifies a port of 0, allowing the kernel to choose any
2914 available port.)
2915 Common Columns:
2917 The overall purpose of these columns is described under Common Columns
2919 at the beginning of this document.
2920 external_ids: map of string-string pairs
2922 other_config: map of string-string pairs
2924
2926 SSL configuration for ovn-sb database access.
2927 Summary:
2929 private_key string
2930 certificate string
2931 ca_cert string
2932 bootstrap_ca_cert boolean
2933 ssl_protocols string
2934 ssl_ciphers string
2935 Common Columns:
2936 external_ids map of string-string pairs
2937 Details:
2939 private_key: string
2940 Name of a PEM file containing the private key used as the
2941 switch’s identity for SSL connections to the controller.
2942 certificate: string
2944 Name of a PEM file containing a certificate, signed by the cer‐
2945 tificate authority (CA) used by the controller and manager, that
2946 certifies the switch’s private key, identifying a trustworthy
2947 switch.
2948 ca_cert: string
2950 Name of a PEM file containing the CA certificate used to verify
2951 that the switch is connected to a trustworthy controller.
2952 bootstrap_ca_cert: boolean
2954 If set to true, then Open vSwitch will attempt to obtain the CA
2955 certificate from the controller on its first SSL connection and
2956 save it to the named PEM file. If it is successful, it will im‐
2957 mediately drop the connection and reconnect, and from then on
2958 all SSL connections must be authenticated by a certificate
2959 signed by the CA certificate thus obtained. This option exposes
2960 the SSL connection to a man-in-the-middle attack obtaining the
2961 initial CA certificate. It may still be useful for bootstrap‐
2962 ping.
2963 ssl_protocols: string
2965 List of SSL protocols to be enabled for SSL connections. The de‐
2966 fault when this option is omitted is TLSv1,TLSv1.1,TLSv1.2.
2967 ssl_ciphers: string
2969 List of ciphers (in OpenSSL cipher string format) to be sup‐
2970 ported for SSL connections. The default when this option is
2971 omitted is HIGH:!aNULL:!MD5.
2972 Common Columns:
2974 The overall purpose of these columns is described under Common Columns
2976 at the beginning of this document.
2977 external_ids: map of string-string pairs
2979
2981 Each row in this table stores the DNS records. The OVN action
2982 dns_lookup uses this table for DNS resolution.
2983 Summary:
2985 records map of string-string pairs
2986 datapaths set of 1 or more Datapath_Bindings
2987 Common Columns:
2988 external_ids map of string-string pairs
2989 Details:
2991 records: map of string-string pairs
2992 Key-value pair of DNS records with DNS query name as the key and
2993 a string of IP address(es) separated by comma or space as the
2994 value. ovn-northd stores the DNS query name in all lowercase in
2995 order to facilitate case-insensitive lookups.
2996 Example: "vm1.ovn.org" = "10.0.0.4 aef0::4"
2998 datapaths: set of 1 or more Datapath_Bindings
3000 The DNS records defined in the column records will be applied
3001 only to the DNS queries originating from the datapaths defined
3002 in this column.
3003 Common Columns:
3005 external_ids: map of string-string pairs
3007 See External IDs at the beginning of this document.
3008
3010 Role table for role-based access controls.
3011 Summary:
3013 name string
3014 permissions map of string-weak reference to RBAC_Per‐
3015 mission pairs
3016 Details:
3018 name: string
3019 The role name, corresponding to the role column in the Connec‐
3020 tion table.
3021 permissions: map of string-weak reference to RBAC_Permission pairs
3023 A mapping of table names to rows in the RBAC_Permission table.
3024
3026 Permissions table for role-based access controls.
3027 Summary:
3029 table string
3030 authorization set of strings
3031 insert_delete boolean
3032 update set of strings
3033 Details:
3035 table: string
3036 Name of table to which this row applies.
3037 authorization: set of strings
3039 Set of strings identifying columns and column:key pairs to be
3040 compared with client ID. At least one match is required in order
3041 to be authorized. A zero-length string is treated as a special
3042 value indicating all clients should be considered authorized.
3043 insert_delete: boolean
3045 When "true", row insertions and authorized row deletions are
3046 permitted.
3047 update: set of strings
3049 Set of strings identifying columns and column:key pairs that au‐
3050 thorized clients are allowed to modify.
3051
3053 Association of Port_Binding rows of type chassisredirect to a Chassis.
3054 The traffic going out through a specific chassisredirect port will be
3055 redirected to a chassis, or a set of them in high availability configu‐
3056 rations.
3057 Summary:
3059 name string (must be unique within table)
3060 chassis optional weak reference to Chassis
3061 priority integer, in range 0 to 32,767
3062 options map of string-string pairs
3063 Common Columns:
3064 external_ids map of string-string pairs
3065 Details:
3067 name: string (must be unique within table)
3068 Name of the Gateway_Chassis.
3069 A suggested, but not required naming convention is
3071 ${port_name}_${chassis_name}.
3072 chassis: optional weak reference to Chassis
3074 The Chassis to which we send the traffic.
3075 priority: integer, in range 0 to 32,767
3077 This is the priority the specific Chassis among all Gate‐
3078 way_Chassis belonging to the same Port_Binding.
3079 options: map of string-string pairs
3081 Reserved for future use.
3082 Common Columns:
3084 The overall purpose of these columns is described under Common Columns
3086 at the beginning of this document.
3087 external_ids: map of string-string pairs
3089
3091 Summary:
3092 chassis optional weak reference to Chassis
3093 priority integer, in range 0 to 32,767
3094 Common Columns:
3095 external_ids map of string-string pairs
3096 Details:
3098 chassis: optional weak reference to Chassis
3099 The Chassis which provides the HA functionality.
3100 priority: integer, in range 0 to 32,767
3102 Priority of the HA chassis. Chassis with highest priority will
3103 be the master in the HA chassis group.
3104 Common Columns:
3106 external_ids: map of string-string pairs
3108 See External IDs at the beginning of this document.
3109
3111 Table representing a group of chassis which can provide High availabil‐
3112 ity services. Each chassis in the group is represented by the table
3113 HA_Chassis. The HA chassis with highest priority will be the master of
3114 this group. If the master chassis failover is detected, the HA chassis
3115 with the next higher priority takes over the responsibility of provid‐
3116 ing the HA. If ha_chassis_group column of the table Port_Binding refer‐
3117 ences this table, then this HA chassis group provides the gateway func‐
3118 tionality and redirects the gateway traffic to the master of this
3119 group.
3120 Summary:
3122 name string (must be unique within table)
3123 ha_chassis set of HA_Chassises
3124 ref_chassis set of weak reference to Chassis
3125 Common Columns:
3126 external_ids map of string-string pairs
3127 Details:
3129 name: string (must be unique within table)
3130 Name of the HA_Chassis_Group. Name should be unique.
3131 ha_chassis: set of HA_Chassises
3133 A list of HA_Chassis which belongs to this group.
3134 ref_chassis: set of weak reference to Chassis
3136 The set of Chassis that reference this HA chassis group. To de‐
3137 termine the correct Chassis, find the chassisredirect type
3138 Port_Binding that references this HA_Chassis_Group. This
3139 Port_Binding is derived from some particular logical router.
3140 Starting from that LR, find the set of all logical switches and
3141 routers connected to it, directly or indirectly, across router
3142 ports that link one LRP to another or to a LSP. For each LSP in
3143 these logical switches, find the corresponding Port_Binding and
3144 add its bound Chassis (if any) to ref_chassis.
3145 Common Columns:
3147 external_ids: map of string-string pairs
3149 See External IDs at the beginning of this document.
3150
3152 Database table used by ovn-controller to report CMS related events.
3153 Please note there is no guarantee a given event is written exactly once
3154 in the db. It is CMS responsibility to squash duplicated lines or to
3155 filter out duplicated events
3156 Summary:
3158 event_type string, must be empty_lb_backends
3159 event_info map of string-string pairs
3160 chassis optional weak reference to Chassis
3161 seq_num integer
3162 Details:
3164 event_type: string, must be empty_lb_backends
3165 Event type occurred
3166 event_info: map of string-string pairs
3168 Key-value pairs used to specify event info to the CMS. Possible
3169 values are:
3170 • vip: VIP reported for the empty_lb_backends event
3172 • protocol: Transport protocol reported for the
3174 empty_lb_backends event
3175 • load_balancer: UUID of the load balancer reported for the
3177 empty_lb_backends event
3178 chassis: optional weak reference to Chassis
3180 This column is a Chassis record to identify the chassis that has
3181 managed a given event.
3182 seq_num: integer
3184 Event sequence number. Global counter for controller generated
3185 events. It can be used by the CMS to detect possible duplication
3186 of the same event.
3187
3189 IP Multicast configuration options. For now only applicable to IGMP.
3190 Summary:
3192 datapath weak reference to Datapath_Binding (must
3193 be unique within table)
3194 enabled optional boolean
3195 querier optional boolean
3196 table_size optional integer
3197 idle_timeout optional integer
3198 query_interval optional integer
3199 seq_no integer
3200 Querier configuration options:
3201 eth_src string
3202 ip4_src string
3203 ip6_src string
3204 query_max_resp optional integer
3205 Details:
3207 datapath: weak reference to Datapath_Binding (must be unique within ta‐
3208 ble)
3209 Datapath_Binding entry for which these configuration options are
3210 defined.
3211 enabled: optional boolean
3213 Enables/disables multicast snooping. Default: disabled.
3214 querier: optional boolean
3216 Enables/disables multicast querying. If enabled then multicast
3217 querying is enabled by default.
3218 table_size: optional integer
3220 Limits the number of multicast groups that can be learned. De‐
3221 fault: 2048 groups per datapath.
3222 idle_timeout: optional integer
3224 Configures the idle timeout (in seconds) for IP multicast groups
3225 if multicast snooping is enabled. Default: 300 seconds.
3226 query_interval: optional integer
3228 Configures the interval (in seconds) for sending multicast
3229 queries if snooping and querier are enabled. Default: idle_time‐
3230 out/2 seconds.
3231 seq_no: integer
3233 ovn-controller reads this value and flushes all learned multi‐
3234 cast groups when it detects that seq_no was changed.
3235 Querier configuration options:
3237 The ovn-controller process that runs on OVN hypervisor nodes uses the
3239 following columns to determine field values in IGMP/MLD queries that it
3240 originates:
3241 eth_src: string
3243 Source Ethernet address.
3244 ip4_src: string
3246 Source IPv4 address.
3247 ip6_src: string
3249 Source IPv6 address.
3250 query_max_resp: optional integer
3252 Value (in seconds) to be used as "max-response" field in multi‐
3253 cast queries. Default: 1 second.
3254
3256 Contains learned IGMP groups indexed by address/datapath/chassis.
3257 Summary:
3259 address string
3260 datapath optional weak reference to Datapath_Bind‐
3261 ing
3262 chassis optional weak reference to Chassis
3263 ports set of weak reference to Port_Bindings
3264 Details:
3266 address: string
3267 Destination IPv4 address for the IGMP group.
3268 datapath: optional weak reference to Datapath_Binding
3270 Datapath to which this IGMP group belongs.
3271 chassis: optional weak reference to Chassis
3273 Chassis to which this IGMP group belongs.
3274 ports: set of weak reference to Port_Bindings
3276 The destination port bindings for this IGMP group.
3277
3279 Each row in this table configures monitoring a service for its live‐
3280 ness. The service can be an IPv4 TCP or UDP service. ovn-controller pe‐
3281 riodically sends out service monitor packets and updates the status of
3282 the service. Service monitoring for IPv6 services is not supported.
3283 ovn-northd uses this feature to implement the load balancer health
3285 check feature offered to the CMS through the northbound database.
3286 Summary:
3288 Configuration:
3289 ip string
3290 protocol optional string, either tcp or udp
3291 port integer, in range 0 to 32,767
3292 logical_port string
3293 src_mac string
3294 src_ip string
3295 options : interval optional string, containing an integer
3296 options : timeout optional string, containing an integer
3297 options : success_count optional string, containing an integer
3298 options : failure_count optional string, containing an integer
3299 Status Reporting:
3300 status optional string, one of error, offline,
3301 or online
3302 Common Columns:
3303 external_ids map of string-string pairs
3304 Details:
3306 Configuration:
3307 ovn-northd sets these columns and values to configure the service moni‐
3309 tor.
3310 ip: string
3312 IP of the service to be monitored. Only IPv4 is supported.
3313 protocol: optional string, either tcp or udp
3315 The protocol of the service.
3316 port: integer, in range 0 to 32,767
3318 The TCP or UDP port of the service.
3319 logical_port: string
3321 The VIF of the logical port on which the service is running. The
3322 ovn-controller that binds this logical_port monitors the service
3323 by sending periodic monitor packets.
3324 src_mac: string
3326 Source Ethernet address to use in the service monitor packet.
3327 src_ip: string
3329 Source IPv4 address to use in the service monitor packet.
3330 options : interval: optional string, containing an integer
3332 The interval, in seconds, between service monitor checks.
3333 options : timeout: optional string, containing an integer
3335 The time, in seconds, after which the service monitor check
3336 times out.
3337 options : success_count: optional string, containing an integer
3339 The number of successful checks after which the service is con‐
3340 sidered online.
3341 options : failure_count: optional string, containing an integer
3343 The number of failure checks after which the service is consid‐
3344 ered offline.
3345 Status Reporting:
3347 The ovn-controller on the chassis that hosts the logical_port updates
3349 this column to report the service’s status.
3350 status: optional string, one of error, offline, or online
3352 For TCP service, ovn-controller sends a SYN to the service and
3353 expects an ACK response to consider the service to be online.
3354 For UDP service, ovn-controller sends a UDP packet to the ser‐
3356 vice and doesn’t expect any reply. If it receives an ICMP reply,
3357 then it considers the service to be offline.
3358 Common Columns:
3360 external_ids: map of string-string pairs
3362 See External IDs at the beginning of this document.
3363
3365 Each row represents a load balancer.
3366 Summary:
3368 name string
3369 vips map of string-string pairs
3370 protocol optional string, one of sctp, tcp, or udp
3371 datapaths set of Datapath_Bindings
3372 Load_Balancer options:
3373 options : hairpin_snat_ip optional string
3374 options : hairpin_orig_tuple
3375 optional string, either true or false
3376 Common Columns:
3377 external_ids map of string-string pairs
3378 Details:
3380 name: string
3381 A name for the load balancer. This name has no special meaning
3382 or purpose other than to provide convenience for human interac‐
3383 tion with the ovn-nb database.
3384 vips: map of string-string pairs
3386 A map of virtual IP addresses (and an optional port number with
3387 : as a separator) associated with this load balancer and their
3388 corresponding endpoint IP addresses (and optional port numbers
3389 with : as separators) separated by commas.
3390 protocol: optional string, one of sctp, tcp, or udp
3392 Valid protocols are tcp, udp, or sctp. This column is useful
3393 when a port number is provided as part of the vips column. If
3394 this column is empty and a port number is provided as part of
3395 vips column, OVN assumes the protocol to be tcp.
3396 datapaths: set of Datapath_Bindings
3398 Datapaths to which this load balancer applies to.
3399 Load_Balancer options:
3401 options : hairpin_snat_ip: optional string
3403 IP to be used as source IP for packets that have been hair-
3404 pinned after load balancing. This value is automatically popu‐
3405 lated by ovn-northd.
3406 options : hairpin_orig_tuple: optional string, either true or false
3408 This value is automatically set to true by ovn-northd when orig‐
3409 inal destination IP and transport port of the load balanced
3410 packets are stored in registers reg1, reg2, xxreg1.
3411 Common Columns:
3413 external_ids: map of string-string pairs
3415 See External IDs at the beginning of this document.
3416
3418 Contains BFD parameter for ovn-controller bfd configuration.
3419 Summary:
3421 Configuration:
3422 src_port integer, in range 49,152 to 65,535
3423 disc integer
3424 logical_port string
3425 dst_ip string
3426 min_tx integer
3427 min_rx integer
3428 detect_mult integer
3429 options map of string-string pairs
3430 external_ids map of string-string pairs
3431 Status Reporting:
3432 status string, one of admin_down, down, init, or
3433 up
3434 Details:
3436 Configuration:
3437 src_port: integer, in range 49,152 to 65,535
3439 udp source port used in bfd control packets. The source port
3440 MUST be in the range 49152 through 65535 (RFC5881 section 4).
3441 disc: integer
3443 A unique, nonzero discriminator value generated by the transmit‐
3444 ting system, used to demultiplex multiple BFD sessions between
3445 the same pair of systems.
3446 logical_port: string
3448 OVN logical port when BFD engine is running.
3449 dst_ip: string
3451 BFD peer IP address.
3452 min_tx: integer
3454 This is the minimum interval, in milliseconds, that the local
3455 system would like to use when transmitting BFD Control packets,
3456 less any jitter applied. The value zero is reserved.
3457 min_rx: integer
3459 This is the minimum interval, in milliseconds, between received
3460 BFD Control packets that this system is capable of supporting,
3461 less any jitter applied by the sender. If this value is zero,
3462 the transmitting system does not want the remote system to send
3463 any periodic BFD Control packets.
3464 detect_mult: integer
3466 Detection time multiplier. The negotiated transmit interval,
3467 multiplied by this value, provides the Detection Time for the
3468 receiving system in Asynchronous mode.
3469 options: map of string-string pairs
3471 Reserved for future use.
3472 external_ids: map of string-string pairs
3474 See External IDs at the beginning of this document.
3475 Status Reporting:
3477 status: string, one of admin_down, down, init, or up
3479 BFD port logical states. Possible values are:
3480 • admin_down
3482 • down
3484 • init
3486 • up
3488
3490 This table is primarily used to learn the MACs observed on a VIF which
3491 belongs to a Logical_Switch_Port record in OVN_Northbound whose port
3492 security is disabled and ’unknown’ address set. If port security is
3493 disabled on a Logical_Switch_Port record, OVN should allow traffic with
3494 any source mac from the VIF. This table will be used to deliver a
3495 packet to the VIF, If a packet’s eth.dst is learnt.
3496 Summary:
3498 mac string
3499 dp_key integer, in range 1 to 16,777,215
3500 port_key integer, in range 1 to 16,777,215
3501 Details:
3503 mac: string
3504 The learnt mac address.
3505 dp_key: integer, in range 1 to 16,777,215
3507 The key of the datapath on which this FDB was learnt.
3508 port_key: integer, in range 1 to 16,777,215
3510 The key of the port binding on which this FDB was learnt.
3511Open vSwitch 21.03.1 DB Schema 20.16.1 ovn-sb(5)