1 <?xml version=
"1.0" encoding=
"utf-8"?>
2 <database name=
"ovn-sb" title=
"OVN Southbound Database">
4 This database holds logical and physical configuration and state for the
5 Open Virtual Network (OVN) system to support virtual network abstraction.
6 For an introduction to OVN, please see
<code>ovn-architecture
</code>(
7).
10 The OVN Southbound database sits at the center of the OVN
11 architecture. It is the one component that speaks both southbound
12 directly to all the hypervisors and gateways, via
13 <code>ovn-controller
</code>/
<code>ovn-controller-vtep
</code>, and
14 northbound to the Cloud Management System, via
<code>ovn-northd
</code>:
17 <h2>Database Structure
</h2>
20 The OVN Southbound database contains classes of data with
21 different properties, as described in the sections below.
24 <h3>Physical Network (PN) data
</h3>
27 PN tables contain information about the chassis nodes in the system. This
28 contains all the information necessary to wire the overlay, such as IP
29 addresses, supported tunnel types, and security keys.
33 The amount of PN data is small (O(n) in the number of chassis) and it
34 changes infrequently, so it can be replicated to every chassis.
38 The
<ref table=
"Chassis"/> table comprises the PN tables.
41 <h3>Logical Network (LN) data
</h3>
44 LN tables contain the topology of logical switches and routers, ACLs,
45 firewall rules, and everything needed to describe how packets traverse a
46 logical network, represented as logical datapath flows (see Logical
47 Datapath Flows, below).
51 LN data may be large (O(n) in the number of logical ports, ACL rules,
52 etc.). Thus, to improve scaling, each chassis should receive only data
53 related to logical networks in which that chassis participates. Past
54 experience shows that in the presence of large logical networks, even
55 finer-grained partitioning of data, e.g. designing logical flows so that
56 only the chassis hosting a logical port needs related flows, pays off
57 scale-wise. (This is not necessary initially but it is worth bearing in
62 The LN is a slave of the cloud management system running northbound of OVN.
63 That CMS determines the entire OVN logical configuration and therefore the
64 LN's content at any given time is a deterministic function of the CMS's
65 configuration, although that happens indirectly via the
66 <ref db=
"OVN_Northbound"/> database and
<code>ovn-northd
</code>.
70 LN data is likely to change more quickly than PN data. This is especially
71 true in a container environment where VMs are created and destroyed (and
72 therefore added to and deleted from logical switches) quickly.
76 <ref table=
"Logical_Flow"/> and
<ref table=
"Multicast_Group"/> contain LN
80 <h3>Logical-physical bindings
</h3>
83 These tables link logical and physical components. They show the current
84 placement of logical components (such as VMs and VIFs) onto chassis, and
85 map logical entities to the values that represent them in tunnel
90 These tables change frequently, at least every time a VM powers up or down
91 or migrates, and especially quickly in a container environment. The
92 amount of data per VM (or VIF) is small.
96 Each chassis is authoritative about the VMs and VIFs that it hosts at any
97 given time and can efficiently flood that state to a central location, so
98 the consistency needs are minimal.
102 The
<ref table=
"Port_Binding"/> and
<ref table=
"Datapath_Binding"/> tables
103 contain binding data.
106 <h3>MAC bindings
</h3>
109 The
<ref table=
"MAC_Binding"/> table tracks the bindings from IP addresses
110 to Ethernet addresses that are dynamically discovered using ARP (for IPv4)
111 and neighbor discovery (for IPv6). Usually, IP-to-MAC bindings for virtual
112 machines are statically populated into the
<ref table=
"Port_Binding"/>
113 table, so
<ref table=
"MAC_Binding"/> is primarily used to discover bindings
114 on physical networks.
117 <h2>Common Columns
</h2>
120 Some tables contain a special column named
<code>external_ids
</code>. This
121 column has the same form and purpose each place that it appears, so we
122 describe it here to save space later.
126 <dt><code>external_ids
</code>: map of string-string pairs
</dt>
128 Key-value pairs for use by the software that manages the OVN Southbound
129 database rather than by
130 <code>ovn-controller
</code>/
<code>ovn-controller-vtep
</code>. In
131 particular,
<code>ovn-northd
</code> can use key-value pairs in this
132 column to relate entities in the southbound database to higher-level
133 entities (such as entities in the OVN Northbound database). Individual
134 key-value pairs in this column may be documented in some cases to aid
135 in understanding and troubleshooting, but the reader should not mistake
136 such documentation as comprehensive.
140 <table name=
"SB_Global" title=
"Southbound configuration">
142 Southbound configuration for an OVN system. This table must have exactly
146 <group title=
"Status">
147 This column allow a client to track the overall configuration state of
150 <column name=
"nb_cfg">
151 Sequence number for the configuration. When a CMS or
152 <code>ovn-nbctl
</code> updates the northbound database, it increments
153 the
<code>nb_cfg
</code> column in the
<code>NB_Global
</code> table in
154 the northbound database. In turn, when
<code>ovn-northd
</code> updates
155 the southbound database to bring it up to date with these changes, it
156 updates this column to the same value.
160 <group title=
"Common Columns">
161 <column name=
"external_ids">
162 See
<em>External IDs
</em> at the beginning of this document.
165 <group title=
"Connection Options">
166 <column name=
"connections">
167 Database clients to which the Open vSwitch database server should
168 connect or on which it should listen, along with options for how these
169 connections should be configured. See the
<ref table=
"Connection"/>
170 table for more information.
173 Global SSL configuration.
178 <table name=
"Chassis" title=
"Physical Network Hypervisor and Gateway Information">
180 Each row in this table represents a hypervisor or gateway (a chassis) in
181 the physical network (PN). Each chassis, via
182 <code>ovn-controller
</code>/
<code>ovn-controller-vtep
</code>, adds
183 and updates its own row, and keeps a copy of the remaining rows to
184 determine how to reach other hypervisors.
188 When a chassis shuts down gracefully, it should remove its own row.
189 (This is not critical because resources hosted on the chassis are equally
190 unreachable regardless of whether the row is present.) If a chassis
191 shuts down permanently without removing its row, some kind of manual or
192 automatic cleanup is eventually needed; we can devise a process for that
197 OVN does not prescribe a particular format for chassis names.
198 ovn-controller populates this column using
<ref key=
"system-id"
199 table=
"Open_vSwitch" column=
"external_ids" db=
"Open_vSwitch"/>
200 in the Open_vSwitch database's
<ref table=
"Open_vSwitch"
201 db=
"Open_vSwitch"/> table. ovn-controller-vtep populates this
202 column with
<ref table=
"Physical_Switch" column=
"name"
203 db=
"hardware_vtep"/> in the hardware_vtep database's
204 <ref table=
"Physical_Switch" db=
"hardware_vtep"/> table.
207 <column name=
"hostname">
208 The hostname of the chassis, if applicable. ovn-controller will populate
209 this column with the hostname of the host it is running on.
210 ovn-controller-vtep will leave this column empty.
213 <column name=
"nb_cfg">
214 Sequence number for the configuration. When
<code>ovn-controller
</code>
215 updates the configuration of a chassis from the contents of the
216 southbound database, it copies
<ref table=
"SB_Global" column=
"nb_cfg"/>
217 from the
<ref table=
"SB_Global"/> table into this column.
220 <column name=
"external_ids" key=
"ovn-bridge-mappings">
221 <code>ovn-controller
</code> populates this key with the set of bridge
222 mappings it has been configured to use. Other applications should treat
223 this key as read-only. See
<code>ovn-controller
</code>(
8) for more
227 <column name=
"external_ids" key=
"datapath-type">
228 <code>ovn-controller
</code> populates this key with the datapath type
229 configured in the
<ref table=
"Bridge" column=
"datapath_type"/> column of
230 the Open_vSwitch database's
<ref table=
"Bridge" db=
"Open_vSwitch"/>
231 table. Other applications should treat this key as read-only. See
232 <code>ovn-controller
</code>(
8) for more information.
235 <column name=
"external_ids" key=
"iface-types">
236 <code>ovn-controller
</code> populates this key with the interface types
237 configured in the
<ref table=
"Open_vSwitch" column=
"iface_types"/> column
238 of the Open_vSwitch database's
<ref table=
"Open_vSwitch"
239 db=
"Open_vSwitch"/> table. Other applications should treat this key as
240 read-only. See
<code>ovn-controller
</code>(
8) for more information.
243 <group title=
"Common Columns">
244 The overall purpose of these columns is described under
<code>Common
245 Columns
</code> at the beginning of this document.
247 <column name=
"external_ids"/>
250 <group title=
"Encapsulation Configuration">
252 OVN uses encapsulation to transmit logical dataplane packets
256 <column name=
"encaps">
257 Points to supported encapsulation configurations to transmit
258 logical dataplane packets to this chassis. Each entry is a
<ref
259 table=
"Encap"/> record that describes the configuration.
263 <group title=
"Gateway Configuration">
265 A
<dfn>gateway
</dfn> is a chassis that forwards traffic between the
266 OVN-managed part of a logical network and a physical VLAN, extending a
267 tunnel-based logical network into a physical network. Gateways are
268 typically dedicated nodes that do not host VMs and will be controlled
269 by
<code>ovn-controller-vtep
</code>.
272 <column name=
"vtep_logical_switches">
273 Stores all VTEP logical switch names connected by this gateway
274 chassis. The
<ref table=
"Port_Binding"/> table entry with
275 <ref column=
"options" table=
"Port_Binding"/>:
<code>vtep-physical-switch
</code>
276 equal
<ref table=
"Chassis"/> <ref column=
"name" table=
"Chassis"/>, and
277 <ref column=
"options" table=
"Port_Binding"/>:
<code>vtep-logical-switch
</code>
278 value in
<ref table=
"Chassis"/>
279 <ref column=
"vtep_logical_switches" table=
"Chassis"/>, will be
280 associated with this
<ref table=
"Chassis"/>.
285 <table name=
"Encap" title=
"Encapsulation Types">
287 The
<ref column=
"encaps" table=
"Chassis"/> column in the
<ref
288 table=
"Chassis"/> table refers to rows in this table to identify
289 how OVN may transmit logical dataplane packets to this chassis.
290 Each chassis, via
<code>ovn-controller
</code>(
8) or
291 <code>ovn-controller-vtep
</code>(
8), adds and updates its own rows
292 and keeps a copy of the remaining rows to determine how to reach
297 The encapsulation to use to transmit packets to this chassis.
298 Hypervisors must use either
<code>geneve
</code> or
299 <code>stt
</code>. Gateways may use
<code>vxlan
</code>,
300 <code>geneve
</code>, or
<code>stt
</code>.
303 <column name=
"options">
305 Options for configuring the encapsulation. Currently, the only
306 option that has been defined is
<code>csum
</code>.
310 <code>csum
</code> indicates that encapsulation checksums can be
311 transmitted and received with reasonable performance. It is a hint
312 to senders transmitting data to this chassis that they should use
313 checksums to protect OVN metadata. Set to
<code>true
</code> to enable
314 or
<code>false
</code> to disable.
318 In terms of performance, this actually significantly increases
319 throughput in most common cases when running on Linux based hosts
320 without NICs supporting encapsulation hardware offload (around
60% for
321 bulk traffic). The reason is that generally all NICs are capable of
322 offloading transmitted and received TCP/UDP checksums (viewed as
323 ordinary data packets and not as tunnels). The benefit comes on the
324 receive side where the validated outer checksum can be used to
325 additionally validate an inner checksum (such as TCP), which in turn
326 allows aggregation of packets to be more efficiently handled by the
331 Not all devices see such a benefit. The most notable exception is
332 hardware VTEPs. These devices are designed to not buffer entire
333 packets in their switching engines and are therefore unable to
334 efficiently compute or validate full packet checksums. In addition
335 certain versions of the Linux kernel are not able to fully take
336 advantage of encapsulation NIC offloads in the presence of checksums.
337 (This is actually a pretty narrow corner case though - earlier
338 versions of Linux don't support encapsulation offloads at all and
339 later versions support both offloads and checksums well.)
343 <code>csum
</code> defaults to
<code>false
</code> for hardware VTEPs and
344 <code>true
</code> for all other cases.
349 The IPv4 address of the encapsulation tunnel endpoint.
353 <table name=
"Address_Set" title=
"Address Sets">
355 See the documentation for the
<ref table=
"Address_Set"
356 db=
"OVN_Northbound"/> table in the
<ref db=
"OVN_Northbound"/> database
360 <column name=
"name"/>
361 <column name=
"addresses"/>
364 <table name=
"Logical_Flow" title=
"Logical Network Flows">
366 Each row in this table represents one logical flow.
367 <code>ovn-northd
</code> populates this table with logical flows
368 that implement the L2 and L3 topologies specified in the
369 <ref db=
"OVN_Northbound"/> database. Each hypervisor, via
370 <code>ovn-controller
</code>, translates the logical flows into
371 OpenFlow flows specific to its hypervisor and installs them into
376 Logical flows are expressed in an OVN-specific format, described here. A
377 logical datapath flow is much like an OpenFlow flow, except that the
378 flows are written in terms of logical ports and logical datapaths instead
379 of physical ports and physical datapaths. Translation between logical
380 and physical flows helps to ensure isolation between logical datapaths.
381 (The logical flow abstraction also allows the OVN centralized
382 components to do less work, since they do not have to separately
383 compute and push out physical flows to each chassis.)
387 The default action when no flow matches is to drop packets.
390 <p><em>Architectural Logical Life Cycle of a Packet
</em></p>
393 This following description focuses on the life cycle of a packet through
394 a logical datapath, ignoring physical details of the implementation.
395 Please refer to
<em>Architectural Physical Life Cycle of a Packet
</em> in
396 <code>ovn-architecture
</code>(
7) for the physical information.
400 The description here is written as if OVN itself executes these steps,
401 but in fact OVN (that is,
<code>ovn-controller
</code>) programs Open
402 vSwitch, via OpenFlow and OVSDB, to execute them on its behalf.
406 At a high level, OVN passes each packet through the logical datapath's
407 logical ingress pipeline, which may output the packet to one or more
408 logical port or logical multicast groups. For each such logical output
409 port, OVN passes the packet through the datapath's logical egress
410 pipeline, which may either drop the packet or deliver it to the
411 destination. Between the two pipelines, outputs to logical multicast
412 groups are expanded into logical ports, so that the egress pipeline only
413 processes a single logical output port at a time. Between the two
414 pipelines is also where, when necessary, OVN encapsulates a packet in a
415 tunnel (or tunnels) to transmit to remote hypervisors.
419 In more detail, to start, OVN searches the
<ref table=
"Logical_Flow"/>
420 table for a row with correct
<ref column=
"logical_datapath"/>, a
<ref
421 column=
"pipeline"/> of
<code>ingress
</code>, a
<ref column=
"table_id"/>
422 of
0, and a
<ref column=
"match"/> that is true for the packet. If none
423 is found, OVN drops the packet. If OVN finds more than one, it chooses
424 the match with the highest
<ref column=
"priority"/>. Then OVN executes
425 each of the actions specified in the row's
<ref table=
"actions"/> column,
426 in the order specified. Some actions, such as those to modify packet
427 headers, require no further details. The
<code>next
</code> and
428 <code>output
</code> actions are special.
432 The
<code>next
</code> action causes the above process to be repeated
433 recursively, except that OVN searches for
<ref column=
"table_id"/> of
1
434 instead of
0. Similarly, any
<code>next
</code> action in a row found in
435 that table would cause a further search for a
<ref column=
"table_id"/> of
436 2, and so on. When recursive processing completes, flow control returns
437 to the action following
<code>next
</code>.
441 The
<code>output
</code> action also introduces recursion. Its effect
442 depends on the current value of the
<code>outport
</code> field. Suppose
443 <code>outport
</code> designates a logical port. First, OVN compares
444 <code>inport
</code> to
<code>outport
</code>; if they are equal, it treats
445 the
<code>output
</code> as a no-op by default. In the common
446 case, where they are different, the packet enters the egress
447 pipeline. This transition to the egress pipeline discards
448 register data, e.g.
<code>reg0
</code> ...
<code>reg9
</code> and
449 connection tracking state, to achieve uniform behavior regardless
450 of whether the egress pipeline is on a different hypervisor
451 (because registers aren't preserve across tunnel encapsulation).
455 To execute the egress pipeline, OVN again searches the
<ref
456 table=
"Logical_Flow"/> table for a row with correct
<ref
457 column=
"logical_datapath"/>, a
<ref column=
"table_id"/> of
0, a
<ref
458 column=
"match"/> that is true for the packet, but now looking for a
<ref
459 column=
"pipeline"/> of
<code>egress
</code>. If no matching row is found,
460 the output becomes a no-op. Otherwise, OVN executes the actions for the
461 matching flow (which is chosen from multiple, if necessary, as already
466 In the
<code>egress
</code> pipeline, the
<code>next
</code> action acts as
467 already described, except that it, of course, searches for
468 <code>egress
</code> flows. The
<code>output
</code> action, however, now
469 directly outputs the packet to the output port (which is now fixed,
470 because
<code>outport
</code> is read-only within the egress pipeline).
474 The description earlier assumed that
<code>outport
</code> referred to a
475 logical port. If it instead designates a logical multicast group, then
476 the description above still applies, with the addition of fan-out from
477 the logical multicast group to each logical port in the group. For each
478 member of the group, OVN executes the logical pipeline as described, with
479 the logical output port replaced by the group member.
482 <p><em>Pipeline Stages
</em></p>
485 <code>ovn-northd
</code> populates the
<ref table=
"Logical_Flow"/> table
486 with the logical flows described in detail in
<code>ovn-northd
</code>(
8).
489 <column name=
"logical_datapath">
490 The logical datapath to which the logical flow belongs.
493 <column name=
"pipeline">
495 The primary flows used for deciding on a packet's destination are the
496 <code>ingress
</code> flows. The
<code>egress
</code> flows implement
497 ACLs. See
<em>Logical Life Cycle of a Packet
</em>, above, for details.
501 <column name=
"table_id">
502 The stage in the logical pipeline, analogous to an OpenFlow table number.
505 <column name=
"priority">
506 The flow's priority. Flows with numerically higher priority take
507 precedence over those with lower. If two logical datapath flows with the
508 same priority both match, then the one actually applied to the packet is
512 <column name=
"match">
514 A matching expression. OVN provides a superset of OpenFlow matching
515 capabilities, using a syntax similar to Boolean expressions in a
516 programming language.
520 The most important components of match expression are
521 <dfn>comparisons
</dfn> between
<dfn>symbols
</dfn> and
522 <dfn>constants
</dfn>, e.g.
<code>ip4.dst ==
192.168.0.1</code>,
523 <code>ip.proto ==
6</code>,
<code>arp.op ==
1</code>,
<code>eth.type ==
524 0x800</code>. The logical AND operator
<code>&&</code> and
525 logical OR operator
<code>||
</code> can combine comparisons into a
530 Matching expressions also support parentheses for grouping, the logical
531 NOT prefix operator
<code>!
</code>, and literals
<code>0</code> and
532 <code>1</code> to express ``false'' or ``true,'' respectively. The
533 latter is useful by itself as a catch-all expression that matches every
538 Match expressions also support a kind of function syntax. The
539 following functions are supported:
543 <dt><code>is_chassis_resident(
<var>lport
</var>)
</code></dt>
545 Evaluates to true on a chassis on which logical port
<var>lport
</var>
546 (a quoted string) resides, and to false elsewhere. This function was
547 introduced in OVN
2.7.
551 <p><em>Symbols
</em></p>
554 <em>Type
</em>. Symbols have
<dfn>integer
</dfn> or
<dfn>string
</dfn>
555 type. Integer symbols have a
<dfn>width
</dfn> in bits.
559 <em>Kinds
</em>. There are three kinds of symbols:
565 <dfn>Fields
</dfn>. A field symbol represents a packet header or
566 metadata field. For example, a field
567 named
<code>vlan.tci
</code> might represent the VLAN TCI field in a
572 A field symbol can have integer or string type. Integer fields can
573 be nominal or ordinal (see
<em>Level of Measurement
</em>,
580 <dfn>Subfields
</dfn>. A subfield represents a subset of bits from
581 a larger field. For example, a field
<code>vlan.vid
</code> might
582 be defined as an alias for
<code>vlan.tci[
0.
.11]
</code>. Subfields
583 are provided for syntactic convenience, because it is always
584 possible to instead refer to a subset of bits from a field
589 Only ordinal fields (see
<em>Level of Measurement
</em>,
590 below) may have subfields. Subfields are always ordinal.
596 <dfn>Predicates
</dfn>. A predicate is shorthand for a Boolean
597 expression. Predicates may be used much like
1-bit fields. For
598 example,
<code>ip4
</code> might expand to
<code>eth.type ==
599 0x800</code>. Predicates are provided for syntactic convenience,
600 because it is always possible to instead specify the underlying
605 A predicate whose expansion refers to any nominal field or
606 predicate (see
<em>Level of Measurement
</em>, below) is nominal;
607 other predicates have Boolean level of measurement.
613 <em>Level of Measurement
</em>. See
614 http://en.wikipedia.org/wiki/Level_of_measurement for the statistical
615 concept on which this classification is based. There are three
622 <dfn>Ordinal
</dfn>. In statistics, ordinal values can be ordered
623 on a scale. OVN considers a field (or subfield) to be ordinal if
624 its bits can be examined individually. This is true for the
625 OpenFlow fields that OpenFlow or Open vSwitch makes ``maskable.''
629 Any use of a nominal field may specify a single bit or a range of
630 bits, e.g.
<code>vlan.tci[
13.
.15]
</code> refers to the PCP field
631 within the VLAN TCI, and
<code>eth.dst[
40]
</code> refers to the
632 multicast bit in the Ethernet destination address.
636 OVN supports all the usual arithmetic relations (
<code>==
</code>,
637 <code>!=
</code>,
<code><</code>,
<code><=
</code>,
638 <code>></code>, and
<code>>=
</code>) on ordinal fields and
639 their subfields, because OVN can implement these in OpenFlow and
640 Open vSwitch as collections of bitwise tests.
646 <dfn>Nominal
</dfn>. In statistics, nominal values cannot be
647 usefully compared except for equality. This is true of OpenFlow
648 port numbers, Ethernet types, and IP protocols are examples: all of
649 these are just identifiers assigned arbitrarily with no deeper
650 meaning. In OpenFlow and Open vSwitch, bits in these fields
651 generally aren't individually addressable.
655 OVN only supports arithmetic tests for equality on nominal fields,
656 because OpenFlow and Open vSwitch provide no way for a flow to
657 efficiently implement other comparisons on them. (A test for
658 inequality can be sort of built out of two flows with different
659 priorities, but OVN matching expressions always generate flows with
664 String fields are always nominal.
670 <dfn>Boolean
</dfn>. A nominal field that has only two values,
0
671 and
1, is somewhat exceptional, since it is easy to support both
672 equality and inequality tests on such a field: either one can be
673 implemented as a test for
0 or
1.
677 Only predicates (see above) have a Boolean level of measurement.
681 This isn't a standard level of measurement.
687 <em>Prerequisites
</em>. Any symbol can have prerequisites, which are
688 additional condition implied by the use of the symbol. For example,
689 For example,
<code>icmp4.type
</code> symbol might have prerequisite
690 <code>icmp4
</code>, which would cause an expression
<code>icmp4.type ==
691 0</code> to be interpreted as
<code>icmp4.type ==
0 &&
692 icmp4
</code>, which would in turn expand to
<code>icmp4.type ==
0
693 && eth.type ==
0x800 && ip4.proto ==
1</code> (assuming
694 <code>icmp4
</code> is a predicate defined as suggested under
695 <em>Types
</em> above).
698 <p><em>Relational operators
</em></p>
701 All of the standard relational operators
<code>==
</code>,
702 <code>!=
</code>,
<code><</code>,
<code><=
</code>,
703 <code>></code>, and
<code>>=
</code> are supported. Nominal
704 fields support only
<code>==
</code> and
<code>!=
</code>, and only in a
705 positive sense when outer
<code>!
</code> are taken into account,
706 e.g. given string field
<code>inport
</code>,
<code>inport ==
707 "eth0"</code> and
<code>!(inport !=
"eth0")
</code> are acceptable, but
708 not
<code>inport !=
"eth0"</code>.
712 The implementation of
<code>==
</code> (or
<code>!=
</code> when it is
713 negated), is more efficient than that of the other relational
717 <p><em>Constants
</em></p>
720 Integer constants may be expressed in decimal, hexadecimal prefixed by
721 <code>0x
</code>, or as dotted-quad IPv4 addresses, IPv6 addresses in
722 their standard forms, or Ethernet addresses as colon-separated hex
723 digits. A constant in any of these forms may be followed by a slash
724 and a second constant (the mask) in the same form, to form a masked
725 constant. IPv4 and IPv6 masks may be given as integers, to express
730 String constants have the same syntax as quoted strings in JSON (thus,
731 they are Unicode strings).
735 Some operators support sets of constants written inside curly braces
736 <code>{
</code> ...
<code>}
</code>. Commas between elements of a set,
737 and after the last elements, are optional. With
<code>==
</code>,
738 ``
<code><var>field
</var> == {
<var>constant1
</var>,
739 <var>constant2
</var>,
</code> ...
<code>}
</code>'' is syntactic sugar
740 for ``
<code><var>field
</var> ==
<var>constant1
</var> ||
741 <var>field
</var> ==
<var>constant2
</var> ||
</code>...
<code></code>.
742 Similarly, ``
<code><var>field
</var> != {
<var>constant1
</var>,
743 <var>constant2
</var>,
</code>...
<code> }
</code>'' is equivalent to
744 ``
<code><var>field
</var> !=
<var>constant1
</var> &&
745 <var>field
</var> !=
<var>constant2
</var> &&
746 </code>...
<code></code>''.
750 You may refer to a set of IPv4, IPv6, or MAC addresses stored in the
751 <ref table=
"Address_Set"/> table by its
<ref column=
"name"
752 table=
"Address_Set"/>. An
<ref table=
"Address_Set"/> with a name
753 of
<code>set1
</code> can be referred to as
757 <p><em>Miscellaneous
</em></p>
760 Comparisons may name the symbol or the constant first,
761 e.g.
<code>tcp.src ==
80</code> and
<code>80 == tcp.src
</code> are both
766 Tests for a range may be expressed using a syntax like
<code>1024 <=
767 tcp.src
<=
49151</code>, which is equivalent to
<code>1024 <=
768 tcp.src
&& tcp.src
<=
49151</code>.
772 For a one-bit field or predicate, a mention of its name is equivalent
773 to
<code><var>symobl
</var> ==
1</code>, e.g.
<code>vlan.present
</code>
774 is equivalent to
<code>vlan.present ==
1</code>. The same is true for
775 one-bit subfields, e.g.
<code>vlan.tci[
12]
</code>. There is no
776 technical limitation to implementing the same for ordinal fields of all
777 widths, but the implementation is expensive enough that the syntax
778 parser requires writing an explicit comparison against zero to make
779 mistakes less likely, e.g. in
<code>tcp.src !=
0</code> the comparison
780 against
0 is required.
784 <em>Operator precedence
</em> is as shown below, from highest to lowest.
785 There are two exceptions where parentheses are required even though the
786 table would suggest that they are not:
<code>&&</code> and
787 <code>||
</code> require parentheses when used together, and
788 <code>!
</code> requires parentheses when applied to a relational
789 expression. Thus, in
<code>(eth.type ==
0x800 || eth.type ==
0x86dd)
790 && ip.proto ==
6</code> or
<code>!(arp.op ==
1)
</code>, the
791 parentheses are mandatory.
795 <li><code>()
</code></li>
796 <li><code>== !=
< <=
> >=
</code></li>
797 <li><code>!
</code></li>
798 <li><code>&& ||
</code></li>
802 <em>Comments
</em> may be introduced by
<code>//
</code>, which extends
803 to the next new-line. Comments within a line may be bracketed by
804 <code>/*
</code> and
<code>*/
</code>. Multiline comments are not
808 <p><em>Symbols
</em></p>
811 Most of the symbols below have integer type. Only
<code>inport
</code>
812 and
<code>outport
</code> have string type.
<code>inport
</code> names a
813 logical port. Thus, its value is a
<ref column=
"logical_port"/> name
814 from the
<ref table=
"Port_Binding"/> table.
<code>outport
</code> may
815 name a logical port, as
<code>inport
</code>, or a logical multicast
816 group defined in the
<ref table=
"Multicast_Group"/> table. For both
817 symbols, only names within the flow's logical datapath may be used.
821 The
<code>reg
</code><var>X
</var> symbols are
32-bit integers.
822 The
<code>xxreg
</code><var>X
</var> symbols are
128-bit integers,
823 which overlay four of the
32-bit registers:
<code>xxreg0
</code>
824 overlays
<code>reg0
</code> through
<code>reg3
</code>, with
825 <code>reg0
</code> supplying the most-significant bits of
826 <code>xxreg0
</code> and
<code>reg3
</code> the least-signficant.
827 <code>xxreg1
</code> similarly overlays
<code>reg4
</code> through
832 <li><code>reg0
</code>...
<code>reg9
</code></li>
833 <li><code>xxreg0
</code> <code>xxreg1
</code></li>
834 <li><code>inport
</code> <code>outport
</code></li>
835 <li><code>flags.loopback
</code></li>
836 <li><code>eth.src
</code> <code>eth.dst
</code> <code>eth.type
</code></li>
837 <li><code>vlan.tci
</code> <code>vlan.vid
</code> <code>vlan.pcp
</code> <code>vlan.present
</code></li>
838 <li><code>ip.proto
</code> <code>ip.dscp
</code> <code>ip.ecn
</code> <code>ip.ttl
</code> <code>ip.frag
</code></li>
839 <li><code>ip4.src
</code> <code>ip4.dst
</code></li>
840 <li><code>ip6.src
</code> <code>ip6.dst
</code> <code>ip6.label
</code></li>
841 <li><code>arp.op
</code> <code>arp.spa
</code> <code>arp.tpa
</code> <code>arp.sha
</code> <code>arp.tha
</code></li>
842 <li><code>tcp.src
</code> <code>tcp.dst
</code> <code>tcp.flags
</code></li>
843 <li><code>udp.src
</code> <code>udp.dst
</code></li>
844 <li><code>sctp.src
</code> <code>sctp.dst
</code></li>
845 <li><code>icmp4.type
</code> <code>icmp4.code
</code></li>
846 <li><code>icmp6.type
</code> <code>icmp6.code
</code></li>
847 <li><code>nd.target
</code> <code>nd.sll
</code> <code>nd.tll
</code></li>
848 <li><code>ct_mark
</code> <code>ct_label
</code></li>
851 <code>ct_state
</code>, which has the following Boolean subfields:
854 <li><code>ct.new
</code>: True for a new flow
</li>
855 <li><code>ct.est
</code>: True for an established flow
</li>
856 <li><code>ct.rel
</code>: True for a related flow
</li>
857 <li><code>ct.rpl
</code>: True for a reply flow
</li>
858 <li><code>ct.inv
</code>: True for a connection entry in a bad state
</li>
861 The above subfields of
<code>ct_state
</code> are initialized by
862 the
<code>ct_next
</code> action, described later.
866 <code>ct.dnat
</code>: True for a packet whose destination IP
867 address has been changed.
870 <code>ct.snat
</code>: True for a packet whose source IP
871 address has been changed.
875 The above subfields of
<code>ct_state
</code> are initialized by
876 the actions like
<code>ct_dnat
</code>,
<code>ct_snat
</code> and
877 <code>ct_lb
</code> described later.
883 The following predicates are supported:
887 <li><code>eth.bcast
</code> expands to
<code>eth.dst == ff:ff:ff:ff:ff:ff
</code></li>
888 <li><code>eth.mcast
</code> expands to
<code>eth.dst[
40]
</code></li>
889 <li><code>vlan.present
</code> expands to
<code>vlan.tci[
12]
</code></li>
890 <li><code>ip4
</code> expands to
<code>eth.type ==
0x800</code></li>
891 <li><code>ip4.mcast
</code> expands to
<code>ip4.dst[
28.
.31] ==
0xe</code></li>
892 <li><code>ip6
</code> expands to
<code>eth.type ==
0x86dd</code></li>
893 <li><code>ip
</code> expands to
<code>ip4 || ip6
</code></li>
894 <li><code>icmp4
</code> expands to
<code>ip4
&& ip.proto ==
1</code></li>
895 <li><code>icmp6
</code> expands to
<code>ip6
&& ip.proto ==
58</code></li>
896 <li><code>icmp
</code> expands to
<code>icmp4 || icmp6
</code></li>
897 <li><code>ip.is_frag
</code> expands to
<code>ip.frag[
0]
</code></li>
898 <li><code>ip.later_frag
</code> expands to
<code>ip.frag[
1]
</code></li>
899 <li><code>ip.first_frag
</code> expands to
<code>ip.is_frag
&& !ip.later_frag
</code></li>
900 <li><code>arp
</code> expands to
<code>eth.type ==
0x806</code></li>
901 <li><code>nd
</code> expands to
<code>icmp6.type == {
135,
136}
&& icmp6.code ==
0 && ip.ttl ==
255</code></li>
902 <li><code>nd_ns
</code> expands to
<code>icmp6.type ==
135 && icmp6.code ==
0 && ip.ttl ==
255</code></li>
903 <li><code>nd_na
</code> expands to
<code>icmp6.type ==
136 && icmp6.code ==
0 && ip.ttl ==
255</code></li>
904 <li><code>tcp
</code> expands to
<code>ip.proto ==
6</code></li>
905 <li><code>udp
</code> expands to
<code>ip.proto ==
17</code></li>
906 <li><code>sctp
</code> expands to
<code>ip.proto ==
132</code></li>
910 <column name=
"actions">
912 Logical datapath actions, to be executed when the logical flow
913 represented by this row is the highest-priority match.
917 Actions share lexical syntax with the
<ref column=
"match"/> column. An
918 empty set of actions (or one that contains just white space or
919 comments), or a set of actions that consists of just
920 <code>drop;
</code>, causes the matched packets to be dropped.
921 Otherwise, the column should contain a sequence of actions, each
922 terminated by a semicolon.
926 The following actions are defined:
930 <dt><code>output;
</code></dt>
933 In the ingress pipeline, this action executes the
934 <code>egress
</code> pipeline as a subroutine. If
935 <code>outport
</code> names a logical port, the egress pipeline
936 executes once; if it is a multicast group, the egress pipeline runs
937 once for each logical port in the group.
941 In the egress pipeline, this action performs the actual
942 output to the
<code>outport
</code> logical port. (In the egress
943 pipeline,
<code>outport
</code> never names a multicast group.)
947 By default, output to the input port is implicitly dropped,
948 that is,
<code>output
</code> becomes a no-op if
949 <code>outport
</code> ==
<code>inport
</code>. Occasionally
950 it may be useful to override this behavior, e.g. to send an
951 ARP reply to an ARP request; to do so, use
952 <code>flags.loopback =
1</code> to allow the packet to
953 "hair-pin" back to the input port.
957 <dt><code>next;
</code></dt>
958 <dt><code>next(
<var>table
</var>);
</code></dt>
960 Executes another logical datapath table as a subroutine. By default,
961 the table after the current one is executed. Specify
962 <var>table
</var> to jump to a specific table in the same pipeline.
965 <dt><code><var>field
</var> =
<var>constant
</var>;
</code></dt>
968 Sets data or metadata field
<var>field
</var> to constant value
969 <var>constant
</var>, e.g.
<code>outport =
"vif0";
</code> to set the
970 logical output port. To set only a subset of bits in a field,
971 specify a subfield for
<var>field
</var> or a masked
972 <var>constant
</var>, e.g. one may use
<code>vlan.pcp[
2] =
1;
</code>
973 or
<code>vlan.pcp =
4/
4;
</code> to set the most sigificant bit of
978 Assigning to a field with prerequisites implicitly adds those
979 prerequisites to
<ref column=
"match"/>; thus, for example, a flow
980 that sets
<code>tcp.dst
</code> applies only to TCP flows,
981 regardless of whether its
<ref column=
"match"/> mentions any TCP
986 Not all fields are modifiable (e.g.
<code>eth.type
</code> and
987 <code>ip.proto
</code> are read-only), and not all modifiable fields
988 may be partially modified (e.g.
<code>ip.ttl
</code> must assigned
989 as a whole). The
<code>outport
</code> field is modifiable in the
990 <code>ingress
</code> pipeline but not in the
<code>egress
</code>
995 <dt><code><var>field1
</var> =
<var>field2
</var>;
</code></dt>
998 Sets data or metadata field
<var>field1
</var> to the value of data
999 or metadata field
<var>field2
</var>, e.g.
<code>reg0 =
1000 ip4.src;
</code> copies
<code>ip4.src
</code> into
<code>reg0
</code>.
1001 To modify only a subset of a field's bits, specify a subfield for
1002 <var>field1
</var> or
<var>field2
</var> or both, e.g.
<code>vlan.pcp
1003 = reg0[
0.
.2];
</code> copies the least-significant bits of
1004 <code>reg0
</code> into the VLAN PCP.
1008 <var>field1
</var> and
<var>field2
</var> must be the same type,
1009 either both string or both integer fields. If they are both
1010 integer fields, they must have the same width.
1014 If
<var>field1
</var> or
<var>field2
</var> has prerequisites, they
1015 are added implicitly to
<ref column=
"match"/>. It is possible to
1016 write an assignment with contradictory prerequisites, such as
1017 <code>ip4.src = ip6.src[
0.
.31];
</code>, but the contradiction means
1018 that a logical flow with such an assignment will never be matched.
1022 <dt><code><var>field1
</var> <-
> <var>field2
</var>;
</code></dt>
1025 Similar to
<code><var>field1
</var> =
<var>field2
</var>;
</code>
1026 except that the two values are exchanged instead of copied. Both
1027 <var>field1
</var> and
<var>field2
</var> must modifiable.
1031 <dt><code>ip.ttl--;
</code></dt>
1034 Decrements the IPv4 or IPv6 TTL. If this would make the TTL zero
1035 or negative, then processing of the packet halts; no further
1036 actions are processed. (To properly handle such cases, a
1037 higher-priority flow should match on
1038 <code>ip.ttl == {
0,
1};
</code>.)
1041 <p><b>Prerequisite:
</b> <code>ip
</code></p>
1044 <dt><code>ct_next;
</code></dt>
1047 Apply connection tracking to the flow, initializing
1048 <code>ct_state
</code> for matching in later tables.
1049 Automatically moves on to the next table, as if followed by
1054 As a side effect, IP fragments will be reassembled for matching.
1055 If a fragmented packet is output, then it will be sent with any
1056 overlapping fragments squashed. The connection tracking state is
1057 scoped by the logical port when the action is used in a flow for
1058 a logical switch, so overlapping addresses may be used. To allow
1059 traffic related to the matched flow, execute
<code>ct_commit
1060 </code>. Connection tracking state is scoped by the logical
1061 topology when the action is used in a flow for a router.
1065 It is possible to have actions follow
<code>ct_next
</code>,
1066 but they will not have access to any of its side-effects and
1067 is not generally useful.
1071 <dt><code>ct_commit;
</code></dt>
1072 <dt><code>ct_commit(ct_mark=
<var>value[/mask]
</var>);
</code></dt>
1073 <dt><code>ct_commit(ct_label=
<var>value[/mask]
</var>);
</code></dt>
1074 <dt><code>ct_commit(ct_mark=
<var>value[/mask]
</var>, ct_label=
<var>value[/mask]
</var>);
</code></dt>
1077 Commit the flow to the connection tracking entry associated with it
1078 by a previous call to
<code>ct_next
</code>. When
1079 <code>ct_mark=
<var>value[/mask]
</var></code> and/or
1080 <code>ct_label=
<var>value[/mask]
</var></code> are supplied,
1081 <code>ct_mark
</code> and/or
<code>ct_label
</code> will be set to the
1082 values indicated by
<var>value[/mask]
</var> on the connection
1083 tracking entry.
<code>ct_mark
</code> is a
32-bit field.
1084 <code>ct_label
</code> is a
128-bit field. The
<var>value[/mask]
</var>
1085 should be specified in hex string if more than
64bits are to be used.
1089 Note that if you want processing to continue in the next table,
1090 you must execute the
<code>next
</code> action after
1091 <code>ct_commit
</code>. You may also leave out
<code>next
</code>
1092 which will commit connection tracking state, and then drop the
1093 packet. This could be useful for setting
<code>ct_mark
</code>
1094 on a connection tracking entry before dropping a packet,
1099 <dt><code>ct_dnat;
</code></dt>
1100 <dt><code>ct_dnat(
<var>IP
</var>);
</code></dt>
1103 <code>ct_dnat
</code> sends the packet through the DNAT zone in
1104 connection tracking table to unDNAT any packet that was DNATed in
1105 the opposite direction. The packet is then automatically sent to
1106 to the next tables as if followed by
<code>next;
</code> action.
1107 The next tables will see the changes in the packet caused by
1108 the connection tracker.
1111 <code>ct_dnat(
<var>IP
</var>)
</code> sends the packet through the
1112 DNAT zone to change the destination IP address of the packet to
1113 the one provided inside the parentheses and commits the connection.
1114 The packet is then automatically sent to the next tables as if
1115 followed by
<code>next;
</code> action. The next tables will see
1116 the changes in the packet caused by the connection tracker.
1120 <dt><code>ct_snat;
</code></dt>
1121 <dt><code>ct_snat(
<var>IP
</var>);
</code></dt>
1124 <code>ct_snat
</code> sends the packet through the SNAT zone to
1125 unSNAT any packet that was SNATed in the opposite direction. If
1126 the packet needs to be sent to the next tables, then it should be
1127 followed by a
<code>next;
</code> action. The next tables will not
1128 see the changes in the packet caused by the connection tracker.
1131 <code>ct_snat(
<var>IP
</var>)
</code> sends the packet through the
1132 SNAT zone to change the source IP address of the packet to
1133 the one provided inside the parenthesis and commits the connection.
1134 The packet is then automatically sent to the next tables as if
1135 followed by
<code>next;
</code> action. The next tables will see the
1136 changes in the packet caused by the connection tracker.
1141 <dt><code>clone {
<var>action
</var>;
</code>...
<code> };
</code></dt>
1143 Makes a copy of the packet being processed and executes each
1144 <code>action
</code> on the copy. Actions following the
1145 <var>clone
</var> action, if any, apply to the original, unmodified
1146 packet. This can be used as a way to ``save and restore'' the packet
1147 around a set of actions that may modify it and should not persist.
1150 <dt><code>arp {
<var>action
</var>;
</code>...
<code> };
</code></dt>
1153 Temporarily replaces the IPv4 packet being processed by an ARP
1154 packet and executes each nested
<var>action
</var> on the ARP
1155 packet. Actions following the
<var>arp
</var> action, if any, apply
1156 to the original, unmodified packet.
1160 The ARP packet that this action operates on is initialized based on
1161 the IPv4 packet being processed, as follows. These are default
1162 values that the nested actions will probably want to change:
1166 <li><code>eth.src
</code> unchanged
</li>
1167 <li><code>eth.dst
</code> unchanged
</li>
1168 <li><code>eth.type =
0x0806</code></li>
1169 <li><code>arp.op =
1</code> (ARP request)
</li>
1170 <li><code>arp.sha
</code> copied from
<code>eth.src
</code></li>
1171 <li><code>arp.spa
</code> copied from
<code>ip4.src
</code></li>
1172 <li><code>arp.tha =
00:
00:
00:
00:
00:
00</code></li>
1173 <li><code>arp.tpa
</code> copied from
<code>ip4.dst
</code></li>
1177 The ARP packet has the same VLAN header, if any, as the IP packet
1181 <p><b>Prerequisite:
</b> <code>ip4
</code></p>
1184 <dt><code>get_arp(
<var>P
</var>,
<var>A
</var>);
</code></dt>
1188 <b>Parameters
</b>: logical port string field
<var>P
</var>,
32-bit
1189 IP address field
<var>A
</var>.
1193 Looks up
<var>A
</var> in
<var>P
</var>'s mac binding table.
1194 If an entry is found, stores its Ethernet address in
1195 <code>eth.dst
</code>, otherwise stores
1196 <code>00:
00:
00:
00:
00:
00</code> in
<code>eth.dst
</code>.
1199 <p><b>Example:
</b> <code>get_arp(outport, ip4.dst);
</code></p>
1203 <code>put_arp(
<var>P
</var>,
<var>A
</var>,
<var>E
</var>);
</code>
1208 <b>Parameters
</b>: logical port string field
<var>P
</var>,
32-bit
1209 IP address field
<var>A
</var>,
48-bit Ethernet address field
1214 Adds or updates the entry for IP address
<var>A
</var> in
1215 logical port
<var>P
</var>'s mac binding table, setting its
1216 Ethernet address to
<var>E
</var>.
1219 <p><b>Example:
</b> <code>put_arp(inport, arp.spa, arp.sha);
</code></p>
1223 <code>nd_na {
<var>action
</var>;
</code>...
<code> };
</code>
1228 Temporarily replaces the IPv6 neighbor solicitation packet
1229 being processed by an IPv6 neighbor advertisement (NA)
1230 packet and executes each nested
<var>action
</var> on the NA
1231 packet. Actions following the
<code>nd_na
</code> action,
1232 if any, apply to the original, unmodified packet.
1236 The NA packet that this action operates on is initialized based on
1237 the IPv6 packet being processed, as follows. These are default
1238 values that the nested actions will probably want to change:
1242 <li><code>eth.dst
</code> exchanged with
<code>eth.src
</code></li>
1243 <li><code>eth.type =
0x86dd</code></li>
1244 <li><code>ip6.dst
</code> copied from
<code>ip6.src
</code></li>
1245 <li><code>ip6.src
</code> copied from
<code>nd.target
</code></li>
1246 <li><code>icmp6.type =
136</code> (Neighbor Advertisement)
</li>
1247 <li><code>nd.target
</code> unchanged
</li>
1248 <li><code>nd.sll =
00:
00:
00:
00:
00:
00</code></li>
1249 <li><code>nd.tll
</code> copied from
<code>eth.dst
</code></li>
1253 The ND packet has the same VLAN header, if any, as the IPv6 packet
1258 <b>Prerequisite:
</b> <code>nd_ns
</code>
1262 <dt><code>get_nd(
<var>P
</var>,
<var>A
</var>);
</code></dt>
1266 <b>Parameters
</b>: logical port string field
<var>P
</var>,
128-bit
1267 IPv6 address field
<var>A
</var>.
1271 Looks up
<var>A
</var> in
<var>P
</var>'s mac binding table.
1272 If an entry is found, stores its Ethernet address in
1273 <code>eth.dst
</code>, otherwise stores
1274 <code>00:
00:
00:
00:
00:
00</code> in
<code>eth.dst
</code>.
1277 <p><b>Example:
</b> <code>get_nd(outport, ip6.dst);
</code></p>
1281 <code>put_nd(
<var>P
</var>,
<var>A
</var>,
<var>E
</var>);
</code>
1286 <b>Parameters
</b>: logical port string field
<var>P
</var>,
1287 128-bit IPv6 address field
<var>A
</var>,
48-bit Ethernet
1288 address field
<var>E
</var>.
1292 Adds or updates the entry for IPv6 address
<var>A
</var> in
1293 logical port
<var>P
</var>'s mac binding table, setting its
1294 Ethernet address to
<var>E
</var>.
1297 <p><b>Example:
</b> <code>put_nd(inport, nd.target, nd.tll);
</code></p>
1301 <code><var>R
</var> = put_dhcp_opts(
<var>D1
</var> =
<var>V1
</var>,
<var>D2
</var> =
<var>V2
</var>, ...,
<var>Dn
</var> =
<var>Vn
</var>);
</code>
1306 <b>Parameters
</b>: one or more DHCP option/value pairs, which must
1307 include an
<code>offerip
</code> option (with code
0).
1311 <b>Result
</b>: stored to a
1-bit subfield
<var>R
</var>.
1315 Valid only in the ingress pipeline.
1319 When this action is applied to a DHCP request packet (DHCPDISCOVER
1320 or DHCPREQUEST), it changes the packet into a DHCP reply (DHCPOFFER
1321 or DHCPACK, respectively), replaces the options by those specified
1322 as parameters, and stores
1 in
<var>R
</var>.
1326 When this action is applied to a non-DHCP packet or a DHCP packet
1327 that is not DHCPDISCOVER or DHCPREQUEST, it leaves the packet
1328 unchanged and stores
0 in
<var>R
</var>.
1332 The contents of the
<ref table=
"DHCP_Option"/> table control the
1333 DHCP option names and values that this action supports.
1339 reg0[
0] = put_dhcp_opts(offerip =
10.0.0.2, router =
10.0.0.1,
1340 netmask =
255.255.255.0, dns_server = {
8.8.8.8,
7.7.7.7});
1346 <code><var>R
</var> = put_dhcpv6_opts(
<var>D1
</var> =
<var>V1
</var>,
<var>D2
</var> =
<var>V2
</var>, ...,
<var>Dn
</var> =
<var>Vn
</var>);
</code>
1351 <b>Parameters
</b>: one or more DHCPv6 option/value pairs.
1355 <b>Result
</b>: stored to a
1-bit subfield
<var>R
</var>.
1359 Valid only in the ingress pipeline.
1363 When this action is applied to a DHCPv6 request packet, it changes
1364 the packet into a DHCPv6 reply, replaces the options by those
1365 specified as parameters, and stores
1 in
<var>R
</var>.
1369 When this action is applied to a non-DHCPv6 packet or an invalid
1370 DHCPv6 request packet , it leaves the packet unchanged and stores
1375 The contents of the
<ref table=
"DHCPv6_Options"/> table control the
1376 DHCPv6 option names and values that this action supports.
1382 reg0[
3] = put_dhcpv6_opts(ia_addr = aef0::
4, server_id =
00:
00:
00:
00:
10:
02,
1383 dns_server={ae70::
1,ae70::
2});
1389 <code>set_queue(
<var>queue_number
</var>);
</code>
1394 <b>Parameters
</b>: Queue number
<var>queue_number
</var>, in the range
0 to
61440.
1398 This is a logical equivalent of the OpenFlow
<code>set_queue
</code>
1399 action. It affects packets that egress a hypervisor through a
1400 physical interface. For nonzero
<var>queue_number
</var>, it
1401 configures packet queuing to match the settings configured for the
1402 <ref table=
"Port_Binding"/> with
1403 <code>options:qdisc_queue_id
</code> matching
1404 <var>queue_number
</var>. When
<var>queue_number
</var> is zero, it
1405 resets queuing to the default strategy.
1408 <p><b>Example:
</b> <code>set_queue(
10);
</code></p>
1411 <dt><code>ct_lb;
</code></dt>
1412 <dt><code>ct_lb(
</code><var>ip
</var>[
<code>:
</code><var>port
</var>]...
<code>);
</code></dt>
1415 With one or more arguments,
<code>ct_lb
</code> commits the packet
1416 to the connection tracking table and DNATs the packet's destination
1417 IP address (and port) to the IP address or addresses (and optional
1418 ports) specified in the string. If multiple comma-separated IP
1419 addresses are specified, each is given equal weight for picking the
1420 DNAT address. Processing automatically moves on to the next table,
1421 as if
<code>next;
</code> were specified, and later tables act on
1422 the packet as modified by the connection tracker. Connection
1423 tracking state is scoped by the logical port when the action is
1424 used in a flow for a logical switch, so overlapping
1425 addresses may be used. Connection tracking state is scoped by the
1426 logical topology when the action is used in a flow for a router.
1429 Without arguments,
<code>ct_lb
</code> sends the packet to the
1430 connection tracking table to NAT the packets. If the packet is
1431 part of an established connection that was previously committed to
1432 the connection tracker via
<code>ct_lb(
</code>...
<code>)
</code>, it
1433 will automatically get DNATed to the same IP address as the first
1434 packet in that connection.
1440 The following actions will likely be useful later, but they have not
1441 been thought out carefully.
1445 <dt><code>icmp4 {
<var>action
</var>;
</code>...
<code> };
</code></dt>
1448 Temporarily replaces the IPv4 packet being processed by an ICMPv4
1449 packet and executes each nested
<var>action
</var> on the ICMPv4
1450 packet. Actions following the
<var>icmp4
</var> action, if any,
1451 apply to the original, unmodified packet.
1455 The ICMPv4 packet that this action operates on is initialized based
1456 on the IPv4 packet being processed, as follows. These are default
1457 values that the nested actions will probably want to change.
1458 Ethernet and IPv4 fields not listed here are not changed:
1462 <li><code>ip.proto =
1</code> (ICMPv4)
</li>
1463 <li><code>ip.frag =
0</code> (not a fragment)
</li>
1464 <li><code>icmp4.type =
3</code> (destination unreachable)
</li>
1465 <li><code>icmp4.code =
1</code> (host unreachable)
</li>
1472 <p><b>Prerequisite:
</b> <code>ip4
</code></p>
1475 <dt><code>tcp_reset;
</code></dt>
1478 This action transforms the current TCP packet according to the
1479 following pseudocode:
1486 tcp.ack = tcp.seq + length(tcp.payload);
1493 Then, the action drops all TCP options and payload data, and
1494 updates the TCP checksum.
1501 <p><b>Prerequisite:
</b> <code>tcp
</code></p>
1506 <column name=
"external_ids" key=
"stage-name">
1507 Human-readable name for this flow's stage in the pipeline.
1510 <column name=
"external_ids" key=
"source">
1511 Source file and line number of the code that added this flow to the
1515 <group title=
"Common Columns">
1516 The overall purpose of these columns is described under
<code>Common
1517 Columns
</code> at the beginning of this document.
1519 <column name=
"external_ids"/>
1523 <table name=
"Multicast_Group" title=
"Logical Port Multicast Groups">
1525 The rows in this table define multicast groups of logical ports.
1526 Multicast groups allow a single packet transmitted over a tunnel to a
1527 hypervisor to be delivered to multiple VMs on that hypervisor, which
1528 uses bandwidth more efficiently.
1532 Each row in this table defines a logical multicast group numbered
<ref
1533 column=
"tunnel_key"/> within
<ref column=
"datapath"/>, whose logical
1534 ports are listed in the
<ref column=
"ports"/> column.
1537 <column name=
"datapath">
1538 The logical datapath in which the multicast group resides.
1541 <column name=
"tunnel_key">
1542 The value used to designate this logical egress port in tunnel
1543 encapsulations. An index forces the key to be unique within the
<ref
1544 column=
"datapath"/>. The unusual range ensures that multicast group IDs
1545 do not overlap with logical port IDs.
1548 <column name=
"name">
1550 The logical multicast group's name. An index forces the name to be
1551 unique within the
<ref column=
"datapath"/>. Logical flows in the
1552 ingress pipeline may output to the group just as for individual logical
1553 ports, by assigning the group's name to
<code>outport
</code> and
1554 executing an
<code>output
</code> action.
1558 Multicast group names and logical port names share a single namespace
1559 and thus should not overlap (but the database schema cannot enforce
1560 this). To try to avoid conflicts,
<code>ovn-northd
</code> uses names
1561 that begin with
<code>_MC_
</code>.
1565 <column name=
"ports">
1566 The logical ports included in the multicast group. All of these ports
1567 must be in the
<ref column=
"datapath"/> logical datapath (but the
1568 database schema cannot enforce this).
1572 <table name=
"Datapath_Binding" title=
"Physical-Logical Datapath Bindings">
1574 Each row in this table identifies physical bindings of a logical
1575 datapath. A logical datapath implements a logical pipeline among the
1576 ports in the
<ref table=
"Port_Binding"/> table associated with it. In
1577 practice, the pipeline in a given logical datapath implements either a
1578 logical switch or a logical router.
1581 <column name=
"tunnel_key">
1582 The tunnel key value to which the logical datapath is bound.
1583 The
<code>Tunnel Encapsulation
</code> section in
1584 <code>ovn-architecture
</code>(
7) describes how tunnel keys are
1585 constructed for each supported encapsulation.
1588 <group title=
"OVN_Northbound Relationship">
1590 Each row in
<ref table=
"Datapath_Binding"/> is associated with some
1591 logical datapath.
<code>ovn-northd
</code> uses these keys to track the
1592 association of a logical datapath with concepts in the
<ref
1593 db=
"OVN_Northbound"/> database.
1596 <column name=
"external_ids" key=
"logical-switch" type='{
"type":
"uuid"}'
>
1597 For a logical datapath that represents a logical switch,
1598 <code>ovn-northd
</code> stores in this key the UUID of the
1599 corresponding
<ref table=
"Logical_Switch" db=
"OVN_Northbound"/> row in
1600 the
<ref db=
"OVN_Northbound"/> database.
1603 <column name=
"external_ids" key=
"logical-router" type='{
"type":
"uuid"}'
>
1604 For a logical datapath that represents a logical router,
1605 <code>ovn-northd
</code> stores in this key the UUID of the
1606 corresponding
<ref table=
"Logical_Router" db=
"OVN_Northbound"/> row in
1607 the
<ref db=
"OVN_Northbound"/> database.
1610 <column name=
"external_ids" key=
"name">
1611 <code>ovn-northd
</code> copies this from the
<ref
1612 table=
"Logical_Router" db=
"OVN_Northbound"/> or
<ref
1613 table=
"Logical_Switch" db=
"OVN_Northbound"/> table in the
<ref
1614 db=
"OVN_Northbound"/> database, when that column is nonempty.
1618 <group title=
"Common Columns">
1619 The overall purpose of these columns is described under
<code>Common
1620 Columns
</code> at the beginning of this document.
1622 <column name=
"external_ids"/>
1626 <table name=
"Port_Binding" title=
"Physical-Logical Port Bindings">
1628 Most rows in this table identify the physical location of a logical port.
1629 (The exceptions are logical patch ports, which do not have any physical
1634 For every
<code>Logical_Switch_Port
</code> record in
1635 <code>OVN_Northbound
</code> database,
<code>ovn-northd
</code>
1636 creates a record in this table.
<code>ovn-northd
</code> populates
1637 and maintains every column except the
<code>chassis
</code> column,
1638 which it leaves empty in new records.
1642 <code>ovn-controller
</code>/
<code>ovn-controller-vtep
</code>
1643 populates the
<code>chassis
</code> column for the records that
1644 identify the logical ports that are located on its hypervisor/gateway,
1645 which
<code>ovn-controller
</code>/
<code>ovn-controller-vtep
</code> in
1646 turn finds out by monitoring the local hypervisor's Open_vSwitch
1647 database, which identifies logical ports via the conventions described
1648 in
<code>IntegrationGuide.rst
</code>. (The exceptions are for
1649 <code>Port_Binding
</code> records with
<code>type
</code> of
1650 <code>l3gateway
</code>, whose locations are identified by
1651 <code>ovn-northd
</code> via the
<code>options:l3gateway-chassis
</code>
1652 column in this table.
<code>ovn-controller
</code> is still responsible
1653 to populate the
<code>chassis
</code> column.)
1657 When a chassis shuts down gracefully, it should clean up the
1658 <code>chassis
</code> column that it previously had populated.
1659 (This is not critical because resources hosted on the chassis are equally
1660 unreachable regardless of whether their rows are present.) To handle the
1661 case where a VM is shut down abruptly on one chassis, then brought up
1662 again on a different one,
1663 <code>ovn-controller
</code>/
<code>ovn-controller-vtep
</code> must
1664 overwrite the
<code>chassis
</code> column with new information.
1667 <group title=
"Core Features">
1668 <column name=
"datapath">
1669 The logical datapath to which the logical port belongs.
1672 <column name=
"logical_port">
1673 A logical port, taken from
<ref table=
"Logical_Switch_Port"
1674 column=
"name" db=
"OVN_Northbound"/> in the OVN_Northbound
1675 database's
<ref table=
"Logical_Switch_Port" db=
"OVN_Northbound"/>
1676 table. OVN does not prescribe a particular format for the
1680 <column name=
"chassis">
1681 The meaning of this column depends on the value of the
<ref column=
"type"/>
1682 column. This is the meaning for each
<ref column=
"type"/>
1685 <dt>(empty string)
</dt>
1687 The physical location of the logical port. To successfully identify a
1688 chassis, this column must be a
<ref table=
"Chassis"/> record. This is
1689 populated by
<code>ovn-controller
</code>.
1694 The physical location of the hardware_vtep gateway. To successfully
1695 identify a chassis, this column must be a
<ref table=
"Chassis"/> record.
1696 This is populated by
<code>ovn-controller-vtep
</code>.
1701 Always empty. A localnet port is realized on every chassis that has
1702 connectivity to the corresponding physical network.
1707 The physical location of the L3 gateway. To successfully identify a
1708 chassis, this column must be a
<ref table=
"Chassis"/> record. This is
1709 populated by
<code>ovn-controller
</code> based on the value of
1710 the
<code>options:l3gateway-chassis
</code> column in this table.
1715 The physical location of this L2 gateway. To successfully identify a
1716 chassis, this column must be a
<ref table=
"Chassis"/> record.
1717 This is populated by
<code>ovn-controller
</code> based on the value
1718 of the
<code>options:l2gateway-chassis
</code> column in this table.
1724 <column name=
"tunnel_key">
1726 A number that represents the logical port in the key (e.g. STT key or
1727 Geneve TLV) field carried within tunnel protocol packets.
1731 The tunnel ID must be unique within the scope of a logical datapath.
1737 The Ethernet address or addresses used as a source address on the
1738 logical port, each in the form
1739 <var>xx
</var>:
<var>xx
</var>:
<var>xx
</var>:
<var>xx
</var>:
<var>xx
</var>:
<var>xx
</var>.
1740 The string
<code>unknown
</code> is also allowed to indicate that the
1741 logical port has an unknown set of (additional) source addresses.
1745 A VM interface would ordinarily have a single Ethernet address. A
1746 gateway port might initially only have
<code>unknown
</code>, and then
1747 add MAC addresses to the set as it learns new source addresses.
1751 <column name=
"type">
1753 A type for this logical port. Logical ports can be used to model other
1754 types of connectivity into an OVN logical switch. The following types
1759 <dt>(empty string)
</dt>
1760 <dd>VM (or VIF) interface.
</dd>
1762 <dt><code>patch
</code></dt>
1764 One of a pair of logical ports that act as if connected by a patch
1765 cable. Useful for connecting two logical datapaths, e.g. to connect
1766 a logical router to a logical switch or to another logical router.
1769 <dt><code>l3gateway
</code></dt>
1771 One of a pair of logical ports that act as if connected by a patch
1772 cable across multiple chassis. Useful for connecting a logical
1773 switch with a Gateway router (which is only resident on a
1774 particular chassis).
1777 <dt><code>localnet
</code></dt>
1779 A connection to a locally accessible network from each
1780 <code>ovn-controller
</code> instance. A logical switch can only
1781 have a single
<code>localnet
</code> port attached. This is used
1782 to model direct connectivity to an existing network.
1785 <dt><code>l2gateway
</code></dt>
1787 An L2 connection to a physical network. The chassis this
1788 <ref table=
"Port_Binding"/> is bound to will serve as
1789 an L2 gateway to the network named by
1790 <ref column=
"options" table=
"Port_Binding"/>:
<code>network_name
</code>.
1793 <dt><code>vtep
</code></dt>
1795 A port to a logical switch on a VTEP gateway chassis. In order to
1796 get this port correctly recognized by the OVN controller, the
<ref
1798 table=
"Port_Binding"/>:
<code>vtep-physical-switch
</code> and
<ref
1800 table=
"Port_Binding"/>:
<code>vtep-logical-switch
</code> must also
1804 <dt><code>chassisredirect
</code></dt>
1806 A logical port that represents a particular instance, bound
1807 to a specific chassis, of an otherwise distributed parent
1808 port (e.g. of type
<code>patch
</code>). A
1809 <code>chassisredirect
</code> port should never be used as an
1810 <code>inport
</code>. When an ingress pipeline sets the
1811 <code>outport
</code>, it may set the value to a logical port
1812 of type
<code>chassisredirect
</code>. This will cause the
1813 packet to be directed to a specific chassis to carry out the
1814 egress pipeline. At the beginning of the egress pipeline,
1815 the
<code>outport
</code> will be reset to the value of the
1822 <group title=
"Patch Options">
1824 These options apply to logical ports with
<ref column=
"type"/> of
1828 <column name=
"options" key=
"peer">
1829 The
<ref column=
"logical_port"/> in the
<ref table=
"Port_Binding"/>
1830 record for the other side of the patch. The named
<ref
1831 column=
"logical_port"/> must specify this
<ref column=
"logical_port"/>
1832 in its own
<code>peer
</code> option. That is, the two patch logical
1833 ports must have reversed
<ref column=
"logical_port"/> and
1834 <code>peer
</code> values.
1838 <group title=
"L3 Gateway Options">
1840 These options apply to logical ports with
<ref column=
"type"/> of
1841 <code>l3gateway
</code>.
1844 <column name=
"options" key=
"peer">
1845 The
<ref column=
"logical_port"/> in the
<ref table=
"Port_Binding"/>
1846 record for the other side of the 'l3gateway' port. The named
<ref
1847 column=
"logical_port"/> must specify this
<ref column=
"logical_port"/>
1848 in its own
<code>peer
</code> option. That is, the two 'l3gateway'
1849 logical ports must have reversed
<ref column=
"logical_port"/> and
1850 <code>peer
</code> values.
1853 <column name=
"options" key=
"l3gateway-chassis">
1854 The
<code>chassis
</code> in which the port resides.
1857 <column name=
"options" key=
"nat-addresses">
1858 MAC address of the
<code>l3gateway
</code> port followed by a list of
1859 SNAT and DNAT IP addresses. This is used to send gratuitous ARPs for
1860 SNAT and DNAT IP addresses via
<code>localnet
</code> and is valid for
1861 only L3 gateway ports. Example:
<code>80:fa:
5b:
06:
72:b7
158.36.44.22
1862 158.36.44.24</code>. This would result in generation of gratuitous
1863 ARPs for IP addresses
158.36.44.22 and
158.36.44.24 with a MAC
1864 address of
80:fa:
5b:
06:
72:b7.
1868 <group title=
"Localnet Options">
1870 These options apply to logical ports with
<ref column=
"type"/> of
1871 <code>localnet
</code>.
1874 <column name=
"options" key=
"network_name">
1875 Required.
<code>ovn-controller
</code> uses the configuration entry
1876 <code>ovn-bridge-mappings
</code> to determine how to connect to this
1877 network.
<code>ovn-bridge-mappings
</code> is a list of network names
1878 mapped to a local OVS bridge that provides access to that network. An
1879 example of configuring
<code>ovn-bridge-mappings
</code> would be:
1881 <pre>$ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
</pre>
1884 When a logical switch has a
<code>localnet
</code> port attached,
1885 every chassis that may have a local vif attached to that logical
1886 switch must have a bridge mapping configured to reach that
1887 <code>localnet
</code>. Traffic that arrives on a
1888 <code>localnet
</code> port is never forwarded over a tunnel to
1894 If set, indicates that the port represents a connection to a specific
1895 VLAN on a locally accessible network. The VLAN ID is used to match
1896 incoming traffic and is also added to outgoing traffic.
1900 <group title=
"L2 Gateway Options">
1902 These options apply to logical ports with
<ref column=
"type"/> of
1903 <code>l2gateway
</code>.
1906 <column name=
"options" key=
"network_name">
1907 Required.
<code>ovn-controller
</code> uses the configuration entry
1908 <code>ovn-bridge-mappings
</code> to determine how to connect to this
1909 network.
<code>ovn-bridge-mappings
</code> is a list of network names
1910 mapped to a local OVS bridge that provides access to that network. An
1911 example of configuring
<code>ovn-bridge-mappings
</code> would be:
1913 <pre>$ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
</pre>
1916 When a logical switch has a
<code>l2gateway
</code> port attached,
1917 the chassis that the
<code>l2gateway
</code> port is bound to
1918 must have a bridge mapping configured to reach the network
1919 identified by
<code>network_name
</code>.
1923 <column name=
"options" key=
"l2gateway-chassis">
1924 Required. The
<code>chassis
</code> in which the port resides.
1928 If set, indicates that the gateway is connected to a specific
1929 VLAN on the physical network. The VLAN ID is used to match
1930 incoming traffic and is also added to outgoing traffic.
1934 <group title=
"VTEP Options">
1936 These options apply to logical ports with
<ref column=
"type"/> of
1940 <column name=
"options" key=
"vtep-physical-switch">
1941 Required. The name of the VTEP gateway.
1944 <column name=
"options" key=
"vtep-logical-switch">
1945 Required. A logical switch name connected by the VTEP gateway. Must
1946 be set when
<ref column=
"type"/> is
<code>vtep
</code>.
1950 <group title=
"VMI (or VIF) Options">
1952 These options apply to logical ports with
<ref column=
"type"/> having
1956 <column name=
"options" key=
"qos_max_rate">
1957 If set, indicates the maximum rate for data sent from this interface,
1958 in bit/s. The traffic will be shaped according to this limit.
1961 <column name=
"options" key=
"qos_burst">
1962 If set, indicates the maximum burst size for data sent from this
1966 <column name=
"options" key=
"qdisc_queue_id"
1967 type='{
"type":
"integer",
"minInteger":
1,
"maxInteger":
61440}'
>
1968 Indicates the queue number on the physical device. This is same as the
1969 <code>queue_id
</code> used in OpenFlow in
<code>struct
1970 ofp_action_enqueue
</code>.
1974 <group title=
"Chassis Redirect Options">
1976 These options apply to logical ports with
<ref column=
"type"/>
1977 of
<code>chassisredirect
</code>.
1980 <column name=
"options" key=
"distributed-port">
1981 The name of the distributed port for which this
1982 <code>chassisredirect
</code> port represents a particular instance.
1985 <column name=
"options" key=
"redirect-chassis">
1986 The
<code>chassis
</code> that this
<code>chassisredirect
</code> port
1987 is bound to. This is taken from
<ref table=
"Logical_Router_Port"
1988 column=
"options" key=
"redirect-chassis" db=
"OVN_Northbound"/>
1989 in the OVN_Northbound database's
<ref table=
"Logical_Router_Port"
1990 db=
"OVN_Northbound"/> table.
1994 <group title=
"Nested Containers">
1996 These columns support containers nested within a VM. Specifically,
1997 they are used when
<ref column=
"type"/> is empty and
<ref
1998 column=
"logical_port"/> identifies the interface of a container spawned
1999 inside a VM. They are empty for containers or VMs that run directly on
2003 <column name=
"parent_port">
2005 <ref table=
"Logical_Switch_Port" column=
"parent_name"
2006 db=
"OVN_Northbound"/> in the OVN_Northbound database's
2007 <ref table=
"Logical_Switch_Port" db=
"OVN_Northbound"/> table.
2012 Identifies the VLAN tag in the network traffic associated with that
2013 container's network interface.
2017 This column is used for a different purpose when
<ref column=
"type"/>
2018 is
<code>localnet
</code> (see
<code>Localnet Options
</code>, above)
2019 or
<code>l2gateway
</code> (see
<code>L2 Gateway Options
</code>, above).
2025 <table name=
"MAC_Binding" title=
"IP to MAC bindings">
2027 Each row in this table specifies a binding from an IP address to an
2028 Ethernet address that has been discovered through ARP (for IPv4) or
2029 neighbor discovery (for IPv6). This table is primarily used to discover
2030 bindings on physical networks, because IP-to-MAC bindings for virtual
2031 machines are usually populated statically into the
<ref
2032 table=
"Port_Binding"/> table.
2036 This table expresses a functional relationship:
<ref
2037 table=
"MAC_Binding"/>(
<ref column=
"logical_port"/>,
<ref column=
"ip"/>) =
2038 <ref column=
"mac"/>.
2042 In outline, the lifetime of a logical router's MAC binding looks like
2048 On hypervisor
1, a logical router determines that a packet should be
2049 forwarded to IP address
<var>A
</var> on one of its router ports. It
2050 uses its logical flow table to determine that
<var>A
</var> lacks a
2051 static IP-to-MAC binding and the
<code>get_arp
</code> action to
2052 determine that it lacks a dynamic IP-to-MAC binding.
2056 Using an OVN logical
<code>arp
</code> action, the logical router
2057 generates and sends a broadcast ARP request to the router port. It
2058 drops the IP packet.
2062 The logical switch attached to the router port delivers the ARP request
2063 to all of its ports. (It might make sense to deliver it only to ports
2064 that have no static IP-to-MAC bindings, but this could also be
2065 surprising behavior.)
2069 A host or VM on hypervisor
2 (which might be the same as hypervisor
1)
2070 attached to the logical switch owns the IP address in question. It
2071 composes an ARP reply and unicasts it to the logical router port's
2076 The logical switch delivers the ARP reply to the logical router port.
2080 The logical router flow table executes a
<code>put_arp
</code> action.
2081 To record the IP-to-MAC binding,
<code>ovn-controller
</code> adds a row
2082 to the
<ref table=
"MAC_Binding"/> table.
2086 On hypervisor
1,
<code>ovn-controller
</code> receives the updated
<ref
2087 table=
"MAC_Binding"/> table from the OVN southbound database. The next
2088 packet destined to
<var>A
</var> through the logical router is sent
2089 directly to the bound Ethernet address.
2093 <column name=
"logical_port">
2094 The logical port on which the binding was discovered.
2098 The bound IP address.
2102 The Ethernet address to which the IP is bound.
2104 <column name=
"datapath">
2105 The logical datapath to which the logical port belongs.
2109 <table name=
"DHCP_Options" title=
"DHCP Options supported by native OVN DHCP">
2111 Each row in this table stores the DHCP Options supported by native OVN
2112 DHCP.
<code>ovn-northd
</code> populates this table with the supported
2113 DHCP options.
<code>ovn-controller
</code> looks up this table to get the
2114 DHCP codes of the DHCP options defined in the
"put_dhcp_opts" action.
2115 Please refer to the RFC
2132 <code>"https://tools.ietf.org/html/rfc2132"</code>
2116 for the possible list of DHCP options that can be defined here.
2119 <column name=
"name">
2121 Name of the DHCP option.
2125 Example.
name=
"router"
2129 <column name=
"code">
2131 DHCP option code for the DHCP option as defined in the RFC
2132.
2139 <column name=
"type">
2141 Data type of the DHCP option code.
2145 <dt><code>value: bool
</code></dt>
2148 This indicates that the value of the DHCP option is a bool.
2152 Example.
"name=ip_forward_enable",
"code=19",
"type=bool".
2156 put_dhcp_opts(..., ip_forward_enable =
1,...)
2160 <dt><code>value: uint8
</code></dt>
2163 This indicates that the value of the DHCP option is an unsigned
2168 Example.
"name=default_ttl",
"code=23",
"type=uint8".
2172 put_dhcp_opts(..., default_ttl =
50,...)
2176 <dt><code>value: uint16
</code></dt>
2179 This indicates that the value of the DHCP option is an unsigned
2184 Example.
"name=mtu",
"code=26",
"type=uint16".
2188 put_dhcp_opts(..., mtu =
1450,...)
2192 <dt><code>value: uint32
</code></dt>
2195 This indicates that the value of the DHCP option is an unsigned
2200 Example.
"name=lease_time",
"code=51",
"type=uint32".
2204 put_dhcp_opts(..., lease_time =
86400,...)
2208 <dt><code>value: ipv4
</code></dt>
2211 This indicates that the value of the DHCP option is an IPv4
2212 address or addresses.
2216 Example.
"name=router",
"code=3",
"type=ipv4".
2220 put_dhcp_opts(..., router =
10.0.0.1,...)
2224 Example.
"name=dns_server",
"code=6",
"type=ipv4".
2228 put_dhcp_opts(..., dns_server = {
8.8.8.8 7.7.7.7},...)
2232 <dt><code>value: static_routes
</code></dt>
2235 This indicates that the value of the DHCP option contains a pair of
2236 IPv4 route and next hop addresses.
2240 Example.
"name=classless_static_route",
"code=121",
"type=static_routes".
2244 put_dhcp_opts(..., classless_static_route = {
30.0.0.0/
24,
10.0.0.4,
0.0.0.0/
0,
10.0.0.1}...)
2248 <dt><code>value: str
</code></dt>
2251 This indicates that the value of the DHCP option is a string.
2255 Example.
"name=host_name",
"code=12",
"type=str".
2262 <table name=
"DHCPv6_Options" title=
"DHCPv6 Options supported by native OVN DHCPv6">
2264 Each row in this table stores the DHCPv6 Options supported by native OVN
2265 DHCPv6.
<code>ovn-northd
</code> populates this table with the supported
2266 DHCPv6 options.
<code>ovn-controller
</code> looks up this table to get
2267 the DHCPv6 codes of the DHCPv6 options defined in the
2268 <code>put_dhcpv6_opts
</code> action. Please refer to RFC
3315 and RFC
2269 3646 for the list of DHCPv6 options that can be defined here.
2272 <column name=
"name">
2274 Name of the DHCPv6 option.
2278 Example.
name=
"ia_addr"
2282 <column name=
"code">
2284 DHCPv6 option code for the DHCPv6 option as defined in the appropriate
2293 <column name=
"type">
2295 Data type of the DHCPv6 option code.
2299 <dt><code>value: ipv6
</code></dt>
2302 This indicates that the value of the DHCPv6 option is an IPv6
2307 Example.
"name=ia_addr",
"code=5",
"type=ipv6".
2311 put_dhcpv6_opts(..., ia_addr = ae70::
4,...)
2315 <dt><code>value: str
</code></dt>
2318 This indicates that the value of the DHCPv6 option is a string.
2322 Example.
"name=domain_search",
"code=24",
"type=str".
2326 put_dhcpv6_opts(..., domain_search = ovn.domain,...)
2330 <dt><code>value: mac
</code></dt>
2333 This indicates that the value of the DHCPv6 option is a MAC address.
2337 Example.
"name=server_id",
"code=2",
"type=mac".
2341 put_dhcpv6_opts(..., server_id =
01:
02:
03:
04L05:
06,...)
2347 <table name=
"Connection" title=
"OVSDB client connections.">
2349 Configuration for a database connection to an Open vSwitch database
2354 This table primarily configures the Open vSwitch database server
2355 (
<code>ovsdb-server
</code>).
2359 The Open vSwitch database server can initiate and maintain active
2360 connections to remote clients. It can also listen for database
2364 <group title=
"Core Features">
2365 <column name=
"target">
2366 <p>Connection methods for clients.
</p>
2368 The following connection methods are currently supported:
2371 <dt><code>ssl:
<var>ip
</var></code>[
<code>:
<var>port
</var></code>]
</dt>
2374 The specified SSL
<var>port
</var> on the host at the given
2375 <var>ip
</var>, which must be expressed as an IP address
2376 (not a DNS name). A valid SSL configuration must be provided
2377 when this form is used, this configuration can be specified
2378 via command-line options or the
<ref table=
"SSL"/> table.
2381 If
<var>port
</var> is not specified, it defaults to
6640.
2384 SSL support is an optional feature that is not always
2385 built as part of Open vSwitch.
2389 <dt><code>tcp:
<var>ip
</var></code>[
<code>:
<var>port
</var></code>]
</dt>
2392 The specified TCP
<var>port
</var> on the host at the given
2393 <var>ip
</var>, which must be expressed as an IP address (not a
2394 DNS name), where
<var>ip
</var> can be IPv4 or IPv6 address. If
2395 <var>ip
</var> is an IPv6 address, wrap it in square brackets,
2396 e.g.
<code>tcp:[::
1]:
6640</code>.
2399 If
<var>port
</var> is not specified, it defaults to
6640.
2402 <dt><code>pssl:
</code>[
<var>port
</var>][
<code>:
<var>ip
</var></code>]
</dt>
2405 Listens for SSL connections on the specified TCP
<var>port
</var>.
2406 Specify
0 for
<var>port
</var> to have the kernel automatically
2407 choose an available port. If
<var>ip
</var>, which must be
2408 expressed as an IP address (not a DNS name), is specified, then
2409 connections are restricted to the specified local IP address
2410 (either IPv4 or IPv6 address). If
<var>ip
</var> is an IPv6
2411 address, wrap in square brackets,
2412 e.g.
<code>pssl:
6640:[::
1]
</code>. If
<var>ip
</var> is not
2413 specified then it listens only on IPv4 (but not IPv6) addresses.
2414 A valid SSL configuration must be provided when this form is used,
2415 this can be specified either via command-line options or the
2416 <ref table=
"SSL"/> table.
2419 If
<var>port
</var> is not specified, it defaults to
6640.
2422 SSL support is an optional feature that is not always built as
2423 part of Open vSwitch.
2426 <dt><code>ptcp:
</code>[
<var>port
</var>][
<code>:
<var>ip
</var></code>]
</dt>
2429 Listens for connections on the specified TCP
<var>port
</var>.
2430 Specify
0 for
<var>port
</var> to have the kernel automatically
2431 choose an available port. If
<var>ip
</var>, which must be
2432 expressed as an IP address (not a DNS name), is specified, then
2433 connections are restricted to the specified local IP address
2434 (either IPv4 or IPv6 address). If
<var>ip
</var> is an IPv6
2435 address, wrap it in square brackets,
2436 e.g.
<code>ptcp:
6640:[::
1]
</code>. If
<var>ip
</var> is not
2437 specified then it listens only on IPv4 addresses.
2440 If
<var>port
</var> is not specified, it defaults to
6640.
2444 <p>When multiple clients are configured, the
<ref column=
"target"/>
2445 values must be unique. Duplicate
<ref column=
"target"/> values yield
2446 unspecified results.
</p>
2449 <column name=
"read_only">
2450 <code>true
</code> to restrict these connections to read-only
2451 transactions,
<code>false
</code> to allow them to modify the database.
2455 <group title=
"Client Failure Detection and Handling">
2456 <column name=
"max_backoff">
2457 Maximum number of milliseconds to wait between connection attempts.
2458 Default is implementation-specific.
2461 <column name=
"inactivity_probe">
2462 Maximum number of milliseconds of idle time on connection to the client
2463 before sending an inactivity probe message. If Open vSwitch does not
2464 communicate with the client for the specified number of seconds, it
2465 will send a probe. If a response is not received for the same
2466 additional amount of time, Open vSwitch assumes the connection has been
2467 broken and attempts to reconnect. Default is implementation-specific.
2468 A value of
0 disables inactivity probes.
2472 <group title=
"Status">
2474 Key-value pair of
<ref column=
"is_connected"/> is always updated.
2475 Other key-value pairs in the status columns may be updated depends
2476 on the
<ref column=
"target"/> type.
2480 When
<ref column=
"target"/> specifies a connection method that
2481 listens for inbound connections (e.g.
<code>ptcp:
</code> or
2482 <code>punix:
</code>), both
<ref column=
"n_connections"/> and
2483 <ref column=
"is_connected"/> may also be updated while the
2484 remaining key-value pairs are omitted.
2488 On the other hand, when
<ref column=
"target"/> specifies an
2489 outbound connection, all key-value pairs may be updated, except
2490 the above-mentioned two key-value pairs associated with inbound
2491 connection targets. They are omitted.
2494 <column name=
"is_connected">
2495 <code>true
</code> if currently connected to this client,
2496 <code>false
</code> otherwise.
2499 <column name=
"status" key=
"last_error">
2500 A human-readable description of the last error on the connection
2501 to the manager; i.e.
<code>strerror(errno)
</code>. This key
2502 will exist only if an error has occurred.
2505 <column name=
"status" key=
"state"
2506 type='{
"type":
"string",
"enum": [
"set", [
"VOID",
"BACKOFF",
"CONNECTING",
"ACTIVE",
"IDLE"]]}'
>
2508 The state of the connection to the manager:
2511 <dt><code>VOID
</code></dt>
2512 <dd>Connection is disabled.
</dd>
2514 <dt><code>BACKOFF
</code></dt>
2515 <dd>Attempting to reconnect at an increasing period.
</dd>
2517 <dt><code>CONNECTING
</code></dt>
2518 <dd>Attempting to connect.
</dd>
2520 <dt><code>ACTIVE
</code></dt>
2521 <dd>Connected, remote host responsive.
</dd>
2523 <dt><code>IDLE
</code></dt>
2524 <dd>Connection is idle. Waiting for response to keep-alive.
</dd>
2527 These values may change in the future. They are provided only for
2532 <column name=
"status" key=
"sec_since_connect"
2533 type='{
"type":
"integer",
"minInteger":
0}'
>
2534 The amount of time since this client last successfully connected
2535 to the database (in seconds). Value is empty if client has never
2536 successfully been connected.
2539 <column name=
"status" key=
"sec_since_disconnect"
2540 type='{
"type":
"integer",
"minInteger":
0}'
>
2541 The amount of time since this client last disconnected from the
2542 database (in seconds). Value is empty if client has never
2546 <column name=
"status" key=
"locks_held">
2547 Space-separated list of the names of OVSDB locks that the connection
2548 holds. Omitted if the connection does not hold any locks.
2551 <column name=
"status" key=
"locks_waiting">
2552 Space-separated list of the names of OVSDB locks that the connection is
2553 currently waiting to acquire. Omitted if the connection is not waiting
2557 <column name=
"status" key=
"locks_lost">
2558 Space-separated list of the names of OVSDB locks that the connection
2559 has had stolen by another OVSDB client. Omitted if no locks have been
2560 stolen from this connection.
2563 <column name=
"status" key=
"n_connections"
2564 type='{
"type":
"integer",
"minInteger":
2}'
>
2565 When
<ref column=
"target"/> specifies a connection method that
2566 listens for inbound connections (e.g.
<code>ptcp:
</code> or
2567 <code>pssl:
</code>) and more than one connection is actually active,
2568 the value is the number of active connections. Otherwise, this
2569 key-value pair is omitted.
2572 <column name=
"status" key=
"bound_port" type='{
"type":
"integer"}'
>
2573 When
<ref column=
"target"/> is
<code>ptcp:
</code> or
2574 <code>pssl:
</code>, this is the TCP port on which the OVSDB server is
2575 listening. (This is particularly useful when
<ref
2576 column=
"target"/> specifies a port of
0, allowing the kernel to
2577 choose any available port.)
2581 <group title=
"Common Columns">
2582 The overall purpose of these columns is described under
<code>Common
2583 Columns
</code> at the beginning of this document.
2585 <column name=
"external_ids"/>
2586 <column name=
"other_config"/>
2590 SSL configuration for ovn-sb database access.
2592 <column name=
"private_key">
2593 Name of a PEM file containing the private key used as the switch's
2594 identity for SSL connections to the controller.
2597 <column name=
"certificate">
2598 Name of a PEM file containing a certificate, signed by the
2599 certificate authority (CA) used by the controller and manager,
2600 that certifies the switch's private key, identifying a trustworthy
2604 <column name=
"ca_cert">
2605 Name of a PEM file containing the CA certificate used to verify
2606 that the switch is connected to a trustworthy controller.
2609 <column name=
"bootstrap_ca_cert">
2610 If set to
<code>true
</code>, then Open vSwitch will attempt to
2611 obtain the CA certificate from the controller on its first SSL
2612 connection and save it to the named PEM file. If it is successful,
2613 it will immediately drop the connection and reconnect, and from then
2614 on all SSL connections must be authenticated by a certificate signed
2615 by the CA certificate thus obtained.
<em>This option exposes the
2616 SSL connection to a man-in-the-middle attack obtaining the initial
2617 CA certificate.
</em> It may still be useful for bootstrapping.
2620 <group title=
"Common Columns">
2621 The overall purpose of these columns is described under
<code>Common
2622 Columns
</code> at the beginning of this document.
2624 <column name=
"external_ids"/>