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 Static_MAC_Binding
164 IP to MAC bindings
165
167 Southbound configuration for an OVN system. This table must have ex‐
168 actly one row.
169 Summary:
171 Status:
172 nb_cfg integer
173 Common Columns:
174 external_ids map of string-string pairs
175 options map of string-string pairs
176 Common options:
177 options map of string-string pairs
178 Options for configuring BFD:
179 options : bfd-min-rx optional string
180 options : bfd-decay-min-rx
181 optional string
182 options : bfd-min-tx optional string
183 options : bfd-mult optional string
184 Options for configuring Load Balancers:
185 options : lb_hairpin_use_ct_mark
186 optional string
187 Connection Options:
188 connections set of Connections
189 ssl optional SSL
190 Security Configurations:
191 ipsec boolean
192 Details:
194 Status:
195 This column allow a client to track the overall configuration state of
197 the system.
198 nb_cfg: integer
200 Sequence number for the configuration. When a CMS or ovn-nbctl
201 updates the northbound database, it increments the nb_cfg column
202 in the NB_Global table in the northbound database. In turn, when
203 ovn-northd updates the southbound database to bring it up to
204 date with these changes, it updates this column to the same
205 value.
206 Common Columns:
208 external_ids: map of string-string pairs
210 See External IDs at the beginning of this document.
211 options: map of string-string pairs
213 Common options:
215 options: map of string-string pairs
217 This column provides general key/value settings. The supported
218 options are described individually below.
219 Options for configuring BFD:
221 These options apply when ovn-controller configures BFD on tunnels in‐
223 terfaces.
224 options : bfd-min-rx: optional string
226 BFD option min-rx value to use when configuring BFD on tunnel
227 interfaces.
228 options : bfd-decay-min-rx: optional string
230 BFD option decay-min-rx value to use when configuring BFD on
231 tunnel interfaces.
232 options : bfd-min-tx: optional string
234 BFD option min-tx value to use when configuring BFD on tunnel
235 interfaces.
236 options : bfd-mult: optional string
238 BFD option mult value to use when configuring BFD on tunnel in‐
239 terfaces.
240 Options for configuring Load Balancers:
242 These options apply when ovn-controller configures load balancer re‐
244 lated flows.
245 options : lb_hairpin_use_ct_mark: optional string
247 By default this option is turned on (even if not present in the
248 database) unless its value is explicitly set to false. This
249 value is automatically set to false by ovn-northd when action
250 ct_lb_mark cannot be used for new load balancer sessions and ac‐
251 tion ct_lb will be used instead. ovn-controller then knows that
252 it should check ct_label.natted to detect load balanced traffic.
253 Connection Options:
255 connections: set of Connections
257 Database clients to which the Open vSwitch database server
258 should connect or on which it should listen, along with options
259 for how these connections should be configured. See the Connec‐
260 tion table for more information.
261 ssl: optional SSL
263 Global SSL configuration.
264 Security Configurations:
266 ipsec: boolean
268 Tunnel encryption configuration. If this column is set to be
269 true, all OVN tunnels will be encrypted with IPsec.
270
272 Each row in this table represents a hypervisor or gateway (a chassis)
273 in the physical network. Each chassis, via ovn-controller/ovn-con‐
274 troller-vtep, adds and updates its own row, and keeps a copy of the re‐
275 maining rows to determine how to reach other hypervisors.
276 When a chassis shuts down gracefully, it should remove its own row.
278 (This is not critical because resources hosted on the chassis are
279 equally unreachable regardless of whether the row is present.) If a
280 chassis shuts down permanently without removing its row, some kind of
281 manual or automatic cleanup is eventually needed; we can devise a
282 process for that as necessary.
283 Summary:
285 name string (must be unique within table)
286 hostname string
287 nb_cfg integer
288 other_config : ovn-bridge-mappings
289 optional string
290 other_config : datapath-type optional string
291 other_config : iface-types optional string
292 other_config : ovn-cms-options
293 optional string
294 other_config : is-interconn optional string
295 other_config : is-remote optional string
296 transport_zones set of strings
297 other_config : ovn-chassis-mac-mappings
298 optional string
299 other_config : port-up-notif optional string
300 Common Columns:
301 external_ids map of string-string pairs
302 Encapsulation Configuration:
303 encaps set of 1 or more Encaps
304 Gateway Configuration:
305 vtep_logical_switches set of strings
306 Details:
308 name: string (must be unique within table)
309 OVN does not prescribe a particular format for chassis names.
310 ovn-controller populates this column using external_ids:system-
311 id in the Open_vSwitch database’s Open_vSwitch table. ovn-con‐
312 troller-vtep populates this column with name in the hard‐
313 ware_vtep database’s Physical_Switch table.
314 hostname: string
316 The hostname of the chassis, if applicable. ovn-controller will
317 populate this column with the hostname of the host it is running
318 on. ovn-controller-vtep will leave this column empty.
319 nb_cfg: integer
321 Deprecated. This column is replaced by the nb_cfg column of the
322 Chassis_Private table.
323 other_config : ovn-bridge-mappings: optional string
325 ovn-controller populates this key with the set of bridge map‐
326 pings it has been configured to use. Other applications should
327 treat this key as read-only. See ovn-controller(8) for more in‐
328 formation.
329 other_config : datapath-type: optional string
331 ovn-controller populates this key with the datapath type config‐
332 ured in the datapath_type column of the Open_vSwitch database’s
333 Bridge table. Other applications should treat this key as read-
334 only. See ovn-controller(8) for more information.
335 other_config : iface-types: optional string
337 ovn-controller populates this key with the interface types con‐
338 figured in the iface_types column of the Open_vSwitch database’s
339 Open_vSwitch table. Other applications should treat this key as
340 read-only. See ovn-controller(8) for more information.
341 other_config : ovn-cms-options: optional string
343 ovn-controller populates this key with the set of options con‐
344 figured in the external_ids:ovn-cms-options column of the
345 Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
346 troller(8) for more information.
347 other_config : is-interconn: optional string
349 ovn-controller populates this key with the setting configured in
350 the external_ids:ovn-is-interconn column of the Open_vSwitch
351 database’s Open_vSwitch table. If set to true, the chassis is
352 used as an interconnection gateway. See ovn-controller(8) for
353 more information.
354 other_config : is-remote: optional string
356 ovn-ic set this key to true for remote interconnection gateway
357 chassises learned from the interconnection southbound database.
358 See ovn-ic(8) for more information.
359 transport_zones: set of strings
361 ovn-controller populates this key with the transport zones con‐
362 figured in the external_ids:ovn-transport-zones column of the
363 Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
364 troller(8) for more information.
365 other_config : ovn-chassis-mac-mappings: optional string
367 ovn-controller populates this key with the set of options con‐
368 figured in the external_ids:ovn-chassis-mac-mappings column of
369 the Open_vSwitch database’s Open_vSwitch table. See ovn-con‐
370 troller(8) for more information.
371 other_config : port-up-notif: optional string
373 ovn-controller populates this key with true when it supports
374 Port_Binding.up.
375 Common Columns:
377 The overall purpose of these columns is described under Common Columns
379 at the beginning of this document.
380 external_ids: map of string-string pairs
382 Encapsulation Configuration:
384 OVN uses encapsulation to transmit logical dataplane packets between
386 chassis.
387 encaps: set of 1 or more Encaps
389 Points to supported encapsulation configurations to transmit
390 logical dataplane packets to this chassis. Each entry is a Encap
391 record that describes the configuration.
392 Gateway Configuration:
394 A gateway is a chassis that forwards traffic between the OVN-managed
396 part of a logical network and a physical VLAN, extending a tunnel-based
397 logical network into a physical network. Gateways are typically dedi‐
398 cated nodes that do not host VMs and will be controlled by ovn-con‐
399 troller-vtep.
400 vtep_logical_switches: set of strings
402 Stores all VTEP logical switch names connected by this gateway
403 chassis. The Port_Binding table entry with options:vtep-physi‐
404 cal-switch equal Chassis name, and options:vtep-logical-switch
405 value in Chassis vtep_logical_switches, will be associated with
406 this Chassis.
407
409 Each row in this table maintains per chassis private data that are ac‐
410 cessed only by the owning chassis (write only) and ovn-northd, not by
411 any other chassis. These data are stored in this separate table instead
412 of the Chassis table for performance considerations: the rows in this
413 table can be conditionally monitored by chassises so that each chassis
414 only get update notifications for its own row, to avoid unnecessary
415 chassis private data update flooding in a large scale deployment.
416 Summary:
418 name string (must be unique within table)
419 chassis optional weak reference to Chassis
420 nb_cfg integer
421 nb_cfg_timestamp integer
422 Common Columns:
423 external_ids map of string-string pairs
424 Details:
426 name: string (must be unique within table)
427 The name of the chassis that owns these chassis-private data.
428 chassis: optional weak reference to Chassis
430 The reference to Chassis table for the chassis that owns these
431 chassis-private data.
432 nb_cfg: integer
434 Sequence number for the configuration. When ovn-controller up‐
435 dates the configuration of a chassis from the contents of the
436 southbound database, it copies nb_cfg from the SB_Global table
437 into this column.
438 nb_cfg_timestamp: integer
440 The timestamp when ovn-controller finishes processing the change
441 corresponding to nb_cfg.
442 Common Columns:
444 The overall purpose of these columns is described under Common Columns
446 at the beginning of this document.
447 external_ids: map of string-string pairs
449
451 The encaps column in the Chassis table refers to rows in this table to
452 identify how OVN may transmit logical dataplane packets to this chas‐
453 sis. Each chassis, via ovn-controller(8) or ovn-controller-vtep(8),
454 adds and updates its own rows and keeps a copy of the remaining rows to
455 determine how to reach other chassis.
456 Summary:
458 type string, one of geneve, stt, or vxlan
459 options map of string-string pairs
460 options : csum optional string, either true or false
461 options : dst_port optional string, containing an integer
462 ip string
463 chassis_name string
464 Details:
466 type: string, one of geneve, stt, or vxlan
467 The encapsulation to use to transmit packets to this chassis.
468 Hypervisors must use either geneve or stt. Gateways may use
469 vxlan, geneve, or stt.
470 options: map of string-string pairs
472 Options for configuring the encapsulation, which may be type
473 specific.
474 options : csum: optional string, either true or false
476 csum indicates whether this chassis can transmit and receive
477 packets that include checksums with reasonable performance. It
478 hints to senders transmitting data to this chassis that they
479 should use checksums to protect OVN metadata. ovn-controller
480 populates this key with the value defined in external_ids:ovn-
481 encap-csum column of the Open_vSwitch database’s Open_vSwitch
482 table. Other applications should treat this key as read-only.
483 See ovn-controller(8) for more information.
484 In terms of performance, checksumming actually significantly in‐
486 creases throughput in most common cases when running on Linux
487 based hosts without NICs supporting encapsulation hardware off‐
488 load (around 60% for bulk traffic). The reason is that generally
489 all NICs are capable of offloading transmitted and received
490 TCP/UDP checksums (viewed as ordinary data packets and not as
491 tunnels). The benefit comes on the receive side where the vali‐
492 dated outer checksum can be used to additionally validate an in‐
493 ner checksum (such as TCP), which in turn allows aggregation of
494 packets to be more efficiently handled by the rest of the stack.
495 Not all devices see such a benefit. The most notable exception
497 is hardware VTEPs. These devices are designed to not buffer en‐
498 tire packets in their switching engines and are therefore unable
499 to efficiently compute or validate full packet checksums. In ad‐
500 dition certain versions of the Linux kernel are not able to
501 fully take advantage of encapsulation NIC offloads in the pres‐
502 ence of checksums. (This is actually a pretty narrow corner case
503 though: earlier versions of Linux don’t support encapsulation
504 offloads at all and later versions support both offloads and
505 checksums well.)
506 csum defaults to false for hardware VTEPs and true for all other
508 cases.
509 This option applies to geneve and vxlan encapsulations.
511 options : dst_port: optional string, containing an integer
513 If set, overrides the UDP (for geneve and vxlan) or TCP (for
514 stt) destination port.
515 ip: string
517 The IPv4 address of the encapsulation tunnel endpoint.
518 chassis_name: string
520 The name of the chassis that created this encap.
521
523 This table contains address sets synced from the Address_Set table in
524 the OVN_Northbound database and address sets generated from the
525 Port_Group table in the OVN_Northbound database.
526 See the documentation for the Address_Set table and Port_Group table in
528 the OVN_Northbound database for details.
529 Summary:
531 name string (must be unique within table)
532 addresses set of strings
533 Details:
535 name: string (must be unique within table)
536 addresses: set of strings
538
540 This table contains names for the logical switch ports in the
541 OVN_Northbound database that belongs to the same group that is defined
542 in Port_Group in the OVN_Northbound database.
543 Summary:
545 name string (must be unique within table)
546 ports set of strings
547 Details:
549 name: string (must be unique within table)
550 ports: set of strings
552
554 Each row in this table represents one logical flow. ovn-northd popu‐
555 lates this table with logical flows that implement the L2 and L3
556 topologies specified in the OVN_Northbound database. Each hypervisor,
557 via ovn-controller, translates the logical flows into OpenFlow flows
558 specific to its hypervisor and installs them into Open vSwitch.
559 Logical flows are expressed in an OVN-specific format, described here.
561 A logical datapath flow is much like an OpenFlow flow, except that the
562 flows are written in terms of logical ports and logical datapaths in‐
563 stead of physical ports and physical datapaths. Translation between
564 logical and physical flows helps to ensure isolation between logical
565 datapaths. (The logical flow abstraction also allows the OVN central‐
566 ized components to do less work, since they do not have to separately
567 compute and push out physical flows to each chassis.)
568 The default action when no flow matches is to drop packets.
570 Architectural Logical Life Cycle of a Packet
572 This following description focuses on the life cycle of a packet
574 through a logical datapath, ignoring physical details of the implemen‐
575 tation. Please refer to Architectural Physical Life Cycle of a Packet
576 in ovn-architecture(7) for the physical information.
577 The description here is written as if OVN itself executes these steps,
579 but in fact OVN (that is, ovn-controller) programs Open vSwitch, via
580 OpenFlow and OVSDB, to execute them on its behalf.
581 At a high level, OVN passes each packet through the logical datapath’s
583 logical ingress pipeline, which may output the packet to one or more
584 logical port or logical multicast groups. For each such logical output
585 port, OVN passes the packet through the datapath’s logical egress pipe‐
586 line, which may either drop the packet or deliver it to the destina‐
587 tion. Between the two pipelines, outputs to logical multicast groups
588 are expanded into logical ports, so that the egress pipeline only pro‐
589 cesses a single logical output port at a time. Between the two pipe‐
590 lines is also where, when necessary, OVN encapsulates a packet in a
591 tunnel (or tunnels) to transmit to remote hypervisors.
592 In more detail, to start, OVN searches the Logical_Flow table for a row
594 with correct logical_datapath or a logical_dp_group, a pipeline of
595 ingress, a table_id of 0, and a match that is true for the packet. If
596 none is found, OVN drops the packet. If OVN finds more than one, it
597 chooses the match with the highest priority. Then OVN executes each of
598 the actions specified in the row’s actions column, in the order speci‐
599 fied. Some actions, such as those to modify packet headers, require no
600 further details. The next and output actions are special.
601 The next action causes the above process to be repeated recursively,
603 except that OVN searches for table_id of 1 instead of 0. Similarly, any
604 next action in a row found in that table would cause a further search
605 for a table_id of 2, and so on. When recursive processing completes,
606 flow control returns to the action following next.
607 The output action also introduces recursion. Its effect depends on the
609 current value of the outport field. Suppose outport designates a logi‐
610 cal port. First, OVN compares inport to outport; if they are equal, it
611 treats the output as a no-op by default. In the common case, where they
612 are different, the packet enters the egress pipeline. This transition
613 to the egress pipeline discards register data, e.g. reg0 ... reg9 and
614 connection tracking state, to achieve uniform behavior regardless of
615 whether the egress pipeline is on a different hypervisor (because reg‐
616 isters aren’t preserve across tunnel encapsulation).
617 To execute the egress pipeline, OVN again searches the Logical_Flow ta‐
619 ble for a row with correct logical_datapath or a logical_dp_group, a
620 table_id of 0, a match that is true for the packet, but now looking for
621 a pipeline of egress. If no matching row is found, the output becomes a
622 no-op. Otherwise, OVN executes the actions for the matching flow (which
623 is chosen from multiple, if necessary, as already described).
624 In the egress pipeline, the next action acts as already described, ex‐
626 cept that it, of course, searches for egress flows. The output action,
627 however, now directly outputs the packet to the output port (which is
628 now fixed, because outport is read-only within the egress pipeline).
629 The description earlier assumed that outport referred to a logical
631 port. If it instead designates a logical multicast group, then the de‐
632 scription above still applies, with the addition of fan-out from the
633 logical multicast group to each logical port in the group. For each
634 member of the group, OVN executes the logical pipeline as described,
635 with the logical output port replaced by the group member.
636 Pipeline Stages
638 ovn-northd populates the Logical_Flow table with the logical flows de‐
640 scribed in detail in ovn-northd(8).
641 Summary:
643 logical_datapath optional Datapath_Binding
644 logical_dp_group optional Logical_DP_Group
645 pipeline string, either egress or ingress
646 table_id integer, in range 0 to 32
647 priority integer, in range 0 to 65,535
648 match string
649 actions string
650 tags map of string-string pairs
651 controller_meter optional string
652 external_ids : stage-name optional string
653 external_ids : stage-hint optional string, containing an uuid
654 external_ids : source optional string
655 Common Columns:
656 external_ids map of string-string pairs
657 Details:
659 logical_datapath: optional Datapath_Binding
660 The logical datapath to which the logical flow belongs.
661 logical_dp_group: optional Logical_DP_Group
663 The group of logical datapaths to which the logical flow be‐
664 longs. This means that the same logical flow belongs to all
665 datapaths in a group.
666 pipeline: string, either egress or ingress
668 The primary flows used for deciding on a packet’s destination
669 are the ingress flows. The egress flows implement ACLs. See Log‐
670 ical Life Cycle of a Packet, above, for details.
671 table_id: integer, in range 0 to 32
673 The stage in the logical pipeline, analogous to an OpenFlow ta‐
674 ble number.
675 priority: integer, in range 0 to 65,535
677 The flow’s priority. Flows with numerically higher priority take
678 precedence over those with lower. If two logical datapath flows
679 with the same priority both match, then the one actually applied
680 to the packet is undefined.
681 match: string
683 A matching expression. OVN provides a superset of OpenFlow
684 matching capabilities, using a syntax similar to Boolean expres‐
685 sions in a programming language.
686 The most important components of match expression are compar‐
688 isons between symbols and constants, e.g. ip4.dst ==
689 192.168.0.1, ip.proto == 6, arp.op == 1, eth.type == 0x800. The
690 logical AND operator && and logical OR operator || can combine
691 comparisons into a larger expression.
692 Matching expressions also support parentheses for grouping, the
694 logical NOT prefix operator !, and literals 0 and 1 to express
695 ``false’’ or ``true,’’ respectively. The latter is useful by it‐
696 self as a catch-all expression that matches every packet.
697 Match expressions also support a kind of function syntax. The
699 following functions are supported:
700 is_chassis_resident(lport)
702 Evaluates to true on a chassis on which logical port
703 lport (a quoted string) resides, and to false elsewhere.
704 This function was introduced in OVN 2.7.
705 Symbols
707 Type. Symbols have integer or string type. Integer symbols have
709 a width in bits.
710 Kinds. There are three kinds of symbols:
712 • Fields. A field symbol represents a packet header or
714 metadata field. For example, a field named vlan.tci might
715 represent the VLAN TCI field in a packet.
716 A field symbol can have integer or string type. Integer
718 fields can be nominal or ordinal (see Level of Measure‐
719 ment, below).
720 • Subfields. A subfield represents a subset of bits from a
722 larger field. For example, a field vlan.vid might be de‐
723 fined as an alias for vlan.tci[0..11]. Subfields are pro‐
724 vided for syntactic convenience, because it is always
725 possible to instead refer to a subset of bits from a
726 field directly.
727 Only ordinal fields (see Level of Measurement, below) may
729 have subfields. Subfields are always ordinal.
730 • Predicates. A predicate is shorthand for a Boolean ex‐
732 pression. Predicates may be used much like 1-bit fields.
733 For example, ip4 might expand to eth.type == 0x800. Pred‐
734 icates are provided for syntactic convenience, because it
735 is always possible to instead specify the underlying ex‐
736 pression directly.
737 A predicate whose expansion refers to any nominal field
739 or predicate (see Level of Measurement, below) is nomi‐
740 nal; other predicates have Boolean level of measurement.
741 Level of Measurement. See
743 http://en.wikipedia.org/wiki/Level_of_measurement for the sta‐
744 tistical concept on which this classification is based. There
745 are three levels:
746 • Ordinal. In statistics, ordinal values can be ordered on
748 a scale. OVN considers a field (or subfield) to be ordi‐
749 nal if its bits can be examined individually. This is
750 true for the OpenFlow fields that OpenFlow or Open
751 vSwitch makes ``maskable.’’
752 Any use of a ordinal field may specify a single bit or a
754 range of bits, e.g. vlan.tci[13..15] refers to the PCP
755 field within the VLAN TCI, and eth.dst[40] refers to the
756 multicast bit in the Ethernet destination address.
757 OVN supports all the usual arithmetic relations (==, !=,
759 <, <=, >, and >=) on ordinal fields and their subfields,
760 because OVN can implement these in OpenFlow and Open
761 vSwitch as collections of bitwise tests.
762 • Nominal. In statistics, nominal values cannot be usefully
764 compared except for equality. This is true of OpenFlow
765 port numbers, Ethernet types, and IP protocols are exam‐
766 ples: all of these are just identifiers assigned arbi‐
767 trarily with no deeper meaning. In OpenFlow and Open
768 vSwitch, bits in these fields generally aren’t individu‐
769 ally addressable.
770 OVN only supports arithmetic tests for equality on nomi‐
772 nal fields, because OpenFlow and Open vSwitch provide no
773 way for a flow to efficiently implement other comparisons
774 on them. (A test for inequality can be sort of built out
775 of two flows with different priorities, but OVN matching
776 expressions always generate flows with a single prior‐
777 ity.)
778 String fields are always nominal.
780 • Boolean. A nominal field that has only two values, 0 and
782 1, is somewhat exceptional, since it is easy to support
783 both equality and inequality tests on such a field: ei‐
784 ther one can be implemented as a test for 0 or 1.
785 Only predicates (see above) have a Boolean level of mea‐
787 surement.
788 This isn’t a standard level of measurement.
790 Prerequisites. Any symbol can have prerequisites, which are ad‐
792 ditional condition implied by the use of the symbol. For exam‐
793 ple, For example, icmp4.type symbol might have prerequisite
794 icmp4, which would cause an expression icmp4.type == 0 to be in‐
795 terpreted as icmp4.type == 0 && icmp4, which would in turn ex‐
796 pand to icmp4.type == 0 && eth.type == 0x800 && ip4.proto == 1
797 (assuming icmp4 is a predicate defined as suggested under Types
798 above).
799 Relational operators
801 All of the standard relational operators ==, !=, <, <=, >, and
803 >= are supported. Nominal fields support only == and !=, and
804 only in a positive sense when outer ! are taken into account,
805 e.g. given string field inport, inport == "eth0" and !(inport !=
806 "eth0") are acceptable, but not inport != "eth0".
807 The implementation of == (or != when it is negated), is more ef‐
809 ficient than that of the other relational operators.
810 Constants
812 Integer constants may be expressed in decimal, hexadecimal pre‐
814 fixed by 0x, or as dotted-quad IPv4 addresses, IPv6 addresses in
815 their standard forms, or Ethernet addresses as colon-separated
816 hex digits. A constant in any of these forms may be followed by
817 a slash and a second constant (the mask) in the same form, to
818 form a masked constant. IPv4 and IPv6 masks may be given as in‐
819 tegers, to express CIDR prefixes.
820 String constants have the same syntax as quoted strings in JSON
822 (thus, they are Unicode strings).
823 Some operators support sets of constants written inside curly
825 braces { ... }. Commas between elements of a set, and after the
826 last elements, are optional. With ==, ``field == { constant1,
827 constant2, ... }’’ is syntactic sugar for ``field == constant1
828 || field == constant2 || .... Similarly, ``field != { constant1,
829 constant2, ... }’’ is equivalent to ``field != constant1 &&
830 field != constant2 && ...’’.
831 You may refer to a set of IPv4, IPv6, or MAC addresses stored in
833 the Address_Set table by its name. An Address_Set with a name of
834 set1 can be referred to as $set1.
835 You may refer to a group of logical switch ports stored in the
837 Port_Group table by its name. An Port_Group with a name of
838 port_group1 can be referred to as @port_group1.
839 Additionally, you may refer to the set of addresses belonging to
841 a group of logical switch ports stored in the Port_Group table
842 by its name followed by a suffix ’_ip4’/’_ip6’. The IPv4 address
843 set of a Port_Group with a name of port_group1 can be referred
844 to as $port_group1_ip4, and the IPv6 address set of the same
845 Port_Group can be referred to as $port_group1_ip6
846 Miscellaneous
848 Comparisons may name the symbol or the constant first, e.g.
850 tcp.src == 80 and 80 == tcp.src are both acceptable.
851 Tests for a range may be expressed using a syntax like 1024 <=
853 tcp.src <= 49151, which is equivalent to 1024 <= tcp.src &&
854 tcp.src <= 49151.
855 For a one-bit field or predicate, a mention of its name is
857 equivalent to symobl == 1, e.g. vlan.present is equivalent to
858 vlan.present == 1. The same is true for one-bit subfields, e.g.
859 vlan.tci[12]. There is no technical limitation to implementing
860 the same for ordinal fields of all widths, but the implementa‐
861 tion is expensive enough that the syntax parser requires writing
862 an explicit comparison against zero to make mistakes less
863 likely, e.g. in tcp.src != 0 the comparison against 0 is re‐
864 quired.
865 Operator precedence is as shown below, from highest to lowest.
867 There are two exceptions where parentheses are required even
868 though the table would suggest that they are not: && and || re‐
869 quire parentheses when used together, and ! requires parentheses
870 when applied to a relational expression. Thus, in (eth.type ==
871 0x800 || eth.type == 0x86dd) && ip.proto == 6 or !(arp.op == 1),
872 the parentheses are mandatory.
873 • ()
875 • == != < <= > >=
877 • !
879 • && ||
881 Comments may be introduced by //, which extends to the next new-
883 line. Comments within a line may be bracketed by /* and */. Mul‐
884 tiline comments are not supported.
885 Symbols
887 Most of the symbols below have integer type. Only inport and
889 outport have string type. inport names a logical port. Thus, its
890 value is a logical_port name from the Port_Binding table. out‐
891 port may name a logical port, as inport, or a logical multicast
892 group defined in the Multicast_Group table. For both symbols,
893 only names within the flow’s logical datapath may be used.
894 The regX symbols are 32-bit integers. The xxregX symbols are
896 128-bit integers, which overlay four of the 32-bit registers:
897 xxreg0 overlays reg0 through reg3, with reg0 supplying the most-
898 significant bits of xxreg0 and reg3 the least-significant.
899 xxreg1 similarly overlays reg4 through reg7.
900 • reg0...reg9
902 • xxreg0 xxreg1
904 • inport outport
906 • flags.loopback
908 • pkt.mark
910 • eth.src eth.dst eth.type
912 • vlan.tci vlan.vid vlan.pcp vlan.present
914 • ip.proto ip.dscp ip.ecn ip.ttl ip.frag
916 • ip4.src ip4.dst
918 • ip6.src ip6.dst ip6.label
920 • arp.op arp.spa arp.tpa arp.sha arp.tha
922 • tcp.src tcp.dst tcp.flags
924 • udp.src udp.dst
926 • sctp.src sctp.dst
928 • icmp4.type icmp4.code
930 • icmp6.type icmp6.code
932 • nd.target nd.sll nd.tll
934 • ct_mark ct_label
936 • ct_state, which has several Boolean subfields. The
938 ct_next action initializes the following subfields:
939 • ct.trk: Always set to true by ct_next to indicate
941 that connection tracking has taken place. All
942 other ct subfields have ct.trk as a prerequisite.
943 • ct.new: True for a new flow
945 • ct.est: True for an established flow
947 • ct.rel: True for a related flow
949 • ct.rpl: True for a reply flow
951 • ct.inv: True for a connection entry in a bad state
953 The ct_dnat, ct_snat, and ct_lb actions initialize the
955 following subfields:
956 • ct.dnat: True for a packet whose destination IP
958 address has been changed.
959 • ct.snat: True for a packet whose source IP address
961 has been changed.
962 The following predicates are supported:
964 • eth.bcast expands to eth.dst == ff:ff:ff:ff:ff:ff
966 • eth.mcast expands to eth.dst[40]
968 • vlan.present expands to vlan.tci[12]
970 • ip4 expands to eth.type == 0x800
972 • ip4.src_mcast expands to ip4.src[28..31] == 0xe
974 • ip4.mcast expands to ip4.dst[28..31] == 0xe
976 • ip6 expands to eth.type == 0x86dd
978 • ip expands to ip4 || ip6
980 • icmp4 expands to ip4 && ip.proto == 1
982 • icmp6 expands to ip6 && ip.proto == 58
984 • icmp expands to icmp4 || icmp6
986 • ip.is_frag expands to ip.frag[0]
988 • ip.later_frag expands to ip.frag[1]
990 • ip.first_frag expands to ip.is_frag && !ip.later_frag
992 • arp expands to eth.type == 0x806
994 • nd expands to icmp6.type == {135, 136} && icmp6.code == 0
996 && ip.ttl == 255
997 • nd_ns expands to icmp6.type == 135 && icmp6.code == 0 &&
999 ip.ttl == 255
1000 • nd_na expands to icmp6.type == 136 && icmp6.code == 0 &&
1002 ip.ttl == 255
1003 • nd_rs expands to icmp6.type == 133 && icmp6.code == 0 &&
1005 ip.ttl == 255
1006 • nd_ra expands to icmp6.type == 134 && icmp6.code == 0 &&
1008 ip.ttl == 255
1009 • tcp expands to ip.proto == 6
1011 • udp expands to ip.proto == 17
1013 • sctp expands to ip.proto == 132
1015 actions: string
1017 Logical datapath actions, to be executed when the logical flow
1018 represented by this row is the highest-priority match.
1019 Actions share lexical syntax with the match column. An empty set
1021 of actions (or one that contains just white space or comments),
1022 or a set of actions that consists of just drop;, causes the
1023 matched packets to be dropped. Otherwise, the column should con‐
1024 tain a sequence of actions, each terminated by a semicolon.
1025 The following actions are defined:
1027 output;
1029 In the ingress pipeline, this action executes the egress
1030 pipeline as a subroutine. If outport names a logical
1031 port, the egress pipeline executes once; if it is a mul‐
1032 ticast group, the egress pipeline runs once for each log‐
1033 ical port in the group.
1034 In the egress pipeline, this action performs the actual
1036 output to the outport logical port. (In the egress pipe‐
1037 line, outport never names a multicast group.)
1038 By default, output to the input port is implicitly
1040 dropped, that is, output becomes a no-op if outport ==
1041 inport. Occasionally it may be useful to override this
1042 behavior, e.g. to send an ARP reply to an ARP request; to
1043 do so, use flags.loopback = 1 to allow the packet to
1044 "hair-pin" back to the input port.
1045 next;
1047 next(table);
1048 next(pipeline=pipeline, table=table);
1049 Executes the given logical datapath table in pipeline as a
1050 subroutine. The default table is just after the current
1051 one. If pipeline is specified, it may be ingress or egress;
1052 the default pipeline is the one currently executing. Ac‐
1053 tions in the both ingress and egress pipeline can use next
1054 to jump across the other pipeline. Actions in the ingress
1055 pipeline should use next to jump into the specific table of
1056 egress pipeline only if it is certain that the packets are
1057 local and not tunnelled and wants to skip certain stages in
1058 the packet processing.
1059 field = constant;
1061 Sets data or metadata field field to constant value con‐
1062 stant, e.g. outport = "vif0"; to set the logical output
1063 port. To set only a subset of bits in a field, specify a
1064 subfield for field or a masked constant, e.g. one may use
1065 vlan.pcp[2] = 1; or vlan.pcp = 4/4; to set the most signif‐
1066 icant bit of the VLAN PCP.
1067 Assigning to a field with prerequisites implicitly adds
1069 those prerequisites to match; thus, for example, a flow
1070 that sets tcp.dst applies only to TCP flows, regardless of
1071 whether its match mentions any TCP field.
1072 Not all fields are modifiable (e.g. eth.type and ip.proto
1074 are read-only), and not all modifiable fields may be par‐
1075 tially modified (e.g. ip.ttl must assigned as a whole). The
1076 outport field is modifiable in the ingress pipeline but not
1077 in the egress pipeline.
1078 ovn_field = constant;
1080 Sets OVN field ovn_field to constant value constant.
1081 OVN supports setting the values of certain fields which are
1083 not yet supported in OpenFlow to set or modify them.
1084 Below are the supported OVN fields:
1086 • icmp4.frag_mtu icmp6.frag_mtu
1088 This field sets the low-order 16 bits of the
1090 ICMP{4,6} header field that is labelled "unused" in
1091 the ICMP specification as defined in the RFC 1191
1092 with the value specified in constant.
1093 Eg. icmp4.frag_mtu = 1500;
1095 field1 = field2;
1097 Sets data or metadata field field1 to the value of data or
1098 metadata field field2, e.g. reg0 = ip4.src; copies ip4.src
1099 into reg0. To modify only a subset of a field’s bits, spec‐
1100 ify a subfield for field1 or field2 or both, e.g. vlan.pcp
1101 = reg0[0..2]; copies the least-significant bits of reg0
1102 into the VLAN PCP.
1103 field1 and field2 must be the same type, either both string
1105 or both integer fields. If they are both integer fields,
1106 they must have the same width.
1107 If field1 or field2 has prerequisites, they are added im‐
1109 plicitly to match. It is possible to write an assignment
1110 with contradictory prerequisites, such as ip4.src =
1111 ip6.src[0..31];, but the contradiction means that a logical
1112 flow with such an assignment will never be matched.
1113 field1 <-> field2;
1115 Similar to field1 = field2; except that the two values are
1116 exchanged instead of copied. Both field1 and field2 must
1117 modifiable.
1118 push(field);
1120 Push the value of field to the stack top.
1121 pop(field);
1123 Pop the stack top and store the value to field, which must
1124 be modifiable.
1125 ip.ttl--;
1127 Decrements the IPv4 or IPv6 TTL. If this would make the TTL
1128 zero or negative, then processing of the packet halts; no
1129 further actions are processed. (To properly handle such
1130 cases, a higher-priority flow should match on ip.ttl == {0,
1131 1};.)
1132 Prerequisite: ip
1134 ct_next;
1136 Apply connection tracking to the flow, initializing
1137 ct_state for matching in later tables. Automatically moves
1138 on to the next table, as if followed by next.
1139 As a side effect, IP fragments will be reassembled for
1141 matching. If a fragmented packet is output, then it will be
1142 sent with any overlapping fragments squashed. The connec‐
1143 tion tracking state is scoped by the logical port when the
1144 action is used in a flow for a logical switch, so overlap‐
1145 ping addresses may be used. To allow traffic related to the
1146 matched flow, execute ct_commit . Connection tracking state
1147 is scoped by the logical topology when the action is used
1148 in a flow for a router.
1149 It is possible to have actions follow ct_next, but they
1151 will not have access to any of its side-effects and is not
1152 generally useful.
1153 ct_commit { };
1155 ct_commit { ct_mark=value[/mask]; };
1156 ct_commit { ct_label=value[/mask]; };
1157 ct_commit { ct_mark=value[/mask]; ct_label=value[/mask]; };
1158 Commit the flow to the connection tracking entry associated
1159 with it by a previous call to ct_next. When
1160 ct_mark=value[/mask] and/or ct_label=value[/mask] are sup‐
1161 plied, ct_mark and/or ct_label will be set to the values
1162 indicated by value[/mask] on the connection tracking entry.
1163 ct_mark is a 32-bit field. ct_label is a 128-bit field. The
1164 value[/mask] should be specified in hex string if more than
1165 64bits are to be used. Registers and other named fields can
1166 be used for value. ct_mark and ct_label may be sub-ad‐
1167 dressed in order to have specific bits set.
1168 Note that if you want processing to continue in the next
1170 table, you must execute the next action after ct_commit.
1171 You may also leave out next which will commit connection
1172 tracking state, and then drop the packet. This could be
1173 useful for setting ct_mark on a connection tracking entry
1174 before dropping a packet, for example.
1175 ct_dnat;
1177 ct_dnat(IP);
1178 ct_dnat sends the packet through the DNAT zone in connec‐
1179 tion tracking table to unDNAT any packet that was DNATed in
1180 the opposite direction. The packet is then automatically
1181 sent to to the next tables as if followed by next; action.
1182 The next tables will see the changes in the packet caused
1183 by the connection tracker.
1184 ct_dnat(IP) sends the packet through the DNAT zone to
1186 change the destination IP address of the packet to the one
1187 provided inside the parentheses and commits the connection.
1188 The packet is then automatically sent to the next tables as
1189 if followed by next; action. The next tables will see the
1190 changes in the packet caused by the connection tracker.
1191 ct_snat;
1193 ct_snat(IP);
1194 ct_snat sends the packet through the SNAT zone to unSNAT
1195 any packet that was SNATed in the opposite direction. The
1196 packet is automatically sent to the next tables as if fol‐
1197 lowed by the next; action. The next tables will see the
1198 changes in the packet caused by the connection tracker.
1199 ct_snat(IP) sends the packet through the SNAT zone to
1201 change the source IP address of the packet to the one pro‐
1202 vided inside the parenthesis and commits the connection.
1203 The packet is then automatically sent to the next tables as
1204 if followed by next; action. The next tables will see the
1205 changes in the packet caused by the connection tracker.
1206 ct_dnat_in_czone;
1208 ct_dnat_in_czone(IP);
1209 ct_dnat_in_czone sends the packet through the common NAT
1210 zone (used for both DNAT and SNAT) in connection tracking
1211 table to unDNAT any packet that was DNATed in the opposite
1212 direction. The packet is then automatically sent to to the
1213 next tables as if followed by next; action. The next tables
1214 will see the changes in the packet caused by the connection
1215 tracker.
1216 ct_dnat_in_czone(IP) sends the packet through the common
1218 NAT zone to change the destination IP address of the packet
1219 to the one provided inside the parentheses and commits the
1220 connection. The packet is then automatically sent to the
1221 next tables as if followed by next; action. The next tables
1222 will see the changes in the packet caused by the connection
1223 tracker.
1224 ct_snat_in_czone;
1226 ct_snat_in_czone(IP);
1227 ct_snat_in_czone sends the packet through the common NAT
1228 zone to unSNAT any packet that was SNATed in the opposite
1229 direction. The packet is automatically sent to the next ta‐
1230 bles as if followed by the next; action. The next tables
1231 will see the changes in the packet caused by the connection
1232 tracker.
1233 ct_snat_in_czone(IP) sends the packet\ through the common
1235 NAT zone to change the source IP address of the packet to
1236 the one provided inside the parenthesis and commits the
1237 connection. The packet is then automatically sent to the
1238 next tables as if followed by next; action. The next tables
1239 will see the changes in the packet caused by the connection
1240 tracker.
1241 ct_clear;
1243 Clears connection tracking state.
1244 clone { action; ... };
1246 Makes a copy of the packet being processed and executes
1247 each action on the copy. Actions following the clone ac‐
1248 tion, if any, apply to the original, unmodified packet.
1249 This can be used as a way to ``save and restore’’ the
1250 packet around a set of actions that may modify it and
1251 should not persist.
1252 arp { action; ... };
1254 Temporarily replaces the IPv4 packet being processed by an
1255 ARP packet and executes each nested action on the ARP
1256 packet. Actions following the arp action, if any, apply to
1257 the original, unmodified packet.
1258 The ARP packet that this action operates on is initialized
1260 based on the IPv4 packet being processed, as follows. These
1261 are default values that the nested actions will probably
1262 want to change:
1263 • eth.src unchanged
1265 • eth.dst unchanged
1267 • eth.type = 0x0806
1269 • arp.op = 1 (ARP request)
1271 • arp.sha copied from eth.src
1273 • arp.spa copied from ip4.src
1275 • arp.tha = 00:00:00:00:00:00
1277 • arp.tpa copied from ip4.dst
1279 The ARP packet has the same VLAN header, if any, as the IP
1281 packet it replaces.
1282 Prerequisite: ip4
1284 get_arp(P, A);
1286 Parameters: logical port string field P, 32-bit IP address
1287 field A.
1288 Looks up A in P’s mac binding table. If an entry is found,
1290 stores its Ethernet address in eth.dst, otherwise stores
1291 00:00:00:00:00:00 in eth.dst.
1292 Example: get_arp(outport, ip4.dst);
1294 put_arp(P, A, E);
1296 Parameters: logical port string field P, 32-bit IP address
1297 field A, 48-bit Ethernet address field E.
1298 Adds or updates the entry for IP address A in logical port
1300 P’s mac binding table, setting its Ethernet address to E.
1301 Example: put_arp(inport, arp.spa, arp.sha);
1303 R = lookup_arp(P, A, M);
1305 Parameters: logical port string field P, 32-bit IP address
1306 field A, 48-bit MAC address field M.
1307 Result: stored to a 1-bit subfield R.
1309 Looks up A and M in P’s mac binding table. If an entry is
1311 found, stores 1 in the 1-bit subfield R, else 0.
1312 Example: reg0[0] = lookup_arp(inport, arp.spa, arp.sha);
1314 R = lookup_arp_ip(P, A);
1316 Parameters: logical port string field P, 32-bit IP address
1317 field A.
1318 Result: stored to a 1-bit subfield R.
1320 Looks up A in P’s mac binding table. If an entry is found,
1322 stores 1 in the 1-bit subfield R, else 0.
1323 Example: reg0[0] = lookup_arp_ip(inport, arp.spa);
1325 P = get_fdb(A);
1327 Parameters:48-bit MAC address field A.
1328 Looks up A in fdb table. If an entry is found, stores the
1330 logical port key to the out parameter P.
1331 Example: outport = get_fdb(eth.src);
1333 put_fdb(P, A);
1335 Parameters: logical port string field P, 48-bit MAC address
1336 field A.
1337 Adds or updates the entry for Ethernet address A in fdb ta‐
1339 ble, setting its logical port key to P.
1340 Example: put_fdb(inport, arp.spa);
1342 R = lookup_fdb(P, A);
1344 Parameters: 48-bit MAC address field M, logical port string
1345 field P.
1346 Result: stored to a 1-bit subfield R.
1348 Looks up A in fdb table. If an entry is found and the the
1350 logical port key is P, P, stores 1 in the 1-bit subfield R,
1351 else 0.
1352 Example: reg0[0] = lookup_fdb(inport, eth.src);
1354 nd_ns { action; ... };
1356 Temporarily replaces the IPv6 packet being processed by an
1357 IPv6 Neighbor Solicitation packet and executes each nested
1358 action on the IPv6 NS packet. Actions following the nd_ns
1359 action, if any, apply to the original, unmodified packet.
1360 The IPv6 NS packet that this action operates on is initial‐
1362 ized based on the IPv6 packet being processed, as follows.
1363 These are default values that the nested actions will prob‐
1364 ably want to change:
1365 • eth.src unchanged
1367 • eth.dst set to IPv6 multicast MAC address
1369 • eth.type = 0x86dd
1371 • ip6.src copied from ip6.src
1373 • ip6.dst set to IPv6 Solicited-Node multicast address
1375 • icmp6.type = 135 (Neighbor Solicitation)
1377 • nd.target copied from ip6.dst
1379 The IPv6 NS packet has the same VLAN header, if any, as the
1381 IP packet it replaces.
1382 Prerequisite: ip6
1384 nd_na { action; ... };
1386 Temporarily replaces the IPv6 neighbor solicitation packet
1387 being processed by an IPv6 neighbor advertisement (NA)
1388 packet and executes each nested action on the NA packet.
1389 Actions following the nd_na action, if any, apply to the
1390 original, unmodified packet.
1391 The NA packet that this action operates on is initialized
1393 based on the IPv6 packet being processed, as follows. These
1394 are default values that the nested actions will probably
1395 want to change:
1396 • eth.dst exchanged with eth.src
1398 • eth.type = 0x86dd
1400 • ip6.dst copied from ip6.src
1402 • ip6.src copied from nd.target
1404 • icmp6.type = 136 (Neighbor Advertisement)
1406 • nd.target unchanged
1408 • nd.sll = 00:00:00:00:00:00
1410 • nd.tll copied from eth.dst
1412 The ND packet has the same VLAN header, if any, as the IPv6
1414 packet it replaces.
1415 Prerequisite: nd_ns
1417 nd_na_router { action; ... };
1419 Temporarily replaces the IPv6 neighbor solicitation packet
1420 being processed by an IPv6 neighbor advertisement (NA)
1421 packet, sets ND_NSO_ROUTER in the RSO flags and executes
1422 each nested action on the NA packet. Actions following the
1423 nd_na_router action, if any, apply to the original, unmodi‐
1424 fied packet.
1425 The NA packet that this action operates on is initialized
1427 based on the IPv6 packet being processed, as follows. These
1428 are default values that the nested actions will probably
1429 want to change:
1430 • eth.dst exchanged with eth.src
1432 • eth.type = 0x86dd
1434 • ip6.dst copied from ip6.src
1436 • ip6.src copied from nd.target
1438 • icmp6.type = 136 (Neighbor Advertisement)
1440 • nd.target unchanged
1442 • nd.sll = 00:00:00:00:00:00
1444 • nd.tll copied from eth.dst
1446 The ND packet has the same VLAN header, if any, as the IPv6
1448 packet it replaces.
1449 Prerequisite: nd_ns
1451 get_nd(P, A);
1453 Parameters: logical port string field P, 128-bit IPv6 ad‐
1454 dress field A.
1455 Looks up A in P’s mac binding table. If an entry is found,
1457 stores its Ethernet address in eth.dst, otherwise stores
1458 00:00:00:00:00:00 in eth.dst.
1459 Example: get_nd(outport, ip6.dst);
1461 put_nd(P, A, E);
1463 Parameters: logical port string field P, 128-bit IPv6 ad‐
1464 dress field A, 48-bit Ethernet address field E.
1465 Adds or updates the entry for IPv6 address A in logical
1467 port P’s mac binding table, setting its Ethernet address to
1468 E.
1469 Example: put_nd(inport, nd.target, nd.tll);
1471 R = lookup_nd(P, A, M);
1473 Parameters: logical port string field P, 128-bit IP address
1474 field A, 48-bit MAC address field M.
1475 Result: stored to a 1-bit subfield R.
1477 Looks up A and M in P’s mac binding table. If an entry is
1479 found, stores 1 in the 1-bit subfield R, else 0.
1480 Example: reg0[0] = lookup_nd(inport, ip6.src, eth.src);
1482 R = lookup_nd_ip(P, A);
1484 Parameters: logical port string field P, 128-bit IP address
1485 field A.
1486 Result: stored to a 1-bit subfield R.
1488 Looks up A in P’s mac binding table. If an entry is found,
1490 stores 1 in the 1-bit subfield R, else 0.
1491 Example: reg0[0] = lookup_nd_ip(inport, ip6.src);
1493 R = put_dhcp_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1495 Parameters: one or more DHCP option/value pairs, which must
1496 include an offerip option (with code 0).
1497 Result: stored to a 1-bit subfield R.
1499 Valid only in the ingress pipeline.
1501 When this action is applied to a DHCP request packet
1503 (DHCPDISCOVER or DHCPREQUEST), it changes the packet into a
1504 DHCP reply (DHCPOFFER or DHCPACK, respectively), replaces
1505 the options by those specified as parameters, and stores 1
1506 in R.
1507 When this action is applied to a non-DHCP packet or a DHCP
1509 packet that is not DHCPDISCOVER or DHCPREQUEST, it leaves
1510 the packet unchanged and stores 0 in R.
1511 The contents of the DHCP_Option table control the DHCP op‐
1513 tion names and values that this action supports.
1514 Example: reg0[0] = put_dhcp_opts(offerip = 10.0.0.2, router
1516 = 10.0.0.1, netmask = 255.255.255.0, dns_server = {8.8.8.8,
1517 7.7.7.7});
1518 R = put_dhcpv6_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1520 Parameters: one or more DHCPv6 option/value pairs.
1521 Result: stored to a 1-bit subfield R.
1523 Valid only in the ingress pipeline.
1525 When this action is applied to a DHCPv6 request packet, it
1527 changes the packet into a DHCPv6 reply, replaces the op‐
1528 tions by those specified as parameters, and stores 1 in R.
1529 When this action is applied to a non-DHCPv6 packet or an
1531 invalid DHCPv6 request packet , it leaves the packet un‐
1532 changed and stores 0 in R.
1533 The contents of the DHCPv6_Options table control the DHCPv6
1535 option names and values that this action supports.
1536 Example: reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4,
1538 server_id = 00:00:00:00:10:02,
1539 dns_server={ae70::1,ae70::2});
1540 set_queue(queue_number);
1542 Parameters: Queue number queue_number, in the range 0 to
1543 61440.
1544 This is a logical equivalent of the OpenFlow set_queue ac‐
1546 tion. It affects packets that egress a hypervisor through a
1547 physical interface. For nonzero queue_number, it configures
1548 packet queuing to match the settings configured for the
1549 Port_Binding with options:qdisc_queue_id matching
1550 queue_number. When queue_number is zero, it resets queuing
1551 to the default strategy.
1552 Example: set_queue(10);
1554 ct_lb;
1556 ct_lb(backends=ip[:port][,...][;
1557 hash_fields=field1,field2,...]);
1558 With arguments, ct_lb commits the packet to the connection
1559 tracking table and DNATs the packet’s destination IP ad‐
1560 dress (and port) to the IP address or addresses (and op‐
1561 tional ports) specified in the backends. If multiple comma-
1562 separated IP addresses are specified, each is given equal
1563 weight for picking the DNAT address. By default, dp_hash is
1564 used as the OpenFlow group selection method, but if
1565 hash_fields is specified, hash is used as the selection
1566 method, and the fields listed are used as the hash fields.
1567 Without arguments, ct_lb sends the packet to the connection
1569 tracking table to NAT the packets. If the packet is part of
1570 an established connection that was previously committed to
1571 the connection tracker via ct_lb(...), it will automati‐
1572 cally get DNATed to the same IP address as the first packet
1573 in that connection.
1574 Processing automatically moves on to the next table, as if
1576 next; were specified, and later tables act on the packet as
1577 modified by the connection tracker. Connection tracking
1578 state is scoped by the logical port when the action is used
1579 in a flow for a logical switch, so overlapping addresses
1580 may be used. Connection tracking state is scoped by the
1581 logical topology when the action is used in a flow for a
1582 router.
1583 ct_lb_mark;
1585 ct_lb_mark(backends=ip[:port][,...][;
1586 hash_fields=field1,field2,...]);
1587 Same as ct_lb, except that it internally uses ct_mark to
1588 store the NAT flag, while ct_lb uses ct_label for the same
1589 purpose.
1590 R = dns_lookup();
1592 Parameters: No parameters.
1593 Result: stored to a 1-bit subfield R.
1595 Valid only in the ingress pipeline.
1597 When this action is applied to a valid DNS request (a UDP
1599 packet typically directed to port 53), it attempts to re‐
1600 solve the query using the contents of the DNS table. If it
1601 is successful, it changes the packet into a DNS reply and
1602 stores 1 in R. If the action is applied to a non-DNS
1603 packet, an invalid DNS request packet, or a valid DNS re‐
1604 quest for which the DNS table does not supply an answer, it
1605 leaves the packet unchanged and stores 0 in R.
1606 Regardless of success, the action does not make any of the
1608 changes to the flow that are necessary to direct the packet
1609 back to the requester. The logical pipeline can implement
1610 this behavior with matches and actions in later tables.
1611 Example: reg0[3] = dns_lookup();
1613 Prerequisite: udp
1615 R = put_nd_ra_opts(D1 = V1, D2 = V2, ..., Dn = Vn);
1617 Parameters: The following IPv6 ND Router Advertisement op‐
1618 tion/value pairs as defined in RFC 4861.
1619 • addr_mode
1621 Mandatory parameter which specifies the address mode
1623 flag to be set in the RA flag options field. The
1624 value of this option is a string and the following
1625 values can be defined - "slaac", "dhcpv6_stateful"
1626 and "dhcpv6_stateless".
1627 • slla
1629 Mandatory parameter which specifies the link-layer
1631 address of the interface from which the Router Ad‐
1632 vertisement is sent.
1633 • mtu
1635 Optional parameter which specifies the MTU.
1637 • prefix
1639 Optional parameter which should be specified if the
1641 addr_mode is "slaac" or "dhcpv6_stateless". The
1642 value should be an IPv6 prefix which will be used
1643 for stateless IPv6 address configuration. This op‐
1644 tion can be defined multiple times.
1645 Result: stored to a 1-bit subfield R.
1647 Valid only in the ingress pipeline.
1649 When this action is applied to an IPv6 Router solicitation
1651 request packet, it changes the packet into an IPv6 Router
1652 Advertisement reply and adds the options specified in the
1653 parameters, and stores 1 in R.
1654 When this action is applied to a non-IPv6 Router solicita‐
1656 tion packet or an invalid IPv6 request packet , it leaves
1657 the packet unchanged and stores 0 in R.
1658 Example: reg0[3] = put_nd_ra_opts(addr_mode = "slaac", slla
1660 = 00:00:00:00:10:02, prefix = aef0::/64, mtu = 1450);
1661 set_meter(rate);
1663 set_meter(rate, burst);
1664 Parameters: rate limit int field rate in kbps, burst rate
1665 limits int field burst in kbps.
1666 This action sets the rate limit for a flow.
1668 Example: set_meter(100, 1000);
1670 R = check_pkt_larger(L)
1672 Parameters: packet length L to check for in bytes.
1673 Result: stored to a 1-bit subfield R.
1675 This is a logical equivalent of the OpenFlow
1677 check_pkt_larger action. If the packet is larger than the
1678 length specified in L, it stores 1 in the subfield R.
1679 Example: reg0[6] = check_pkt_larger(1000);
1681 log(key=value, ...);
1683 Causes ovn-controller to log the packet on the chassis
1684 that processes it. Packet logging currently uses the same
1685 logging mechanism as other Open vSwitch and OVN messages,
1686 which means that whether and where log messages appear
1687 depends on the local logging configuration that can be
1688 configured with ovs-appctl, etc.
1689 The log action takes zero or more of the following key-
1691 value pair arguments that control what is logged:
1692 name=string
1694 An optional name for the ACL. The string is cur‐
1695 rently limited to 64 bytes.
1696 severity=level
1698 Indicates the severity of the event. The level is
1699 one of following (from more to less serious):
1700 alert, warning, notice, info, or debug. If a
1701 severity is not provided, the default is info.
1702 verdict=value
1704 The verdict for packets matching the flow. The
1705 value must be one of allow, deny, or reject.
1706 meter=string
1708 An optional rate-limiting meter to be applied to
1709 the logs. The string should reference a name entry
1710 from the Meter table. The only meter action that
1711 is appropriate is drop.
1712 fwd_group(liveness=bool, childports=port, ...);
1714 Parameters: optional liveness, either true or false, de‐
1715 faulting to false; childports, a comma-delimited list of
1716 strings denoting logical ports to load balance across.
1717 Load balance traffic to one or more child ports in a log‐
1719 ical switch. ovn-controller translates the fwd_group into
1720 an OpenFlow group with one bucket for each child port. If
1721 liveness=true is specified, it also integrates the bucket
1722 selection with BFD status on the tunnel interface corre‐
1723 sponding to child port.
1724 Example: fwd_group(liveness=true, childports="p1", "p2");
1726 icmp4 { action; ... };
1728 icmp4_error { action; ... };
1729 Temporarily replaces the IPv4 packet being processed by an
1730 ICMPv4 packet and executes each nested action on the ICMPv4
1731 packet. Actions following these actions, if any, apply to
1732 the original, unmodified packet.
1733 The ICMPv4 packet that these actions operates on is ini‐
1735 tialized based on the IPv4 packet being processed, as fol‐
1736 lows. These are default values that the nested actions will
1737 probably want to change. Ethernet and IPv4 fields not
1738 listed here are not changed:
1739 • ip.proto = 1 (ICMPv4)
1741 • ip.frag = 0 (not a fragment)
1743 • ip.ttl = 255
1745 • icmp4.type = 3 (destination unreachable)
1747 • icmp4.code = 1 (host unreachable)
1749 icmp4_error action is expected to be used to generate an
1751 ICMPv4 packet in response to an error in original IP
1752 packet. When this action generates the ICMPv4 packet, it
1753 also copies the original IP datagram following the ICMPv4
1754 header as per RFC 1122: 3.2.2.
1755 Prerequisite: ip4
1757 icmp6 { action; ... };
1759 icmp6_error { action; ... };
1760 Temporarily replaces the IPv6 packet being processed by an
1761 ICMPv6 packet and executes each nested action on the ICMPv6
1762 packet. Actions following the icmp6 action, if any, apply
1763 to the original, unmodified packet.
1764 The ICMPv6 packet that this action operates on is initial‐
1766 ized based on the IPv6 packet being processed, as follows.
1767 These are default values that the nested actions will prob‐
1768 ably want to change. Ethernet and IPv6 fields not listed
1769 here are not changed:
1770 • ip.proto = 58 (ICMPv6)
1772 • ip.ttl = 255
1774 • icmp6.type = 1 (destination unreachable)
1776 • icmp6.code = 1 (administratively prohibited)
1778 icmp6_error action is expected to be used to generate an
1780 ICMPv6 packet in response to an error in original IPv6
1781 packet.
1782 Prerequisite: ip6
1784 tcp_reset;
1786 This action transforms the current TCP packet according to
1787 the following pseudocode:
1788 if (tcp.ack) {
1790 tcp.seq = tcp.ack;
1791 } else {
1792 tcp.ack = tcp.seq + length(tcp.payload);
1793 tcp.seq = 0;
1794 }
1795 tcp.flags = RST;
1796 Then, the action drops all TCP options and payload data,
1798 and updates the TCP checksum. IP ttl is set to 255.
1799 Prerequisite: tcp
1801 reject { action; ... };
1803 If the original packet is IPv4 or IPv6 TCP packet, it re‐
1804 places it with IPv4 or IPv6 TCP RST packet and executes the
1805 inner actions. Otherwise it replaces it with an ICMPv4 or
1806 ICMPv6 packet and executes the inner actions.
1807 The inner actions should not attempt to swap eth source
1809 with eth destination and IP source with IP destination as
1810 this action implicitly does that.
1811 trigger_event;
1813 This action is used to allow ovs-vswitchd to report CMS re‐
1814 lated events writing them in Controller_Event table. It is
1815 possible to associate a meter to a each event in order to
1816 not overload pinctrl thread under heavy load; each meter is
1817 identified though a defined naming convention. Supported
1818 events:
1819 • empty_lb_backends. This event is raised if a re‐
1821 ceived packet is destined for a load balancer VIP
1822 that has no configured backend destinations. For
1823 this event, the event info includes the load bal‐
1824 ancer VIP, the load balancer UUID, and the transport
1825 protocol. Associated meter: event-elb
1826 igmp;
1828 This action sends the packet to ovn-controller for multi‐
1829 cast snooping.
1830 Prerequisite: igmp
1832 bind_vport(V, P);
1834 Parameters: logical port string field V of type virtual,
1835 logical port string field P.
1836 Binds the virtual logical port V and sets the chassis col‐
1838 umn and virtual_parent of the table Port_Binding. vir‐
1839 tual_parent is set to P.
1840 handle_svc_check(P);
1842 Parameters: logical port string field P.
1843 Handles the service monitor reply received from the VIF of
1845 the logical port P. ovn-controller periodically sends out
1846 the service monitor packets for the services configured in
1847 the Service_Monitor table and this action updates the sta‐
1848 tus of those services.
1849 Example: handle_svc_check(inport);
1851 handle_dhcpv6_reply;
1853 Handle DHCPv6 prefix delegation advertisements/replies from
1854 a IPv6 delegation server. ovn-controller will add an entry
1855 ipv6_ra_pd_list in the options table for each prefix re‐
1856 ceived from the delegation server
1857 R = select(N1[=W1], N2[=W2], ...);
1859 Parameters: Integer N1, N2..., with optional weight W1, W2,
1860 ...
1861 Result: stored to a logical field or subfield R.
1863 Select from a list of integers N1, N2..., each within the
1865 range 0 ~ 65535, and store the selected one in the field R.
1866 There must be 2 or more integers listed, each with an op‐
1867 tional weight, which is an integer within the range 1 ~
1868 65535. If weight is not specified, it defaults to 100. The
1869 selection method is based on the 5-tuple hash of packet
1870 header.
1871 Processing automatically moves on to the next table, as if
1873 next; were specified. The select action must be put as the
1874 last action of the logical flow when there are multiple ac‐
1875 tions (actions put after select will not take effect).
1876 Example: reg8[16..31] = select(1=20, 2=30, 3=50);
1878 handle_dhcpv6_reply;
1880 This action is used to parse DHCPv6 replies from IPv6 Dele‐
1881 gation Router and managed IPv6 Prefix delegation state ma‐
1882 chine
1883 R = chk_lb_hairpin();
1885 This action checks if the packet under consideration was
1886 destined to a load balancer VIP and it is hairpinned, i.e.,
1887 after load balancing the destination IP matches the source
1888 IP. If it is so, then the 1-bit destination register R is
1889 set to 1.
1890 R = chk_lb_hairpin_reply();
1892 This action checks if the packet under consideration is
1893 from one of the backend IP of a load balancer VIP and the
1894 destination IP is the load balancer VIP. If it is so, then
1895 the 1-bit destination register R is set to 1.
1896 R = ct_snat_to_vip;
1898 This action sends the packet through the SNAT zone to
1899 change the source IP address of the packet to the load bal‐
1900 ancer VIP if the original destination IP was load balancer
1901 VIP and commits the connection. This action applies suc‐
1902 cessfully only for the hairpinned traffic i.e if the action
1903 chk_lb_hairpin returned success. This action doesn’t take
1904 any arguments and it determines the SNAT IP internally. The
1905 packet is not automatically sent to the next table. The
1906 caller has to execute the next; action explicitly after
1907 this action to advance the packet to the next stage.
1908 R = check_in_port_sec();
1910 This action checks if the packet under consideration passes
1911 the inport port security checks. If the packet fails the
1912 port security checks, then 1 is stored in the destination
1913 register R. Else 0 is stored. The port security values to
1914 check are retrieved from the the inport logical port.
1915 This action should be used in the ingress logical switch
1917 pipeline.
1918 Example: reg8[0..7] = check_in_port_sec();
1920 R = check_out_port_sec();
1922 This action checks if the packet under consideration passes
1923 the outport port security checks. If the packet fails the
1924 port security checks, then 1 is stored in the destination
1925 register R. Else 0 is stored. The port security values to
1926 check are retrieved from the the outport logical port.
1927 This action should be used in the egress logical switch
1929 pipeline.
1930 Example: reg8[0..7] = check_out_port_sec();
1932 tags: map of string-string pairs
1934 Key-value pairs that provide additional information to help ovn-
1935 controller processing the logical flow. Below are the tags used
1936 by ovn-controller.
1937 in_out_port
1939 In the logical flow’s "match" column, if a logical port P
1940 is compared with "inport" and the logical flow is on a
1941 logical switch ingress pipeline, or if P is compared with
1942 "outport" and the logical flow is on a logical switch
1943 egress pipeline, and the expression is combined with
1944 other expressions (if any) using the operator &&, then
1945 the port P should be added as the value in this tag. If
1946 there are multiple logical ports meeting this criteria,
1947 one of them can be added. ovn-controller uses this infor‐
1948 mation to skip parsing flows that are not needed on the
1949 chassis. Failing to add the tag will affect efficiency,
1950 while adding wrong value will affect correctness.
1951 controller_meter: optional string
1953 The name of the meter in table Meter to be used for all packets
1954 that the logical flow might send to ovn-controller.
1955 external_ids : stage-name: optional string
1957 Human-readable name for this flow’s stage in the pipeline.
1958 external_ids : stage-hint: optional string, containing an uuid
1960 UUID of a OVN_Northbound record that caused this logical flow to
1961 be created. Currently used only for attribute of logical flows
1962 to northbound ACL records.
1963 external_ids : source: optional string
1965 Source file and line number of the code that added this flow to
1966 the pipeline.
1967 Common Columns:
1969 The overall purpose of these columns is described under Common Columns
1971 at the beginning of this document.
1972 external_ids: map of string-string pairs
1974
1976 Each row in this table represents a group of logical datapaths refer‐
1977 enced by the logical_dp_group column in the Logical_Flow table.
1978 Summary:
1980 datapaths set of weak reference to Datapath_Bind‐
1981 ings
1982 Details:
1984 datapaths: set of weak reference to Datapath_Bindings
1985 List of Datapath_Binding entries.
1986
1988 The rows in this table define multicast groups of logical ports. Multi‐
1989 cast groups allow a single packet transmitted over a tunnel to a hyper‐
1990 visor to be delivered to multiple VMs on that hypervisor, which uses
1991 bandwidth more efficiently.
1992 Each row in this table defines a logical multicast group numbered tun‐
1994 nel_key within datapath, whose logical ports are listed in the ports
1995 column.
1996 Summary:
1998 datapath Datapath_Binding
1999 tunnel_key integer, in range 32,768 to 65,535
2000 name string
2001 ports set of weak reference to Port_Bindings
2002 Details:
2004 datapath: Datapath_Binding
2005 The logical datapath in which the multicast group resides.
2006 tunnel_key: integer, in range 32,768 to 65,535
2008 The value used to designate this logical egress port in tunnel
2009 encapsulations. An index forces the key to be unique within the
2010 datapath. The unusual range ensures that multicast group IDs do
2011 not overlap with logical port IDs.
2012 name: string
2014 The logical multicast group’s name. An index forces the name to
2015 be unique within the datapath. Logical flows in the ingress
2016 pipeline may output to the group just as for individual logical
2017 ports, by assigning the group’s name to outport and executing an
2018 output action.
2019 Multicast group names and logical port names share a single
2021 namespace and thus should not overlap (but the database schema
2022 cannot enforce this). To try to avoid conflicts, ovn-northd uses
2023 names that begin with _MC_.
2024 ports: set of weak reference to Port_Bindings
2026 The logical ports included in the multicast group. All of these
2027 ports must be in the datapath logical datapath (but the database
2028 schema cannot enforce this).
2029
2031 Each row in this table represents a meter that can be used for QoS or
2032 rate-limiting.
2033 Summary:
2035 name string (must be unique within table)
2036 unit string, either kbps or pktps
2037 bands set of 1 or more Meter_Bands
2038 Details:
2040 name: string (must be unique within table)
2041 A name for this meter.
2042 Names that begin with "__" (two underscores) are reserved for
2044 OVN internal use and should not be added manually.
2045 unit: string, either kbps or pktps
2047 The unit for rate and burst_rate parameters in the bands entry.
2048 kbps specifies kilobits per second, and pktps specifies packets
2049 per second.
2050 bands: set of 1 or more Meter_Bands
2052 The bands associated with this meter. Each band specifies a rate
2053 above which the band is to take the action action. If multiple
2054 bands’ rates are exceeded, then the band with the highest rate
2055 among the exceeded bands is selected.
2056
2058 Each row in this table represents a meter band which specifies the rate
2059 above which the configured action should be applied. These bands are
2060 referenced by the bands column in the Meter table.
2061 Summary:
2063 action string, must be drop
2064 rate integer, in range 1 to 4,294,967,295
2065 burst_size integer, in range 0 to 4,294,967,295
2066 Details:
2068 action: string, must be drop
2069 The action to execute when this band matches. The only supported
2070 action is drop.
2071 rate: integer, in range 1 to 4,294,967,295
2073 The rate limit for this band, in kilobits per second or bits per
2074 second, depending on whether the parent Meter entry’s unit col‐
2075 umn specified kbps or pktps.
2076 burst_size: integer, in range 0 to 4,294,967,295
2078 The maximum burst allowed for the band in kilobits or packets,
2079 depending on whether kbps or pktps was selected in the parent
2080 Meter entry’s unit column. If the size is zero, the switch is
2081 free to select some reasonable value depending on its configura‐
2082 tion.
2083
2085 Each row in this table represents a logical datapath, which implements
2086 a logical pipeline among the ports in the Port_Binding table associated
2087 with it. In practice, the pipeline in a given logical datapath imple‐
2088 ments either a logical switch or a logical router.
2089 The main purpose of a row in this table is provide a physical binding
2091 for a logical datapath. A logical datapath does not have a physical lo‐
2092 cation, so its physical binding information is limited: just tun‐
2093 nel_key. The rest of the data in this table does not affect packet for‐
2094 warding.
2095 Summary:
2097 tunnel_key integer, in range 1 to 16,777,215 (must
2098 be unique within table)
2099 load_balancers set of uuids
2100 OVN_Northbound Relationship:
2101 external_ids : logical-switch
2102 optional string, containing an uuid
2103 external_ids : logical-router
2104 optional string, containing an uuid
2105 external_ids : interconn-ts
2106 optional string
2107 Naming:
2108 external_ids : name optional string
2109 external_ids : name2 optional string
2110 Common Columns:
2111 external_ids map of string-string pairs
2112 Details:
2114 tunnel_key: integer, in range 1 to 16,777,215 (must be unique within
2115 table)
2116 The tunnel key value to which the logical datapath is bound. The
2117 Tunnel Encapsulation section in ovn-architecture(7) describes
2118 how tunnel keys are constructed for each supported encapsula‐
2119 tion.
2120 load_balancers: set of uuids
2122 Not used anymore; kept for backwards compatibility of the
2123 schema.
2124 OVN_Northbound Relationship:
2126 Each row in Datapath_Binding is associated with some logical datapath.
2128 ovn-northd uses these keys to track the association of a logical data‐
2129 path with concepts in the OVN_Northbound database.
2130 external_ids : logical-switch: optional string, containing an uuid
2132 For a logical datapath that represents a logical switch,
2133 ovn-northd stores in this key the UUID of the corresponding Log‐
2134 ical_Switch row in the OVN_Northbound database.
2135 external_ids : logical-router: optional string, containing an uuid
2137 For a logical datapath that represents a logical router,
2138 ovn-northd stores in this key the UUID of the corresponding Log‐
2139 ical_Router row in the OVN_Northbound database.
2140 external_ids : interconn-ts: optional string
2142 For a logical datapath that represents a logical switch that
2143 represents a transit switch for interconnection, ovn-northd
2144 stores in this key the value of the same interconn-ts key of the
2145 external_ids column of the corresponding Logical_Switch row in
2146 the OVN_Northbound database.
2147 Naming:
2149 ovn-northd copies these from the name fields in the OVN_Northbound
2151 database, either from name and external_ids:neutron:router_name in the
2152 Logical_Router table or from name and external_ids:neutron:network_name
2153 in the Logical_Switch table.
2154 external_ids : name: optional string
2156 A name for the logical datapath.
2157 external_ids : name2: optional string
2159 Another name for the logical datapath.
2160 Common Columns:
2162 The overall purpose of these columns is described under Common Columns
2164 at the beginning of this document.
2165 external_ids: map of string-string pairs
2167
2169 Each row in this table binds a logical port to a realization. For most
2170 logical ports, this means binding to some physical location, for exam‐
2171 ple by binding a logical port to a VIF that belongs to a VM running on
2172 a particular hypervisor. Other logical ports, such as logical patch
2173 ports, can be realized without a specific physical location, but their
2174 bindings are still expressed through rows in this table.
2175 For every Logical_Switch_Port record in OVN_Northbound database,
2177 ovn-northd creates a record in this table. ovn-northd populates and
2178 maintains every column except the chassis and virtual_parent columns,
2179 which it leaves empty in new records.
2180 ovn-controller/ovn-controller-vtep populates the chassis column for the
2182 records that identify the logical ports that are located on its hyper‐
2183 visor/gateway, which ovn-controller/ovn-controller-vtep in turn finds
2184 out by monitoring the local hypervisor’s Open_vSwitch database, which
2185 identifies logical ports via the conventions described in Integra‐
2186 tionGuide.rst. (The exceptions are for Port_Binding records with type
2187 of l3gateway, whose locations are identified by ovn-northd via the op‐
2188 tions:l3gateway-chassis column in this table. ovn-controller is still
2189 responsible to populate the chassis column.)
2190 ovn-controller also populates the virtual_parent column of records
2192 whose type is virtual.
2193 When a chassis shuts down gracefully, it should clean up the chassis
2195 column that it previously had populated. (This is not critical because
2196 resources hosted on the chassis are equally unreachable regardless of
2197 whether their rows are present.) To handle the case where a VM is shut
2198 down abruptly on one chassis, then brought up again on a different one,
2199 ovn-controller/ovn-controller-vtep must overwrite the chassis column
2200 with new information.
2201 Summary:
2203 Core Features:
2204 datapath Datapath_Binding
2205 logical_port string (must be unique within table)
2206 encap optional weak reference to Encap
2207 additional_encap set of weak reference to Encaps
2208 chassis optional weak reference to Chassis
2209 additional_chassis set of weak reference to Chassis
2210 gateway_chassis set of Gateway_Chassises
2211 ha_chassis_group optional HA_Chassis_Group
2212 up optional boolean
2213 tunnel_key integer, in range 1 to 32,767
2214 mac set of strings
2215 port_security set of strings
2216 type string
2217 requested_chassis optional weak reference to Chassis
2218 requested_additional_chassis
2219 set of weak reference to Chassis
2220 Patch Options:
2221 options : peer optional string
2222 nat_addresses set of strings
2223 L3 Gateway Options:
2224 options : peer optional string
2225 options : l3gateway-chassis
2226 optional string
2227 nat_addresses set of strings
2228 Localnet Options:
2229 options : network_name optional string
2230 tag optional integer, in range 1 to 4,095
2231 L2 Gateway Options:
2232 options : network_name optional string
2233 options : l2gateway-chassis
2234 optional string
2235 tag optional integer, in range 1 to 4,095
2236 VTEP Options:
2237 options : vtep-physical-switch
2238 optional string
2239 options : vtep-logical-switch
2240 optional string
2241 VMI (or VIF) Options:
2242 options : requested-chassis
2243 optional string
2244 options : iface-id-ver optional string
2245 options : qos_min_rate optional string
2246 options : qos_max_rate optional string
2247 options : qos_burst optional string
2248 options : qdisc_queue_id optional string, containing an integer,
2249 in range 1 to 61,440
2250 Distributed Gateway Port Options:
2251 options : chassis-redirect-port
2252 optional string
2253 Chassis Redirect Options:
2254 options : distributed-port optional string
2255 options : redirect-type optional string
2256 options : always-redirect optional string
2257 Nested Containers:
2258 parent_port optional string
2259 tag optional integer, in range 1 to 4,095
2260 Virtual ports:
2261 virtual_parent optional string
2262 Naming:
2263 external_ids : name optional string
2264 Common Columns:
2265 external_ids map of string-string pairs
2266 Details:
2268 Core Features:
2269 datapath: Datapath_Binding
2271 The logical datapath to which the logical port belongs.
2272 logical_port: string (must be unique within table)
2274 A logical port. For a logical switch port, this is taken from
2275 name in the OVN_Northbound database’s Logical_Switch_Port table.
2276 For a logical router port, this is taken from name in the
2277 OVN_Northbound database’s Logical_Router_port table. (This means
2278 that logical switch ports and router port names must not share
2279 names in an OVN deployment.) OVN does not prescribe a particular
2280 format for the logical port ID.
2281 encap: optional weak reference to Encap
2283 Points to preferred encapsulation configuration to transmit log‐
2284 ical dataplane packets to this chassis. The entry is reference
2285 to a Encap record.
2286 additional_encap: set of weak reference to Encaps
2288 Points to preferred encapsulation configuration to transmit log‐
2289 ical dataplane packets to this additional chassis. The entry is
2290 reference to a Encap record. See also additional_chassis.
2291 chassis: optional weak reference to Chassis
2293 The meaning of this column depends on the value of the type col‐
2294 umn. This is the meaning for each type
2295 (empty string)
2297 The physical location of the logical port. To success‐
2298 fully identify a chassis, this column must be a Chassis
2299 record. This is populated by ovn-controller.
2300 vtep The physical location of the hardware_vtep gateway. To
2302 successfully identify a chassis, this column must be a
2303 Chassis record. This is populated by ovn-controller-vtep.
2304 localnet
2306 Always empty. A localnet port is realized on every chas‐
2307 sis that has connectivity to the corresponding physical
2308 network.
2309 localport
2311 Always empty. A localport port is present on every chas‐
2312 sis.
2313 l3gateway
2315 The physical location of the L3 gateway. To successfully
2316 identify a chassis, this column must be a Chassis record.
2317 This is populated by ovn-controller based on the value of
2318 the options:l3gateway-chassis column in this table.
2319 l2gateway
2321 The physical location of this L2 gateway. To successfully
2322 identify a chassis, this column must be a Chassis record.
2323 This is populated by ovn-controller based on the value of
2324 the options:l2gateway-chassis column in this table.
2325 additional_chassis: set of weak reference to Chassis
2327 The meaning of this column is the same as for the chassis. The
2328 column is used to track an additional physical location of the
2329 logical port. Used with regular (empty type) port bindings.
2330 gateway_chassis: set of Gateway_Chassises
2332 A list of Gateway_Chassis.
2333 This should only be populated for ports with type set to chas‐
2335 sisredirect. This column defines the list of chassis used as
2336 gateways where traffic will be redirected through.
2337 ha_chassis_group: optional HA_Chassis_Group
2339 This should only be populated for ports with type set to chas‐
2340 sisredirect. This column defines the HA chassis group with a
2341 list of HA chassis used as gateways where traffic will be redi‐
2342 rected through.
2343 up: optional boolean
2345 This is set to true whenever all OVS flows required by this
2346 Port_Binding have been installed. This is populated by ovn-con‐
2347 troller.
2348 tunnel_key: integer, in range 1 to 32,767
2350 A number that represents the logical port in the key (e.g. STT
2351 key or Geneve TLV) field carried within tunnel protocol packets.
2352 The tunnel ID must be unique within the scope of a logical data‐
2354 path.
2355 mac: set of strings
2357 This column is a misnomer as it may contain MAC addresses and IP
2358 addresses. It is copied from the addresses column in the Logi‐
2359 cal_Switch_Port table in the Northbound database. It follows the
2360 same format as that column.
2361 port_security: set of strings
2363 This column controls the addresses from which the host attached
2364 to the logical port (``the host’’) is allowed to send packets
2365 and to which it is allowed to receive packets. If this column is
2366 empty, all addresses are permitted.
2367 It is copied from the port_security column in the Logi‐
2369 cal_Switch_Port table in the Northbound database. It follows the
2370 same format as that column.
2371 type: string
2373 A type for this logical port. Logical ports can be used to model
2374 other types of connectivity into an OVN logical switch. The fol‐
2375 lowing types are defined:
2376 (empty string)
2378 VM (or VIF) interface.
2379 patch One of a pair of logical ports that act as if connected
2381 by a patch cable. Useful for connecting two logical data‐
2382 paths, e.g. to connect a logical router to a logical
2383 switch or to another logical router.
2384 l3gateway
2386 One of a pair of logical ports that act as if connected
2387 by a patch cable across multiple chassis. Useful for con‐
2388 necting a logical switch with a Gateway router (which is
2389 only resident on a particular chassis).
2390 localnet
2392 A connection to a locally accessible network from
2393 ovn-controller instances that have a corresponding bridge
2394 mapping. A logical switch can have multiple localnet
2395 ports attached. This type is used to model direct connec‐
2396 tivity to existing networks. In this case, each chassis
2397 should have a mapping for one of the physical networks
2398 only. Note: nothing said above implies that a chassis
2399 cannot be plugged to multiple physical networks as long
2400 as they belong to different switches.
2401 localport
2403 A connection to a local VIF. Traffic that arrives on a
2404 localport is never forwarded over a tunnel to another
2405 chassis. These ports are present on every chassis and
2406 have the same address in all of them. This is used to
2407 model connectivity to local services that run on every
2408 hypervisor.
2409 l2gateway
2411 An L2 connection to a physical network. The chassis this
2412 Port_Binding is bound to will serve as an L2 gateway to
2413 the network named by options:network_name.
2414 vtep A port to a logical switch on a VTEP gateway chassis. In
2416 order to get this port correctly recognized by the OVN
2417 controller, the options:vtep-physical-switch and op‐
2418 tions:vtep-logical-switch must also be defined.
2419 chassisredirect
2421 A logical port that represents a particular instance,
2422 bound to a specific chassis, of an otherwise distributed
2423 parent port (e.g. of type patch). A chassisredirect port
2424 should never be used as an inport. When an ingress pipe‐
2425 line sets the outport, it may set the value to a logical
2426 port of type chassisredirect. This will cause the packet
2427 to be directed to a specific chassis to carry out the
2428 egress pipeline. At the beginning of the egress pipeline,
2429 the outport will be reset to the value of the distributed
2430 port.
2431 virtual
2433 Represents a logical port with an virtual ip. This vir‐
2434 tual ip can be configured on a logical port (which is
2435 refered as virtual parent).
2436 requested_chassis: optional weak reference to Chassis
2438 This column exists so that the ovn-controller can effectively
2439 monitor all Port_Binding records destined for it, and is a sup‐
2440 plement to the options:requested-chassis option. The option is
2441 still required so that the ovn-controller can check the CMS in‐
2442 tent when the chassis pointed to does not currently exist, which
2443 for example occurs when the ovn-controller is stopped without
2444 passing the -restart argument. This column must be a Chassis
2445 record. This is populated by ovn-northd when the options:re‐
2446 quested-chassis is defined and contains a string matching the
2447 name or hostname of an existing chassis. See also requested_ad‐
2448 ditional_chassis.
2449 requested_additional_chassis: set of weak reference to Chassis
2451 This column exists so that the ovn-controller can effectively
2452 monitor all Port_Binding records destined for it, and is a sup‐
2453 plement to the options:requested-chassis option when multiple
2454 chassis are listed. This column must be a list of Chassis
2455 records. This is populated by ovn-northd when the options:re‐
2456 quested-chassis is defined as a list of chassis names or host‐
2457 names. See also requested_chassis.
2458 Patch Options:
2460 These options apply to logical ports with type of patch.
2462 options : peer: optional string
2464 The logical_port in the Port_Binding record for the other side
2465 of the patch. The named logical_port must specify this logi‐
2466 cal_port in its own peer option. That is, the two patch logical
2467 ports must have reversed logical_port and peer values.
2468 nat_addresses: set of strings
2470 MAC address followed by a list of SNAT and DNAT external IP ad‐
2471 dresses, followed by is_chassis_resident("lport"), where lport
2472 is the name of a logical port on the same chassis where the cor‐
2473 responding NAT rules are applied. This is used to send gratu‐
2474 itous ARPs for SNAT and DNAT external IP addresses via localnet,
2475 from the chassis where lport resides. Example: 80:fa:5b:06:72:b7
2476 158.36.44.22 158.36.44.24 is_chassis_resident("foo1"). This
2477 would result in generation of gratuitous ARPs for IP addresses
2478 158.36.44.22 and 158.36.44.24 with a MAC address of
2479 80:fa:5b:06:72:b7 from the chassis where the logical port "foo1"
2480 resides.
2481 L3 Gateway Options:
2483 These options apply to logical ports with type of l3gateway.
2485 options : peer: optional string
2487 The logical_port in the Port_Binding record for the other side
2488 of the ’l3gateway’ port. The named logical_port must specify
2489 this logical_port in its own peer option. That is, the two
2490 ’l3gateway’ logical ports must have reversed logical_port and
2491 peer values.
2492 options : l3gateway-chassis: optional string
2494 The chassis in which the port resides.
2495 nat_addresses: set of strings
2497 MAC address of the l3gateway port followed by a list of SNAT and
2498 DNAT external IP addresses. This is used to send gratuitous ARPs
2499 for SNAT and DNAT external IP addresses via localnet. Example:
2500 80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24. This would result
2501 in generation of gratuitous ARPs for IP addresses 158.36.44.22
2502 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. This
2503 is used in OVS version 2.8 and later versions.
2504 Localnet Options:
2506 These options apply to logical ports with type of localnet.
2508 options : network_name: optional string
2510 Required. ovn-controller uses the configuration entry
2511 ovn-bridge-mappings to determine how to connect to this network.
2512 ovn-bridge-mappings is a list of network names mapped to a local
2513 OVS bridge that provides access to that network. An example of
2514 configuring ovn-bridge-mappings would be: .IP
2515 $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
2516 When a logical switch has a localnet port attached, every chas‐
2518 sis that may have a local vif attached to that logical switch
2519 must have a bridge mapping configured to reach that localnet.
2520 Traffic that arrives on a localnet port is never forwarded over
2521 a tunnel to another chassis. If there are multiple localnet
2522 ports in a logical switch, each chassis should only have a sin‐
2523 gle bridge mapping for one of the physical networks. Note: In
2524 case of multiple localnet ports, to provide interconnectivity
2525 between all VIFs located on different chassis with different
2526 fabric connectivity, the fabric should implement some form of
2527 routing between the segments.
2528 tag: optional integer, in range 1 to 4,095
2530 If set, indicates that the port represents a connection to a
2531 specific VLAN on a locally accessible network. The VLAN ID is
2532 used to match incoming traffic and is also added to outgoing
2533 traffic.
2534 L2 Gateway Options:
2536 These options apply to logical ports with type of l2gateway.
2538 options : network_name: optional string
2540 Required. ovn-controller uses the configuration entry
2541 ovn-bridge-mappings to determine how to connect to this network.
2542 ovn-bridge-mappings is a list of network names mapped to a local
2543 OVS bridge that provides access to that network. An example of
2544 configuring ovn-bridge-mappings would be: .IP
2545 $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
2546 When a logical switch has a l2gateway port attached, the chassis
2548 that the l2gateway port is bound to must have a bridge mapping
2549 configured to reach the network identified by network_name.
2550 options : l2gateway-chassis: optional string
2552 Required. The chassis in which the port resides.
2553 tag: optional integer, in range 1 to 4,095
2555 If set, indicates that the gateway is connected to a specific
2556 VLAN on the physical network. The VLAN ID is used to match in‐
2557 coming traffic and is also added to outgoing traffic.
2558 VTEP Options:
2560 These options apply to logical ports with type of vtep.
2562 options : vtep-physical-switch: optional string
2564 Required. The name of the VTEP gateway.
2565 options : vtep-logical-switch: optional string
2567 Required. A logical switch name connected by the VTEP gateway.
2568 Must be set when type is vtep.
2569 VMI (or VIF) Options:
2571 These options apply to logical ports with type having (empty string)
2573 options : requested-chassis: optional string
2575 If set, identifies a specific chassis (by name or hostname) that
2576 is allowed to bind this port. Using this option will prevent
2577 thrashing between two chassis trying to bind the same port dur‐
2578 ing a live migration. It can also prevent similar thrashing due
2579 to a mis-configuration, if a port is accidentally created on
2580 more than one chassis.
2581 If set to a comma separated list, the first entry identifies the
2583 main chassis and the rest are one or more additional chassis
2584 that are allowed to bind the same port.
2585 When multiple chassis are set for the port, and the logical
2587 switch is connected to an external network through a localnet
2588 port, tunneling is enforced for the port to guarantee delivery
2589 of packets directed to the port to all its locations. This has
2590 MTU implications because the network used for tunneling must
2591 have MTU larger than localnet for stable connectivity.
2592 options : iface-id-ver: optional string
2594 If set, this port will be bound by ovn-controller only if this
2595 same key and value is configured in the external_ids column in
2596 the Open_vSwitch database’s Interface table.
2597 options : qos_min_rate: optional string
2599 If set, indicates the minimum guaranteed rate available for data
2600 sent from this interface, in bit/s.
2601 options : qos_max_rate: optional string
2603 If set, indicates the maximum rate for data sent from this in‐
2604 terface, in bit/s. The traffic will be shaped according to this
2605 limit.
2606 options : qos_burst: optional string
2608 If set, indicates the maximum burst size for data sent from this
2609 interface, in bits.
2610 options : qdisc_queue_id: optional string, containing an integer, in
2612 range 1 to 61,440
2613 Indicates the queue number on the physical device. This is same
2614 as the queue_id used in OpenFlow in struct ofp_action_enqueue.
2615 Distributed Gateway Port Options:
2617 These options apply to the distributed parent ports of logical ports
2619 with type of chasssisredirect.
2620 options : chassis-redirect-port: optional string
2622 The name of the chassis redirect port derived from this port if
2623 this port is a distributed parent of a chassis redirect port.
2624 Chassis Redirect Options:
2626 These options apply to logical ports with type of chassisredirect.
2628 options : distributed-port: optional string
2630 The name of the distributed port for which this chassisredirect
2631 port represents a particular instance.
2632 options : redirect-type: optional string
2634 The value is copied from the column options in the OVN_North‐
2635 bound database’s Logical_Router_Port table for the distributed
2636 parent of this port.
2637 options : always-redirect: optional string
2639 A boolean option that is set to true if the distributed parent
2640 of this chassis redirect port does not need distributed process‐
2641 ing.
2642 Nested Containers:
2644 These columns support containers nested within a VM. Specifically, they
2646 are used when type is empty and logical_port identifies the interface
2647 of a container spawned inside a VM. They are empty for containers or
2648 VMs that run directly on a hypervisor.
2649 parent_port: optional string
2651 This is taken from parent_name in the OVN_Northbound database’s
2652 Logical_Switch_Port table.
2653 tag: optional integer, in range 1 to 4,095
2655 Identifies the VLAN tag in the network traffic associated with
2656 that container’s network interface.
2657 This column is used for a different purpose when type is local‐
2659 net (see Localnet Options, above) or l2gateway (see L2 Gateway
2660 Options, above).
2661 Virtual ports:
2663 virtual_parent: optional string
2665 This column is set by ovn-controller with one of the value from
2666 the options:virtual-parents in the OVN_Northbound database’s
2667 Logical_Switch_Port table when the OVN action bind_vport is exe‐
2668 cuted. ovn-controller also sets the chassis column when it exe‐
2669 cutes this action with its chassis id.
2670 ovn-controller sets this column only if the type is "virtual".
2672 Naming:
2674 external_ids : name: optional string
2676 For a logical switch port, ovn-northd copies this from exter‐
2677 nal_ids:neutron:port_name in the Logical_Switch_Port table in
2678 the OVN_Northbound database, if it is a nonempty string.
2679 For a logical switch port, ovn-northd does not currently set
2681 this key.
2682 Common Columns:
2684 external_ids: map of string-string pairs
2686 See External IDs at the beginning of this document.
2687 The ovn-northd program populates this column with all entries
2689 into the external_ids column of the Logical_Switch_Port and Log‐
2690 ical_Router_Port tables of the OVN_Northbound database.
2691
2693 Each row in this table specifies a binding from an IP address to an
2694 Ethernet address that has been discovered through ARP (for IPv4) or
2695 neighbor discovery (for IPv6). This table is primarily used to discover
2696 bindings on physical networks, because IP-to-MAC bindings for virtual
2697 machines are usually populated statically into the Port_Binding table.
2698 This table expresses a functional relationship: MAC_Binding(logi‐
2700 cal_port, ip) = mac.
2701 In outline, the lifetime of a logical router’s MAC binding looks like
2703 this:
2704 1. On hypervisor 1, a logical router determines that a packet
2706 should be forwarded to IP address A on one of its router
2707 ports. It uses its logical flow table to determine that A
2708 lacks a static IP-to-MAC binding and the get_arp action to
2709 determine that it lacks a dynamic IP-to-MAC binding.
2710 2. Using an OVN logical arp action, the logical router gener‐
2712 ates and sends a broadcast ARP request to the router port.
2713 It drops the IP packet.
2714 3. The logical switch attached to the router port delivers the
2716 ARP request to all of its ports. (It might make sense to de‐
2717 liver it only to ports that have no static IP-to-MAC bind‐
2718 ings, but this could also be surprising behavior.)
2719 4. A host or VM on hypervisor 2 (which might be the same as hy‐
2721 pervisor 1) attached to the logical switch owns the IP ad‐
2722 dress in question. It composes an ARP reply and unicasts it
2723 to the logical router port’s Ethernet address.
2724 5. The logical switch delivers the ARP reply to the logical
2726 router port.
2727 6. The logical router flow table executes a put_arp action. To
2729 record the IP-to-MAC binding, ovn-controller adds a row to
2730 the MAC_Binding table.
2731 7. On hypervisor 1, ovn-controller receives the updated
2733 MAC_Binding table from the OVN southbound database. The next
2734 packet destined to A through the logical router is sent di‐
2735 rectly to the bound Ethernet address.
2736 Summary:
2738 logical_port string
2739 ip string
2740 mac string
2741 datapath Datapath_Binding
2742 Details:
2744 logical_port: string
2745 The logical port on which the binding was discovered.
2746 ip: string
2748 The bound IP address.
2749 mac: string
2751 The Ethernet address to which the IP is bound.
2752 datapath: Datapath_Binding
2754 The logical datapath to which the logical port belongs.
2755
2757 Each row in this table stores the DHCP Options supported by native OVN
2758 DHCP. ovn-northd populates this table with the supported DHCP options.
2759 ovn-controller looks up this table to get the DHCP codes of the DHCP
2760 options defined in the "put_dhcp_opts" action. Please refer to the RFC
2761 2132 "https://tools.ietf.org/html/rfc2132" for the possible list of
2762 DHCP options that can be defined here.
2763 Summary:
2765 name string
2766 code integer, in range 0 to 254
2767 type string, one of bool, domains, host_id,
2768 ipv4, static_routes, str, uint16, uint32,
2769 or uint8
2770 Details:
2772 name: string
2773 Name of the DHCP option.
2774 Example. name="router"
2776 code: integer, in range 0 to 254
2778 DHCP option code for the DHCP option as defined in the RFC 2132.
2779 Example. code=3
2781 type: string, one of bool, domains, host_id, ipv4, static_routes, str,
2783 uint16, uint32, or uint8
2784 Data type of the DHCP option code.
2785 value: bool
2787 This indicates that the value of the DHCP option is a
2788 bool.
2789 Example. "name=ip_forward_enable", "code=19",
2791 "type=bool".
2792 put_dhcp_opts(..., ip_forward_enable = 1,...)
2794 value: uint8
2796 This indicates that the value of the DHCP option is an
2797 unsigned int8 (8 bits)
2798 Example. "name=default_ttl", "code=23", "type=uint8".
2800 put_dhcp_opts(..., default_ttl = 50,...)
2802 value: uint16
2804 This indicates that the value of the DHCP option is an
2805 unsigned int16 (16 bits).
2806 Example. "name=mtu", "code=26", "type=uint16".
2808 put_dhcp_opts(..., mtu = 1450,...)
2810 value: uint32
2812 This indicates that the value of the DHCP option is an
2813 unsigned int32 (32 bits).
2814 Example. "name=lease_time", "code=51", "type=uint32".
2816 put_dhcp_opts(..., lease_time = 86400,...)
2818 value: ipv4
2820 This indicates that the value of the DHCP option is an
2821 IPv4 address or addresses.
2822 Example. "name=router", "code=3", "type=ipv4".
2824 put_dhcp_opts(..., router = 10.0.0.1,...)
2826 Example. "name=dns_server", "code=6", "type=ipv4".
2828 put_dhcp_opts(..., dns_server = {8.8.8.8 7.7.7.7},...)
2830 value: static_routes
2832 This indicates that the value of the DHCP option contains
2833 a pair of IPv4 route and next hop addresses.
2834 Example. "name=classless_static_route", "code=121",
2836 "type=static_routes".
2837 put_dhcp_opts(..., classless_static_route =
2839 {30.0.0.0/24,10.0.0.4,0.0.0.0/0,10.0.0.1}...)
2840 value: str
2842 This indicates that the value of the DHCP option is a
2843 string.
2844 Example. "name=host_name", "code=12", "type=str".
2846 value: host_id
2848 This indicates that the value of the DHCP option is a
2849 host_id. It can either be a host_name or an IP address.
2850 Example. "name=tftp_server", "code=66", "type=host_id".
2852 value: domains
2854 This indicates that the value of the DHCP option is a do‐
2855 main name or a comma separated list of domain names.
2856 Example. "name=domain_search_list", "code=119", "type=do‐
2858 mains".
2859
2861 Each row in this table stores the DHCPv6 Options supported by native
2862 OVN DHCPv6. ovn-northd populates this table with the supported DHCPv6
2863 options. ovn-controller looks up this table to get the DHCPv6 codes of
2864 the DHCPv6 options defined in the put_dhcpv6_opts action. Please refer
2865 to RFC 3315 and RFC 3646 for the list of DHCPv6 options that can be de‐
2866 fined here.
2867 Summary:
2869 name string
2870 code integer, in range 0 to 254
2871 type string, one of ipv6, mac, or str
2872 Details:
2874 name: string
2875 Name of the DHCPv6 option.
2876 Example. name="ia_addr"
2878 code: integer, in range 0 to 254
2880 DHCPv6 option code for the DHCPv6 option as defined in the ap‐
2881 propriate RFC.
2882 Example. code=3
2884 type: string, one of ipv6, mac, or str
2886 Data type of the DHCPv6 option code.
2887 value: ipv6
2889 This indicates that the value of the DHCPv6 option is an
2890 IPv6 address(es).
2891 Example. "name=ia_addr", "code=5", "type=ipv6".
2893 put_dhcpv6_opts(..., ia_addr = ae70::4,...)
2895 value: str
2897 This indicates that the value of the DHCPv6 option is a
2898 string.
2899 Example. "name=domain_search", "code=24", "type=str".
2901 put_dhcpv6_opts(..., domain_search = ovn.domain,...)
2903 value: mac
2905 This indicates that the value of the DHCPv6 option is a
2906 MAC address.
2907 Example. "name=server_id", "code=2", "type=mac".
2909 put_dhcpv6_opts(..., server_id = 01:02:03:04L05:06,...)
2911
2913 Configuration for a database connection to an Open vSwitch database
2914 (OVSDB) client.
2915 This table primarily configures the Open vSwitch database server
2917 (ovsdb-server).
2918 The Open vSwitch database server can initiate and maintain active con‐
2920 nections to remote clients. It can also listen for database connec‐
2921 tions.
2922 Summary:
2924 Core Features:
2925 target string (must be unique within table)
2926 read_only boolean
2927 role string
2928 Client Failure Detection and Handling:
2929 max_backoff optional integer, at least 1,000
2930 inactivity_probe optional integer
2931 Status:
2932 is_connected boolean
2933 status : last_error optional string
2934 status : state optional string, one of ACTIVE, BACKOFF,
2935 CONNECTING, IDLE, or VOID
2936 status : sec_since_connect optional string, containing an integer,
2937 at least 0
2938 status : sec_since_disconnect
2939 optional string, containing an integer,
2940 at least 0
2941 status : locks_held optional string
2942 status : locks_waiting optional string
2943 status : locks_lost optional string
2944 status : n_connections optional string, containing an integer,
2945 at least 2
2946 status : bound_port optional string, containing an integer
2947 Common Columns:
2948 external_ids map of string-string pairs
2949 other_config map of string-string pairs
2950 Details:
2952 Core Features:
2953 target: string (must be unique within table)
2955 Connection methods for clients.
2956 The following connection methods are currently supported:
2958 ssl:host[:port]
2960 The specified SSL port on the given host, which can ei‐
2961 ther be a DNS name (if built with unbound library) or an
2962 IP address. A valid SSL configuration must be provided
2963 when this form is used, this configuration can be speci‐
2964 fied via command-line options or the SSL table.
2965 If port is not specified, it defaults to 6640.
2967 SSL support is an optional feature that is not always
2969 built as part of Open vSwitch.
2970 tcp:host[:port]
2972 The specified TCP port on the given host, which can ei‐
2973 ther be a DNS name (if built with unbound library) or an
2974 IP address (IPv4 or IPv6). If host is an IPv6 address,
2975 wrap it in square brackets, e.g. tcp:[::1]:6640.
2976 If port is not specified, it defaults to 6640.
2978 pssl:[port][:host]
2980 Listens for SSL connections on the specified TCP port.
2981 Specify 0 for port to have the kernel automatically
2982 choose an available port. If host, which can either be a
2983 DNS name (if built with unbound library) or an IP ad‐
2984 dress, is specified, then connections are restricted to
2985 the resolved or specified local IP address (either IPv4
2986 or IPv6 address). If host is an IPv6 address, wrap in
2987 square brackets, e.g. pssl:6640:[::1]. If host is not
2988 specified then it listens only on IPv4 (but not IPv6) ad‐
2989 dresses. A valid SSL configuration must be provided when
2990 this form is used, this can be specified either via com‐
2991 mand-line options or the SSL table.
2992 If port is not specified, it defaults to 6640.
2994 SSL support is an optional feature that is not always
2996 built as part of Open vSwitch.
2997 ptcp:[port][:host]
2999 Listens for connections on the specified TCP port. Spec‐
3000 ify 0 for port to have the kernel automatically choose an
3001 available port. If host, which can either be a DNS name
3002 (if built with unbound library) or an IP address, is
3003 specified, then connections are restricted to the re‐
3004 solved or specified local IP address (either IPv4 or IPv6
3005 address). If host is an IPv6 address, wrap it in square
3006 brackets, e.g. ptcp:6640:[::1]. If host is not specified
3007 then it listens only on IPv4 addresses.
3008 If port is not specified, it defaults to 6640.
3010 When multiple clients are configured, the target values must be
3012 unique. Duplicate target values yield unspecified results.
3013 read_only: boolean
3015 true to restrict these connections to read-only transactions,
3016 false to allow them to modify the database.
3017 role: string
3019 String containing role name for this connection entry.
3020 Client Failure Detection and Handling:
3022 max_backoff: optional integer, at least 1,000
3024 Maximum number of milliseconds to wait between connection at‐
3025 tempts. Default is implementation-specific.
3026 inactivity_probe: optional integer
3028 Maximum number of milliseconds of idle time on connection to the
3029 client before sending an inactivity probe message. If Open
3030 vSwitch does not communicate with the client for the specified
3031 number of seconds, it will send a probe. If a response is not
3032 received for the same additional amount of time, Open vSwitch
3033 assumes the connection has been broken and attempts to recon‐
3034 nect. Default is implementation-specific. A value of 0 disables
3035 inactivity probes.
3036 Status:
3038 Key-value pair of is_connected is always updated. Other key-value pairs
3040 in the status columns may be updated depends on the target type.
3041 When target specifies a connection method that listens for inbound con‐
3043 nections (e.g. ptcp: or punix:), both n_connections and is_connected
3044 may also be updated while the remaining key-value pairs are omitted.
3045 On the other hand, when target specifies an outbound connection, all
3047 key-value pairs may be updated, except the above-mentioned two key-
3048 value pairs associated with inbound connection targets. They are omit‐
3049 ted.
3050 is_connected: boolean
3052 true if currently connected to this client, false otherwise.
3053 status : last_error: optional string
3055 A human-readable description of the last error on the connection
3056 to the manager; i.e. strerror(errno). This key will exist only
3057 if an error has occurred.
3058 status : state: optional string, one of ACTIVE, BACKOFF, CONNECTING,
3060 IDLE, or VOID
3061 The state of the connection to the manager:
3062 VOID Connection is disabled.
3064 BACKOFF
3066 Attempting to reconnect at an increasing period.
3067 CONNECTING
3069 Attempting to connect.
3070 ACTIVE Connected, remote host responsive.
3072 IDLE Connection is idle. Waiting for response to keep-alive.
3074 These values may change in the future. They are provided only
3076 for human consumption.
3077 status : sec_since_connect: optional string, containing an integer, at
3079 least 0
3080 The amount of time since this client last successfully connected
3081 to the database (in seconds). Value is empty if client has never
3082 successfully been connected.
3083 status : sec_since_disconnect: optional string, containing an integer,
3085 at least 0
3086 The amount of time since this client last disconnected from the
3087 database (in seconds). Value is empty if client has never dis‐
3088 connected.
3089 status : locks_held: optional string
3091 Space-separated list of the names of OVSDB locks that the con‐
3092 nection holds. Omitted if the connection does not hold any
3093 locks.
3094 status : locks_waiting: optional string
3096 Space-separated list of the names of OVSDB locks that the con‐
3097 nection is currently waiting to acquire. Omitted if the connec‐
3098 tion is not waiting for any locks.
3099 status : locks_lost: optional string
3101 Space-separated list of the names of OVSDB locks that the con‐
3102 nection has had stolen by another OVSDB client. Omitted if no
3103 locks have been stolen from this connection.
3104 status : n_connections: optional string, containing an integer, at
3106 least 2
3107 When target specifies a connection method that listens for in‐
3108 bound connections (e.g. ptcp: or pssl:) and more than one con‐
3109 nection is actually active, the value is the number of active
3110 connections. Otherwise, this key-value pair is omitted.
3111 status : bound_port: optional string, containing an integer
3113 When target is ptcp: or pssl:, this is the TCP port on which the
3114 OVSDB server is listening. (This is particularly useful when
3115 target specifies a port of 0, allowing the kernel to choose any
3116 available port.)
3117 Common Columns:
3119 The overall purpose of these columns is described under Common Columns
3121 at the beginning of this document.
3122 external_ids: map of string-string pairs
3124 other_config: map of string-string pairs
3126
3128 SSL configuration for ovn-sb database access.
3129 Summary:
3131 private_key string
3132 certificate string
3133 ca_cert string
3134 bootstrap_ca_cert boolean
3135 ssl_protocols string
3136 ssl_ciphers string
3137 Common Columns:
3138 external_ids map of string-string pairs
3139 Details:
3141 private_key: string
3142 Name of a PEM file containing the private key used as the
3143 switch’s identity for SSL connections to the controller.
3144 certificate: string
3146 Name of a PEM file containing a certificate, signed by the cer‐
3147 tificate authority (CA) used by the controller and manager, that
3148 certifies the switch’s private key, identifying a trustworthy
3149 switch.
3150 ca_cert: string
3152 Name of a PEM file containing the CA certificate used to verify
3153 that the switch is connected to a trustworthy controller.
3154 bootstrap_ca_cert: boolean
3156 If set to true, then Open vSwitch will attempt to obtain the CA
3157 certificate from the controller on its first SSL connection and
3158 save it to the named PEM file. If it is successful, it will im‐
3159 mediately drop the connection and reconnect, and from then on
3160 all SSL connections must be authenticated by a certificate
3161 signed by the CA certificate thus obtained. This option exposes
3162 the SSL connection to a man-in-the-middle attack obtaining the
3163 initial CA certificate. It may still be useful for bootstrap‐
3164 ping.
3165 ssl_protocols: string
3167 List of SSL protocols to be enabled for SSL connections. The de‐
3168 fault when this option is omitted is TLSv1,TLSv1.1,TLSv1.2.
3169 ssl_ciphers: string
3171 List of ciphers (in OpenSSL cipher string format) to be sup‐
3172 ported for SSL connections. The default when this option is
3173 omitted is HIGH:!aNULL:!MD5.
3174 Common Columns:
3176 The overall purpose of these columns is described under Common Columns
3178 at the beginning of this document.
3179 external_ids: map of string-string pairs
3181
3183 Each row in this table stores the DNS records. The OVN action
3184 dns_lookup uses this table for DNS resolution.
3185 Summary:
3187 records map of string-string pairs
3188 datapaths set of 1 or more Datapath_Bindings
3189 Common Columns:
3190 external_ids map of string-string pairs
3191 Details:
3193 records: map of string-string pairs
3194 Key-value pair of DNS records with DNS query name as the key and
3195 a string of IP address(es) separated by comma or space as the
3196 value. ovn-northd stores the DNS query name in all lowercase in
3197 order to facilitate case-insensitive lookups.
3198 Example: "vm1.ovn.org" = "10.0.0.4 aef0::4"
3200 datapaths: set of 1 or more Datapath_Bindings
3202 The DNS records defined in the column records will be applied
3203 only to the DNS queries originating from the datapaths defined
3204 in this column.
3205 Common Columns:
3207 external_ids: map of string-string pairs
3209 See External IDs at the beginning of this document.
3210
3212 Role table for role-based access controls.
3213 Summary:
3215 name string
3216 permissions map of string-weak reference to RBAC_Per‐
3217 mission pairs
3218 Details:
3220 name: string
3221 The role name, corresponding to the role column in the Connec‐
3222 tion table.
3223 permissions: map of string-weak reference to RBAC_Permission pairs
3225 A mapping of table names to rows in the RBAC_Permission table.
3226
3228 Permissions table for role-based access controls.
3229 Summary:
3231 table string
3232 authorization set of strings
3233 insert_delete boolean
3234 update set of strings
3235 Details:
3237 table: string
3238 Name of table to which this row applies.
3239 authorization: set of strings
3241 Set of strings identifying columns and column:key pairs to be
3242 compared with client ID. At least one match is required in order
3243 to be authorized. A zero-length string is treated as a special
3244 value indicating all clients should be considered authorized.
3245 insert_delete: boolean
3247 When "true", row insertions and authorized row deletions are
3248 permitted.
3249 update: set of strings
3251 Set of strings identifying columns and column:key pairs that au‐
3252 thorized clients are allowed to modify.
3253
3255 Association of Port_Binding rows of type chassisredirect to a Chassis.
3256 The traffic going out through a specific chassisredirect port will be
3257 redirected to a chassis, or a set of them in high availability configu‐
3258 rations.
3259 Summary:
3261 name string (must be unique within table)
3262 chassis optional weak reference to Chassis
3263 priority integer, in range 0 to 32,767
3264 options map of string-string pairs
3265 Common Columns:
3266 external_ids map of string-string pairs
3267 Details:
3269 name: string (must be unique within table)
3270 Name of the Gateway_Chassis.
3271 A suggested, but not required naming convention is
3273 ${port_name}_${chassis_name}.
3274 chassis: optional weak reference to Chassis
3276 The Chassis to which we send the traffic.
3277 priority: integer, in range 0 to 32,767
3279 This is the priority the specific Chassis among all Gate‐
3280 way_Chassis belonging to the same Port_Binding.
3281 options: map of string-string pairs
3283 Reserved for future use.
3284 Common Columns:
3286 The overall purpose of these columns is described under Common Columns
3288 at the beginning of this document.
3289 external_ids: map of string-string pairs
3291
3293 Summary:
3294 chassis optional weak reference to Chassis
3295 priority integer, in range 0 to 32,767
3296 Common Columns:
3297 external_ids map of string-string pairs
3298 Details:
3300 chassis: optional weak reference to Chassis
3301 The Chassis which provides the HA functionality.
3302 priority: integer, in range 0 to 32,767
3304 Priority of the HA chassis. Chassis with highest priority will
3305 be the master in the HA chassis group.
3306 Common Columns:
3308 external_ids: map of string-string pairs
3310 See External IDs at the beginning of this document.
3311
3313 Table representing a group of chassis which can provide High availabil‐
3314 ity services. Each chassis in the group is represented by the table
3315 HA_Chassis. The HA chassis with highest priority will be the master of
3316 this group. If the master chassis failover is detected, the HA chassis
3317 with the next higher priority takes over the responsibility of provid‐
3318 ing the HA. If ha_chassis_group column of the table Port_Binding refer‐
3319 ences this table, then this HA chassis group provides the gateway func‐
3320 tionality and redirects the gateway traffic to the master of this
3321 group.
3322 Summary:
3324 name string (must be unique within table)
3325 ha_chassis set of HA_Chassises
3326 ref_chassis set of weak reference to Chassis
3327 Common Columns:
3328 external_ids map of string-string pairs
3329 Details:
3331 name: string (must be unique within table)
3332 Name of the HA_Chassis_Group. Name should be unique.
3333 ha_chassis: set of HA_Chassises
3335 A list of HA_Chassis which belongs to this group.
3336 ref_chassis: set of weak reference to Chassis
3338 The set of Chassis that reference this HA chassis group. To de‐
3339 termine the correct Chassis, find the chassisredirect type
3340 Port_Binding that references this HA_Chassis_Group. This
3341 Port_Binding is derived from some particular logical router.
3342 Starting from that LR, find the set of all logical switches and
3343 routers connected to it, directly or indirectly, across router
3344 ports that link one LRP to another or to a LSP. For each LSP in
3345 these logical switches, find the corresponding Port_Binding and
3346 add its bound Chassis (if any) to ref_chassis.
3347 Common Columns:
3349 external_ids: map of string-string pairs
3351 See External IDs at the beginning of this document.
3352
3354 Database table used by ovn-controller to report CMS related events.
3355 Please note there is no guarantee a given event is written exactly once
3356 in the db. It is CMS responsibility to squash duplicated lines or to
3357 filter out duplicated events
3358 Summary:
3360 event_type string, must be empty_lb_backends
3361 event_info map of string-string pairs
3362 chassis optional weak reference to Chassis
3363 seq_num integer
3364 Details:
3366 event_type: string, must be empty_lb_backends
3367 Event type occurred
3368 event_info: map of string-string pairs
3370 Key-value pairs used to specify event info to the CMS. Possible
3371 values are:
3372 • vip: VIP reported for the empty_lb_backends event
3374 • protocol: Transport protocol reported for the
3376 empty_lb_backends event
3377 • load_balancer: UUID of the load balancer reported for the
3379 empty_lb_backends event
3380 chassis: optional weak reference to Chassis
3382 This column is a Chassis record to identify the chassis that has
3383 managed a given event.
3384 seq_num: integer
3386 Event sequence number. Global counter for controller generated
3387 events. It can be used by the CMS to detect possible duplication
3388 of the same event.
3389
3391 IP Multicast configuration options. For now only applicable to IGMP.
3392 Summary:
3394 datapath weak reference to Datapath_Binding (must
3395 be unique within table)
3396 enabled optional boolean
3397 querier optional boolean
3398 table_size optional integer
3399 idle_timeout optional integer
3400 query_interval optional integer
3401 seq_no integer
3402 Querier configuration options:
3403 eth_src string
3404 ip4_src string
3405 ip6_src string
3406 query_max_resp optional integer
3407 Details:
3409 datapath: weak reference to Datapath_Binding (must be unique within ta‐
3410 ble)
3411 Datapath_Binding entry for which these configuration options are
3412 defined.
3413 enabled: optional boolean
3415 Enables/disables multicast snooping. Default: disabled.
3416 querier: optional boolean
3418 Enables/disables multicast querying. If enabled then multicast
3419 querying is enabled by default.
3420 table_size: optional integer
3422 Limits the number of multicast groups that can be learned. De‐
3423 fault: 2048 groups per datapath.
3424 idle_timeout: optional integer
3426 Configures the idle timeout (in seconds) for IP multicast groups
3427 if multicast snooping is enabled. Default: 300 seconds.
3428 query_interval: optional integer
3430 Configures the interval (in seconds) for sending multicast
3431 queries if snooping and querier are enabled. Default: idle_time‐
3432 out/2 seconds.
3433 seq_no: integer
3435 ovn-controller reads this value and flushes all learned multi‐
3436 cast groups when it detects that seq_no was changed.
3437 Querier configuration options:
3439 The ovn-controller process that runs on OVN hypervisor nodes uses the
3441 following columns to determine field values in IGMP/MLD queries that it
3442 originates:
3443 eth_src: string
3445 Source Ethernet address.
3446 ip4_src: string
3448 Source IPv4 address.
3449 ip6_src: string
3451 Source IPv6 address.
3452 query_max_resp: optional integer
3454 Value (in seconds) to be used as "max-response" field in multi‐
3455 cast queries. Default: 1 second.
3456
3458 Contains learned IGMP groups indexed by address/datapath/chassis.
3459 Summary:
3461 address string
3462 datapath optional weak reference to Datapath_Bind‐
3463 ing
3464 chassis optional weak reference to Chassis
3465 ports set of weak reference to Port_Bindings
3466 Details:
3468 address: string
3469 Destination IPv4 address for the IGMP group.
3470 datapath: optional weak reference to Datapath_Binding
3472 Datapath to which this IGMP group belongs.
3473 chassis: optional weak reference to Chassis
3475 Chassis to which this IGMP group belongs.
3476 ports: set of weak reference to Port_Bindings
3478 The destination port bindings for this IGMP group.
3479
3481 Each row in this table configures monitoring a service for its live‐
3482 ness. The service can be an IPv4 TCP or UDP service. ovn-controller pe‐
3483 riodically sends out service monitor packets and updates the status of
3484 the service. Service monitoring for IPv6 services is not supported.
3485 ovn-northd uses this feature to implement the load balancer health
3487 check feature offered to the CMS through the northbound database.
3488 Summary:
3490 Configuration:
3491 ip string
3492 protocol optional string, either tcp or udp
3493 port integer, in range 0 to 65,535
3494 logical_port string
3495 src_mac string
3496 src_ip string
3497 options : interval optional string, containing an integer
3498 options : timeout optional string, containing an integer
3499 options : success_count optional string, containing an integer
3500 options : failure_count optional string, containing an integer
3501 Status Reporting:
3502 status optional string, one of error, offline,
3503 or online
3504 Common Columns:
3505 external_ids map of string-string pairs
3506 Details:
3508 Configuration:
3509 ovn-northd sets these columns and values to configure the service moni‐
3511 tor.
3512 ip: string
3514 IP of the service to be monitored. Only IPv4 is supported.
3515 protocol: optional string, either tcp or udp
3517 The protocol of the service.
3518 port: integer, in range 0 to 65,535
3520 The TCP or UDP port of the service.
3521 logical_port: string
3523 The VIF of the logical port on which the service is running. The
3524 ovn-controller that binds this logical_port monitors the service
3525 by sending periodic monitor packets.
3526 src_mac: string
3528 Source Ethernet address to use in the service monitor packet.
3529 src_ip: string
3531 Source IPv4 address to use in the service monitor packet.
3532 options : interval: optional string, containing an integer
3534 The interval, in seconds, between service monitor checks.
3535 options : timeout: optional string, containing an integer
3537 The time, in seconds, after which the service monitor check
3538 times out.
3539 options : success_count: optional string, containing an integer
3541 The number of successful checks after which the service is con‐
3542 sidered online.
3543 options : failure_count: optional string, containing an integer
3545 The number of failure checks after which the service is consid‐
3546 ered offline.
3547 Status Reporting:
3549 The ovn-controller on the chassis that hosts the logical_port updates
3551 this column to report the service’s status.
3552 status: optional string, one of error, offline, or online
3554 For TCP service, ovn-controller sends a SYN to the service and
3555 expects an ACK response to consider the service to be online.
3556 For UDP service, ovn-controller sends a UDP packet to the ser‐
3558 vice and doesn’t expect any reply. If it receives an ICMP reply,
3559 then it considers the service to be offline.
3560 Common Columns:
3562 external_ids: map of string-string pairs
3564 See External IDs at the beginning of this document.
3565
3567 Each row represents a load balancer.
3568 Summary:
3570 name string
3571 vips map of string-string pairs
3572 protocol optional string, one of sctp, tcp, or udp
3573 datapaths set of Datapath_Bindings
3574 Load_Balancer options:
3575 options : hairpin_snat_ip optional string
3576 options : hairpin_orig_tuple
3577 optional string, either true or false
3578 Common Columns:
3579 external_ids map of string-string pairs
3580 Details:
3582 name: string
3583 A name for the load balancer. This name has no special meaning
3584 or purpose other than to provide convenience for human interac‐
3585 tion with the ovn-nb database.
3586 vips: map of string-string pairs
3588 A map of virtual IP addresses (and an optional port number with
3589 : as a separator) associated with this load balancer and their
3590 corresponding endpoint IP addresses (and optional port numbers
3591 with : as separators) separated by commas.
3592 protocol: optional string, one of sctp, tcp, or udp
3594 Valid protocols are tcp, udp, or sctp. This column is useful
3595 when a port number is provided as part of the vips column. If
3596 this column is empty and a port number is provided as part of
3597 vips column, OVN assumes the protocol to be tcp.
3598 datapaths: set of Datapath_Bindings
3600 Datapaths to which this load balancer applies to.
3601 Load_Balancer options:
3603 options : hairpin_snat_ip: optional string
3605 IP to be used as source IP for packets that have been hair-
3606 pinned after load balancing. This value is automatically popu‐
3607 lated by ovn-northd.
3608 options : hairpin_orig_tuple: optional string, either true or false
3610 This value is automatically set to true by ovn-northd when orig‐
3611 inal destination IP and transport port of the load balanced
3612 packets are stored in registers reg1, reg2, xxreg1.
3613 Common Columns:
3615 external_ids: map of string-string pairs
3617 See External IDs at the beginning of this document.
3618
3620 Contains BFD parameter for ovn-controller bfd configuration.
3621 Summary:
3623 Configuration:
3624 src_port integer, in range 49,152 to 65,535
3625 disc integer
3626 logical_port string
3627 dst_ip string
3628 min_tx integer
3629 min_rx integer
3630 detect_mult integer
3631 options map of string-string pairs
3632 external_ids map of string-string pairs
3633 Status Reporting:
3634 status string, one of admin_down, down, init, or
3635 up
3636 Details:
3638 Configuration:
3639 src_port: integer, in range 49,152 to 65,535
3641 udp source port used in bfd control packets. The source port
3642 MUST be in the range 49152 through 65535 (RFC5881 section 4).
3643 disc: integer
3645 A unique, nonzero discriminator value generated by the transmit‐
3646 ting system, used to demultiplex multiple BFD sessions between
3647 the same pair of systems.
3648 logical_port: string
3650 OVN logical port when BFD engine is running.
3651 dst_ip: string
3653 BFD peer IP address.
3654 min_tx: integer
3656 This is the minimum interval, in milliseconds, that the local
3657 system would like to use when transmitting BFD Control packets,
3658 less any jitter applied. The value zero is reserved.
3659 min_rx: integer
3661 This is the minimum interval, in milliseconds, between received
3662 BFD Control packets that this system is capable of supporting,
3663 less any jitter applied by the sender. If this value is zero,
3664 the transmitting system does not want the remote system to send
3665 any periodic BFD Control packets.
3666 detect_mult: integer
3668 Detection time multiplier. The negotiated transmit interval,
3669 multiplied by this value, provides the Detection Time for the
3670 receiving system in Asynchronous mode.
3671 options: map of string-string pairs
3673 Reserved for future use.
3674 external_ids: map of string-string pairs
3676 See External IDs at the beginning of this document.
3677 Status Reporting:
3679 status: string, one of admin_down, down, init, or up
3681 BFD port logical states. Possible values are:
3682 • admin_down
3684 • down
3686 • init
3688 • up
3690
3692 This table is primarily used to learn the MACs observed on a VIF which
3693 belongs to a Logical_Switch_Port record in OVN_Northbound whose port
3694 security is disabled and ’unknown’ address set. If port security is
3695 disabled on a Logical_Switch_Port record, OVN should allow traffic with
3696 any source mac from the VIF. This table will be used to deliver a
3697 packet to the VIF, If a packet’s eth.dst is learnt.
3698 Summary:
3700 mac string
3701 dp_key integer, in range 1 to 16,777,215
3702 port_key integer, in range 1 to 16,777,215
3703 Details:
3705 mac: string
3706 The learnt mac address.
3707 dp_key: integer, in range 1 to 16,777,215
3709 The key of the datapath on which this FDB was learnt.
3710 port_key: integer, in range 1 to 16,777,215
3712 The key of the port binding on which this FDB was learnt.
3713
3715 Each record represents a Static_MAC_Binding entry for a logical router.
3716 Summary:
3718 logical_port string
3719 ip string
3720 mac string
3721 override_dynamic_mac boolean
3722 datapath Datapath_Binding
3723 Details:
3725 logical_port: string
3726 The logical router port for the binding.
3727 ip: string
3729 The bound IP address.
3730 mac: string
3732 The Ethernet address to which the IP is bound.
3733 override_dynamic_mac: boolean
3735 Override dynamically learnt MACs.
3736 datapath: Datapath_Binding
3738 The logical datapath to which the logical router port belongs.
3739Open vSwitch 22.06.1 DB Schema 20.23.0 ovn-sb(5)