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>, and northbound to the Cloud Management
14 System, via <code>ovn-northd</code>:
17 <h2>Database Structure</h2>
20 The OVN Southbound database contains three 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"/> and <ref table="Gateway"/> tables comprise the
42 <h3>Logical Network (LN) data</h3>
45 LN tables contain the topology of logical switches and routers, ACLs,
46 firewall rules, and everything needed to describe how packets traverse a
47 logical network, represented as logical datapath flows (see Logical
48 Datapath Flows, below).
52 LN data may be large (O(n) in the number of logical ports, ACL rules,
53 etc.). Thus, to improve scaling, each chassis should receive only data
54 related to logical networks in which that chassis participates. Past
55 experience shows that in the presence of large logical networks, even
56 finer-grained partitioning of data, e.g. designing logical flows so that
57 only the chassis hosting a logical port needs related flows, pays off
58 scale-wise. (This is not necessary initially but it is worth bearing in
63 The LN is a slave of the cloud management system running northbound of OVN.
64 That CMS determines the entire OVN logical configuration and therefore the
65 LN's content at any given time is a deterministic function of the CMS's
66 configuration, although that happens indirectly via the OVN Northbound DB
67 and <code>ovn-northd</code>.
71 LN data is likely to change more quickly than PN data. This is especially
72 true in a container environment where VMs are created and destroyed (and
73 therefore added to and deleted from logical switches) quickly.
77 <ref table="Logical_Flow"/> and <ref table="Multicast_Group"/> contain LN
81 <h3>Bindings data</h3>
84 Bindings data link logical and physical components. They show the current
85 placement of logical components (such as VMs and VIFs) onto chassis, and
86 map logical entities to the values that represent them in tunnel
91 Bindings change frequently, at least every time a VM powers up or down
92 or migrates, and especially quickly in a container environment. The
93 amount of data per VM (or VIF) is small.
97 Each chassis is authoritative about the VMs and VIFs that it hosts at any
98 given time and can efficiently flood that state to a central location, so
99 the consistency needs are minimal.
103 The <ref table="Port_Binding"/> and <ref table="Datapath_Binding"/> tables
104 contain binding data.
107 <h2>Common Columns</h2>
110 Some tables contain a special column named <code>external_ids</code>. This
111 column has the same form and purpose each place that it appears, so we
112 describe it here to save space later.
116 <dt><code>external_ids</code>: map of string-string pairs</dt>
118 Key-value pairs for use by the software that manages the OVN Southbound
119 database rather than by <code>ovn-controller</code>. In particular,
120 <code>ovn-northd</code> can use key-value pairs in this column to relate
121 entities in the southbound database to higher-level entities (such as
122 entities in the OVN Northbound database). Individual key-value pairs in
123 this column may be documented in some cases to aid in understanding and
124 troubleshooting, but the reader should not mistake such documentation as
129 <table name="Chassis" title="Physical Network Hypervisor and Gateway Information">
131 Each row in this table represents a hypervisor or gateway (a chassis) in
132 the physical network (PN). Each chassis, via
133 <code>ovn-controller</code>, adds and updates its own row, and keeps a
134 copy of the remaining rows to determine how to reach other hypervisors.
138 When a chassis shuts down gracefully, it should remove its own row.
139 (This is not critical because resources hosted on the chassis are equally
140 unreachable regardless of whether the row is present.) If a chassis
141 shuts down permanently without removing its row, some kind of manual or
142 automatic cleanup is eventually needed; we can devise a process for that
147 A chassis name, taken from <ref key="system-id" table="Open_vSwitch"
148 column="external_ids" db="Open_vSwitch"/> in the Open_vSwitch
149 database's <ref table="Open_vSwitch" db="Open_vSwitch"/> table. OVN does
150 not prescribe a particular format for chassis names.
153 <group title="Encapsulation Configuration">
155 OVN uses encapsulation to transmit logical dataplane packets
159 <column name="encaps">
160 Points to supported encapsulation configurations to transmit
161 logical dataplane packets to this chassis. Each entry is a <ref
162 table="Encap"/> record that describes the configuration.
166 <group title="Gateway Configuration">
168 A <dfn>gateway</dfn> is a chassis that forwards traffic between a
169 logical network and a physical VLAN. Gateways are typically dedicated
170 nodes that do not host VMs.
173 <column name="gateway_ports">
174 Maps from the name of a port attached to the OVN integration bridge
175 (typically a physical port or an Open vSwitch patch port) to a <ref
176 table="Gateway"/> record that describes the details of the gatewaying
182 <table name="Encap" title="Encapsulation Types">
184 The <ref column="encaps" table="Chassis"/> column in the <ref
185 table="Chassis"/> table refers to rows in this table to identify
186 how OVN may transmit logical dataplane packets to this chassis.
187 Each chassis, via <code>ovn-controller</code>(8), adds and updates
188 its own rows and keeps a copy of the remaining rows to determine
189 how to reach other chassis.
193 The encapsulation to use to transmit packets to this chassis.
194 Hypervisors must use either <code>geneve</code> or
195 <code>stt</code>. Gateways may use <code>vxlan</code>,
196 <code>geneve</code>, or <code>stt</code>.
199 <column name="options">
200 Options for configuring the encapsulation, e.g. IPsec parameters when
201 IPsec support is introduced. No options are currently defined.
205 The IPv4 address of the encapsulation tunnel endpoint.
209 <table name="Gateway" title="Physical Network Gateway Ports">
211 The <ref column="gateway_ports" table="Chassis"/> column in the <ref
212 table="Chassis"/> table refers to rows in this table to connect a chassis
213 port to a gateway function. Each row in this table describes the logical
214 networks to which a gateway port is attached. Each chassis, via
215 <code>ovn-controller</code>(8), adds and updates its own rows, if any
216 (since most chassis are not gateways), and keeps a copy of the remaining
217 rows to determine how to reach other chassis.
220 <column name="vlan_map">
221 Maps from a VLAN ID to a logical port name. Thus, each named logical
222 port corresponds to one VLAN on the gateway port.
226 <table name="Logical_Flow" title="Logical Network Flows">
228 Each row in this table represents one logical flow. The cloud management
229 system, via its OVN integration, populates this table with logical flows
230 that implement the L2 and L3 topology specified in the CMS configuration.
231 Each hypervisor, via <code>ovn-controller</code>, translates the logical
232 flows into OpenFlow flows specific to its hypervisor and installs them
237 Logical flows are expressed in an OVN-specific format, described here. A
238 logical datapath flow is much like an OpenFlow flow, except that the
239 flows are written in terms of logical ports and logical datapaths instead
240 of physical ports and physical datapaths. Translation between logical
241 and physical flows helps to ensure isolation between logical datapaths.
242 (The logical flow abstraction also allows the CMS to do less work, since
243 it does not have to separately compute and push out physical flows to each
248 The default action when no flow matches is to drop packets.
251 <p><em>Logical Life Cycle of a Packet</em></p>
254 This following description focuses on the life cycle of a packet through
255 a logical datapath, ignoring physical details of the implementation.
256 Please refer to <em>Life Cycle of a Packet</em> in
257 <code>ovn-architecture</code>(7) for the physical information.
261 The description here is written as if OVN itself executes these steps,
262 but in fact OVN (that is, <code>ovn-controller</code>) programs Open
263 vSwitch, via OpenFlow and OVSDB, to execute them on its behalf.
267 At a high level, OVN passes each packet through the logical datapath's
268 logical ingress pipeline, which may output the packet to one or more
269 logical port or logical multicast groups. For each such logical output
270 port, OVN passes the packet through the datapath's logical egress
271 pipeline, which may either drop the packet or deliver it to the
272 destination. Between the two pipelines, outputs to logical multicast
273 groups are expanded into logical ports, so that the egress pipeline only
274 processes a single logical output port at a time. Between the two
275 pipelines is also where, when necessary, OVN encapsulates a packet in a
276 tunnel (or tunnels) to transmit to remote hypervisors.
280 In more detail, to start, OVN searches the <ref table="Logical_Flow"/>
281 table for a row with correct <ref column="logical_datapath"/>, a <ref
282 column="pipeline"/> of <code>ingress</code>, a <ref column="table_id"/>
283 of 0, and a <ref column="match"/> that is true for the packet. If none
284 is found, OVN drops the packet. If OVN finds more than one, it chooses
285 the match with the highest <ref column="priority"/>. Then OVN executes
286 each of the actions specified in the row's <ref table="actions"/> column,
287 in the order specified. Some actions, such as those to modify packet
288 headers, require no further details. The <code>next</code> and
289 <code>output</code> actions are special.
293 The <code>next</code> action causes the above process to be repeated
294 recursively, except that OVN searches for <ref column="table_id"/> of 1
295 instead of 0. Similarly, any <code>next</code> action in a row found in
296 that table would cause a further search for a <ref column="table_id"/> of
297 2, and so on. When recursive processing completes, flow control returns
298 to the action following <code>next</code>.
302 The <code>output</code> action also introduces recursion. Its effect
303 depends on the current value of the <code>outport</code> field. Suppose
304 <code>outport</code> designates a logical port. First, OVN compares
305 <code>inport</code> to <code>outport</code>; if they are equal, it treats
306 the <code>output</code> as a no-op. In the common case, where they are
307 different, the packet enters the egress pipeline. This transition to the
308 egress pipeline discards register data, e.g. <code>reg0</code>
309 ... <code>reg5</code>, to achieve uniform behavior regardless of whether
310 the egress pipeline is on a different hypervisor (because registers
311 aren't preserve across tunnel encapsulation).
315 To execute the egress pipeline, OVN again searches the <ref
316 table="Logical_Flow"/> table for a row with correct <ref
317 column="logical_datapath"/>, a <ref column="table_id"/> of 0, a <ref
318 column="match"/> that is true for the packet, but now looking for a <ref
319 column="pipeline"/> of <code>egress</code>. If no matching row is found,
320 the output becomes a no-op. Otherwise, OVN executes the actions for the
321 matching flow (which is chosen from multiple, if necessary, as already
326 In the <code>egress</code> pipeline, the <code>next</code> action acts as
327 already described, except that it, of course, searches for
328 <code>egress</code> flows. The <code>output</code> action, however, now
329 directly outputs the packet to the output port (which is now fixed,
330 because <code>outport</code> is read-only within the egress pipeline).
334 The description earlier assumed that <code>outport</code> referred to a
335 logical port. If it instead designates a logical multicast group, then
336 the description above still applies, with the addition of fan-out from
337 the logical multicast group to each logical port in the group. For each
338 member of the group, OVN executes the logical pipeline as described, with
339 the logical output port replaced by the group member.
342 <column name="logical_datapath">
343 The logical datapath to which the logical flow belongs.
346 <column name="pipeline">
348 The primary flows used for deciding on a packet's destination are the
349 <code>ingress</code> flows. The <code>egress</code> flows implement
350 ACLs. See <em>Logical Life Cycle of a Packet</em>, above, for details.
354 <column name="table_id">
355 The stage in the logical pipeline, analogous to an OpenFlow table number.
358 <column name="priority">
359 The flow's priority. Flows with numerically higher priority take
360 precedence over those with lower. If two logical datapath flows with the
361 same priority both match, then the one actually applied to the packet is
365 <column name="match">
367 A matching expression. OVN provides a superset of OpenFlow matching
368 capabilities, using a syntax similar to Boolean expressions in a
369 programming language.
373 The most important components of match expression are
374 <dfn>comparisons</dfn> between <dfn>symbols</dfn> and
375 <dfn>constants</dfn>, e.g. <code>ip4.dst == 192.168.0.1</code>,
376 <code>ip.proto == 6</code>, <code>arp.op == 1</code>, <code>eth.type ==
377 0x800</code>. The logical AND operator <code>&&</code> and
378 logical OR operator <code>||</code> can combine comparisons into a
383 Matching expressions also support parentheses for grouping, the logical
384 NOT prefix operator <code>!</code>, and literals <code>0</code> and
385 <code>1</code> to express ``false'' or ``true,'' respectively. The
386 latter is useful by itself as a catch-all expression that matches every
390 <p><em>Symbols</em></p>
393 <em>Type</em>. Symbols have <dfn>integer</dfn> or <dfn>string</dfn>
394 type. Integer symbols have a <dfn>width</dfn> in bits.
398 <em>Kinds</em>. There are three kinds of symbols:
404 <dfn>Fields</dfn>. A field symbol represents a packet header or
405 metadata field. For example, a field
406 named <code>vlan.tci</code> might represent the VLAN TCI field in a
411 A field symbol can have integer or string type. Integer fields can
412 be nominal or ordinal (see <em>Level of Measurement</em>,
419 <dfn>Subfields</dfn>. A subfield represents a subset of bits from
420 a larger field. For example, a field <code>vlan.vid</code> might
421 be defined as an alias for <code>vlan.tci[0..11]</code>. Subfields
422 are provided for syntactic convenience, because it is always
423 possible to instead refer to a subset of bits from a field
428 Only ordinal fields (see <em>Level of Measurement</em>,
429 below) may have subfields. Subfields are always ordinal.
435 <dfn>Predicates</dfn>. A predicate is shorthand for a Boolean
436 expression. Predicates may be used much like 1-bit fields. For
437 example, <code>ip4</code> might expand to <code>eth.type ==
438 0x800</code>. Predicates are provided for syntactic convenience,
439 because it is always possible to instead specify the underlying
444 A predicate whose expansion refers to any nominal field or
445 predicate (see <em>Level of Measurement</em>, below) is nominal;
446 other predicates have Boolean level of measurement.
452 <em>Level of Measurement</em>. See
453 http://en.wikipedia.org/wiki/Level_of_measurement for the statistical
454 concept on which this classification is based. There are three
461 <dfn>Ordinal</dfn>. In statistics, ordinal values can be ordered
462 on a scale. OVN considers a field (or subfield) to be ordinal if
463 its bits can be examined individually. This is true for the
464 OpenFlow fields that OpenFlow or Open vSwitch makes ``maskable.''
468 Any use of a nominal field may specify a single bit or a range of
469 bits, e.g. <code>vlan.tci[13..15]</code> refers to the PCP field
470 within the VLAN TCI, and <code>eth.dst[40]</code> refers to the
471 multicast bit in the Ethernet destination address.
475 OVN supports all the usual arithmetic relations (<code>==</code>,
476 <code>!=</code>, <code><</code>, <code><=</code>,
477 <code>></code>, and <code>>=</code>) on ordinal fields and
478 their subfields, because OVN can implement these in OpenFlow and
479 Open vSwitch as collections of bitwise tests.
485 <dfn>Nominal</dfn>. In statistics, nominal values cannot be
486 usefully compared except for equality. This is true of OpenFlow
487 port numbers, Ethernet types, and IP protocols are examples: all of
488 these are just identifiers assigned arbitrarily with no deeper
489 meaning. In OpenFlow and Open vSwitch, bits in these fields
490 generally aren't individually addressable.
494 OVN only supports arithmetic tests for equality on nominal fields,
495 because OpenFlow and Open vSwitch provide no way for a flow to
496 efficiently implement other comparisons on them. (A test for
497 inequality can be sort of built out of two flows with different
498 priorities, but OVN matching expressions always generate flows with
503 String fields are always nominal.
509 <dfn>Boolean</dfn>. A nominal field that has only two values, 0
510 and 1, is somewhat exceptional, since it is easy to support both
511 equality and inequality tests on such a field: either one can be
512 implemented as a test for 0 or 1.
516 Only predicates (see above) have a Boolean level of measurement.
520 This isn't a standard level of measurement.
526 <em>Prerequisites</em>. Any symbol can have prerequisites, which are
527 additional condition implied by the use of the symbol. For example,
528 For example, <code>icmp4.type</code> symbol might have prerequisite
529 <code>icmp4</code>, which would cause an expression <code>icmp4.type ==
530 0</code> to be interpreted as <code>icmp4.type == 0 &&
531 icmp4</code>, which would in turn expand to <code>icmp4.type == 0
532 && eth.type == 0x800 && ip4.proto == 1</code> (assuming
533 <code>icmp4</code> is a predicate defined as suggested under
534 <em>Types</em> above).
537 <p><em>Relational operators</em></p>
540 All of the standard relational operators <code>==</code>,
541 <code>!=</code>, <code><</code>, <code><=</code>,
542 <code>></code>, and <code>>=</code> are supported. Nominal
543 fields support only <code>==</code> and <code>!=</code>, and only in a
544 positive sense when outer <code>!</code> are taken into account,
545 e.g. given string field <code>inport</code>, <code>inport ==
546 "eth0"</code> and <code>!(inport != "eth0")</code> are acceptable, but
547 not <code>inport != "eth0"</code>.
551 The implementation of <code>==</code> (or <code>!=</code> when it is
552 negated), is more efficient than that of the other relational
556 <p><em>Constants</em></p>
559 Integer constants may be expressed in decimal, hexadecimal prefixed by
560 <code>0x</code>, or as dotted-quad IPv4 addresses, IPv6 addresses in
561 their standard forms, or Ethernet addresses as colon-separated hex
562 digits. A constant in any of these forms may be followed by a slash
563 and a second constant (the mask) in the same form, to form a masked
564 constant. IPv4 and IPv6 masks may be given as integers, to express
569 String constants have the same syntax as quoted strings in JSON (thus,
570 they are Unicode strings).
574 Some operators support sets of constants written inside curly braces
575 <code>{</code> ... <code>}</code>. Commas between elements of a set,
576 and after the last elements, are optional. With <code>==</code>,
577 ``<code><var>field</var> == { <var>constant1</var>,
578 <var>constant2</var>,</code> ... <code>}</code>'' is syntactic sugar
579 for ``<code><var>field</var> == <var>constant1</var> ||
580 <var>field</var> == <var>constant2</var> || </code>...<code></code>.
581 Similarly, ``<code><var>field</var> != { <var>constant1</var>,
582 <var>constant2</var>, </code>...<code> }</code>'' is equivalent to
583 ``<code><var>field</var> != <var>constant1</var> &&
584 <var>field</var> != <var>constant2</var> &&
585 </code>...<code></code>''.
588 <p><em>Miscellaneous</em></p>
591 Comparisons may name the symbol or the constant first,
592 e.g. <code>tcp.src == 80</code> and <code>80 == tcp.src</code> are both
597 Tests for a range may be expressed using a syntax like <code>1024 <=
598 tcp.src <= 49151</code>, which is equivalent to <code>1024 <=
599 tcp.src && tcp.src <= 49151</code>.
603 For a one-bit field or predicate, a mention of its name is equivalent
604 to <code><var>symobl</var> == 1</code>, e.g. <code>vlan.present</code>
605 is equivalent to <code>vlan.present == 1</code>. The same is true for
606 one-bit subfields, e.g. <code>vlan.tci[12]</code>. There is no
607 technical limitation to implementing the same for ordinal fields of all
608 widths, but the implementation is expensive enough that the syntax
609 parser requires writing an explicit comparison against zero to make
610 mistakes less likely, e.g. in <code>tcp.src != 0</code> the comparison
611 against 0 is required.
615 <em>Operator precedence</em> is as shown below, from highest to lowest.
616 There are two exceptions where parentheses are required even though the
617 table would suggest that they are not: <code>&&</code> and
618 <code>||</code> require parentheses when used together, and
619 <code>!</code> requires parentheses when applied to a relational
620 expression. Thus, in <code>(eth.type == 0x800 || eth.type == 0x86dd)
621 && ip.proto == 6</code> or <code>!(arp.op == 1)</code>, the
622 parentheses are mandatory.
626 <li><code>()</code></li>
627 <li><code>== != < <= > >=</code></li>
628 <li><code>!</code></li>
629 <li><code>&& ||</code></li>
633 <em>Comments</em> may be introduced by <code>//</code>, which extends
634 to the next new-line. Comments within a line may be bracketed by
635 <code>/*</code> and <code>*/</code>. Multiline comments are not
639 <p><em>Symbols</em></p>
642 Most of the symbols below have integer type. Only <code>inport</code>
643 and <code>outport</code> have string type. <code>inport</code> names a
644 logical port. Thus, its value is a <ref column="logical_port"/> name
645 from the <ref table="Port_Binding"/> or <ref table="Gateway"/> tables.
646 <code>outport</code> may name a logical port, as <code>inport</code>,
647 or a logical multicast group defined in the <ref
648 table="Multicast_Group"/> table. For both symbols, only names within
649 the flow's logical datapath may be used.
653 <li><code>reg0</code>...<code>reg5</code></li>
654 <li><code>inport</code> <code>outport</code></li>
655 <li><code>eth.src</code> <code>eth.dst</code> <code>eth.type</code></li>
656 <li><code>vlan.tci</code> <code>vlan.vid</code> <code>vlan.pcp</code> <code>vlan.present</code></li>
657 <li><code>ip.proto</code> <code>ip.dscp</code> <code>ip.ecn</code> <code>ip.ttl</code> <code>ip.frag</code></li>
658 <li><code>ip4.src</code> <code>ip4.dst</code></li>
659 <li><code>ip6.src</code> <code>ip6.dst</code> <code>ip6.label</code></li>
660 <li><code>arp.op</code> <code>arp.spa</code> <code>arp.tpa</code> <code>arp.sha</code> <code>arp.tha</code></li>
661 <li><code>tcp.src</code> <code>tcp.dst</code> <code>tcp.flags</code></li>
662 <li><code>udp.src</code> <code>udp.dst</code></li>
663 <li><code>sctp.src</code> <code>sctp.dst</code></li>
664 <li><code>icmp4.type</code> <code>icmp4.code</code></li>
665 <li><code>icmp6.type</code> <code>icmp6.code</code></li>
666 <li><code>nd.target</code> <code>nd.sll</code> <code>nd.tll</code></li>
671 <column name="actions">
673 Logical datapath actions, to be executed when the logical flow
674 represented by this row is the highest-priority match.
678 Actions share lexical syntax with the <ref column="match"/> column. An
679 empty set of actions (or one that contains just white space or
680 comments), or a set of actions that consists of just
681 <code>drop;</code>, causes the matched packets to be dropped.
682 Otherwise, the column should contain a sequence of actions, each
683 terminated by a semicolon.
687 The following actions are defined:
691 <dt><code>output;</code></dt>
694 In the ingress pipeline, this action executes the
695 <code>egress</code> pipeline as a subroutine. If
696 <code>outport</code> names a logical port, the egress pipeline
697 executes once; if it is a multicast group, the egress pipeline runs
698 once for each logical port in the group.
702 In the egress pipeline, this action performs the actual
703 output to the <code>outport</code> logical port. (In the egress
704 pipeline, <code>outport</code> never names a multicast group.)
708 Output to the input port is implicitly dropped, that is,
709 <code>output</code> becomes a no-op if <code>outport</code> ==
714 <dt><code>next;</code></dt>
716 Executes the next logical datapath table as a subroutine.
719 <dt><code><var>field</var> = <var>constant</var>;</code></dt>
722 Sets data or metadata field <var>field</var> to constant value
723 <var>constant</var>, e.g. <code>outport = "vif0";</code> to set the
724 logical output port. To set only a subset of bits in a field,
725 specify a subfield for <var>field</var> or a masked
726 <var>constant</var>, e.g. one may use <code>vlan.pcp[2] = 1;</code>
727 or <code>vlan.pcp = 4/4;</code> to set the most sigificant bit of
732 Assigning to a field with prerequisites implicitly adds those
733 prerequisites to <ref column="match"/>; thus, for example, a flow
734 that sets <code>tcp.dst</code> applies only to TCP flows,
735 regardless of whether its <ref column="match"/> mentions any TCP
740 Not all fields are modifiable (e.g. <code>eth.type</code> and
741 <code>ip.proto</code> are read-only), and not all modifiable fields
742 may be partially modified (e.g. <code>ip.ttl</code> must assigned
743 as a whole). The <code>outport</code> field is modifiable in the
744 <code>ingress</code> pipeline but not in the <code>egress</code>
751 The following actions will likely be useful later, but they have not
752 been thought out carefully.
756 <dt><code><var>field1</var> = <var>field2</var>;</code></dt>
758 Extends the assignment action to allow copying between fields.
761 <dt><code>learn</code></dt>
763 <dt><code>conntrack</code></dt>
765 <dt><code>dec_ttl { <var>action</var>, </code>...<code> } { <var>action</var>; </code>...<code>};</code></dt>
767 decrement TTL; execute first set of actions if
768 successful, second set if TTL decrement fails
771 <dt><code>icmp_reply { <var>action</var>, </code>...<code> };</code></dt>
772 <dd>generate ICMP reply from packet, execute <var>action</var>s</dd>
774 <dt><code>arp { <var>action</var>, </code>...<code> }</code></dt>
775 <dd>generate ARP from packet, execute <var>action</var>s</dd>
780 <table name="Multicast_Group" title="Logical Port Multicast Groups">
782 The rows in this table define multicast groups of logical ports.
783 Multicast groups allow a single packet transmitted over a tunnel to a
784 hypervisor to be delivered to multiple VMs on that hypervisor, which
785 uses bandwidth more efficiently.
789 Each row in this table defines a logical multicast group numbered <ref
790 column="tunnel_key"/> within <ref column="datapath"/>, whose logical
791 ports are listed in the <ref column="ports"/> column.
794 <column name="datapath">
795 The logical datapath in which the multicast group resides.
798 <column name="tunnel_key">
799 The value used to designate this logical egress port in tunnel
800 encapsulations. An index forces the key to be unique within the <ref
801 column="datapath"/>. The unusual range ensures that multicast group IDs
802 do not overlap with logical port IDs.
807 The logical multicast group's name. An index forces the name to be
808 unique within the <ref column="datapath"/>. Logical flows in the
809 ingress pipeline may output to the group just as for individual logical
810 ports, by assigning the group's name to <code>outport</code> and
811 executing an <code>output</code> action.
815 Multicast group names and logical port names share a single namespace
816 and thus should not overlap (but the database schema cannot enforce
817 this). To try to avoid conflicts, <code>ovn-northd</code> uses names
818 that begin with <code>_MC_</code>.
822 <column name="ports">
823 The logical ports included in the multicast group. All of these ports
824 must be in the <ref column="datapath"/> logical datapath (but the
825 database schema cannot enforce this).
829 <table name="Datapath_Binding" title="Physical-Logical Datapath Bindings">
831 Each row in this table identifies physical bindings of a logical
832 datapath. A logical datapath implements a logical pipeline among the
833 ports in the <ref table="Port_Binding"/> table associated with it. In
834 practice, the pipeline in a given logical datapath implements either a
835 logical switch or a logical router.
838 <column name="tunnel_key">
839 The tunnel key value to which the logical datapath is bound.
840 The <code>Tunnel Encapsulation</code> section in
841 <code>ovn-architecture</code>(7) describes how tunnel keys are
842 constructed for each supported encapsulation.
845 <column name="external_ids" key="logical-switch" type='{"type": "uuid"}'>
846 Each row in <ref table="Datapath_Binding"/> is associated with some
847 logical datapath. <code>ovn-northd</code> uses this key to store the
848 UUID of the logical datapath <ref table="Logical_Switch"
849 db="OVN_Northbound"/> row in the <ref db="OVN_Northbound"/> database.
852 <group title="Common Columns">
853 The overall purpose of these columns is described under <code>Common
854 Columns</code> at the beginning of this document.
856 <column name="external_ids"/>
860 <table name="Port_Binding" title="Physical-Logical Port Bindings">
862 Each row in this table identifies the physical location of a logical
867 For every <code>Logical_Port</code> record in <code>OVN_Northbound</code>
868 database, <code>ovn-northd</code> creates a record in this table.
869 <code>ovn-northd</code> populates and maintains every column except
870 the <code>chassis</code> column, which it leaves empty in new records.
874 <code>ovn-controller</code> populates the <code>chassis</code> column
875 for the records that identify the logical ports that are located on its
876 hypervisor, which <code>ovn-controller</code> in turn finds out by
877 monitoring the local hypervisor's Open_vSwitch database, which
878 identifies logical ports via the conventions described in
879 <code>IntegrationGuide.md</code>.
883 When a chassis shuts down gracefully, it should clean up the
884 <code>chassis</code> column that it previously had populated.
885 (This is not critical because resources hosted on the chassis are equally
886 unreachable regardless of whether their rows are present.) To handle the
887 case where a VM is shut down abruptly on one chassis, then brought up
888 again on a different one, <code>ovn-controller</code> must overwrite the
889 <code>chassis</code> column with new information.
892 <column name="datapath">
893 The logical datapath to which the logical port belongs.
896 <column name="logical_port">
897 A logical port, taken from <ref table="Logical_Port" column="name"
898 db="OVN_Northbound"/> in the OVN_Northbound database's
899 <ref table="Logical_Port" db="OVN_Northbound"/> table. OVN does not
900 prescribe a particular format for the logical port ID.
905 A type for this logical port. Logical ports can be used to model
906 other types of connectivity into an OVN logical switch. Leaving this column
907 blank maintains the default logical port behavior.
911 There are no other logical port types implemented yet.
915 <column name="options">
916 This column provides key/value settings specific to the logical port
917 <ref column="type"/>.
920 <column name="tunnel_key">
922 A number that represents the logical port in the key (e.g. STT key or
923 Geneve TLV) field carried within tunnel protocol packets.
927 The tunnel ID must be unique within the scope of a logical datapath.
931 <column name="parent_port">
932 For containers created inside a VM, this is taken from
933 <ref table="Logical_Port" column="parent_name" db="OVN_Northbound"/>
934 in the OVN_Northbound database's <ref table="Logical_Port"
935 db="OVN_Northbound"/> table. It is left empty if
936 <ref column="logical_port"/> belongs to a VM or a container created
941 When <ref column="logical_port"/> identifies the interface of a container
942 spawned inside a VM, this column identifies the VLAN tag in
943 the network traffic associated with that container's network interface.
944 It is left empty if <ref column="logical_port"/> belongs to a VM or a
945 container created in the hypervisor.
948 <column name="chassis">
949 The physical location of the logical port. To successfully identify a
950 chassis, this column must be a <ref table="Chassis"/> record. This is
951 populated by <code>ovn-controller</code>.
956 The Ethernet address or addresses used as a source address on the
957 logical port, each in the form
958 <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>.
959 The string <code>unknown</code> is also allowed to indicate that the
960 logical port has an unknown set of (additional) source addresses.
964 A VM interface would ordinarily have a single Ethernet address. A
965 gateway port might initially only have <code>unknown</code>, and then
966 add MAC addresses to the set as it learns new source addresses.