]>
Commit | Line | Data |
---|---|---|
fe36184b | 1 | <?xml version="1.0" encoding="utf-8"?> |
ec78987f | 2 | <database name="ovn-sb" title="OVN Southbound Database"> |
fe36184b BP |
3 | <p> |
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). | |
7 | </p> | |
8 | ||
9 | <p> | |
ec78987f JP |
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 | |
88058f19 AW |
13 | <code>ovn-controller</code>/<code>ovn-controller-vtep</code>, and |
14 | northbound to the Cloud Management System, via <code>ovn-northd</code>: | |
fe36184b BP |
15 | </p> |
16 | ||
17 | <h2>Database Structure</h2> | |
18 | ||
19 | <p> | |
0bac7164 | 20 | The OVN Southbound database contains classes of data with |
ec78987f | 21 | different properties, as described in the sections below. |
fe36184b BP |
22 | </p> |
23 | ||
2357e695 | 24 | <h3>Physical network</h3> |
fe36184b BP |
25 | |
26 | <p> | |
2357e695 BP |
27 | Physical network tables contain information about the chassis nodes in the |
28 | system. This contains all the information necessary to wire the overlay, | |
29 | such as IP addresses, supported tunnel types, and security keys. | |
fe36184b BP |
30 | </p> |
31 | ||
32 | <p> | |
2357e695 BP |
33 | The amount of physical network data is small (O(n) in the number of |
34 | chassis) and it changes infrequently, so it can be replicated to every | |
35 | chassis. | |
fe36184b BP |
36 | </p> |
37 | ||
38 | <p> | |
2357e695 BP |
39 | The <ref table="Chassis"/> and <ref table="Encap"/> tables are the physical |
40 | network tables. | |
fe36184b BP |
41 | </p> |
42 | ||
2357e695 | 43 | <h3>Logical Network</h3> |
fe36184b BP |
44 | |
45 | <p> | |
2357e695 BP |
46 | Logical network tables contain the topology of logical switches and |
47 | routers, ACLs, firewall rules, and everything needed to describe how | |
48 | packets traverse a logical network, represented as logical datapath flows | |
49 | (see Logical Datapath Flows, below). | |
fe36184b BP |
50 | </p> |
51 | ||
52 | <p> | |
2357e695 BP |
53 | Logical network data may be large (O(n) in the number of logical ports, ACL |
54 | rules, etc.). Thus, to improve scaling, each chassis should receive only | |
55 | data related to logical networks in which that chassis participates. | |
fe36184b BP |
56 | </p> |
57 | ||
58 | <p> | |
2357e695 BP |
59 | The logical network data is ultimately controlled by the cloud management |
60 | system (CMS) running northbound of OVN. That CMS determines the entire OVN | |
61 | logical configuration and therefore the logical network data at any given | |
62 | time is a deterministic function of the CMS's configuration, although that | |
63 | happens indirectly via the <ref db="OVN_Northbound"/> database and | |
64 | <code>ovn-northd</code>. | |
fe36184b BP |
65 | </p> |
66 | ||
67 | <p> | |
2357e695 BP |
68 | Logical network data is likely to change more quickly than physical network |
69 | data. This is especially true in a container environment where containers | |
70 | are created and destroyed (and therefore added to and deleted from logical | |
71 | switches) quickly. | |
fe36184b BP |
72 | </p> |
73 | ||
74 | <p> | |
2357e695 BP |
75 | The <ref table="Logical_Flow"/>, <ref table="Multicast_Group"/>, <ref |
76 | table="Address_Group"/>, <ref table="DHCP_Options"/>, <ref | |
77 | table="DHCPv6_Options"/>, and <ref table="DNS"/> tables contain logical | |
78 | network data. | |
fe36184b BP |
79 | </p> |
80 | ||
0bac7164 | 81 | <h3>Logical-physical bindings</h3> |
fe36184b BP |
82 | |
83 | <p> | |
0bac7164 | 84 | These tables link logical and physical components. They show the current |
5868eb24 BP |
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 | |
87 | encapsulations. | |
fe36184b BP |
88 | </p> |
89 | ||
90 | <p> | |
0bac7164 | 91 | These tables change frequently, at least every time a VM powers up or down |
fe36184b BP |
92 | or migrates, and especially quickly in a container environment. The |
93 | amount of data per VM (or VIF) is small. | |
94 | </p> | |
95 | ||
96 | <p> | |
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. | |
100 | </p> | |
101 | ||
102 | <p> | |
5868eb24 BP |
103 | The <ref table="Port_Binding"/> and <ref table="Datapath_Binding"/> tables |
104 | contain binding data. | |
fe36184b BP |
105 | </p> |
106 | ||
0bac7164 BP |
107 | <h3>MAC bindings</h3> |
108 | ||
109 | <p> | |
110 | The <ref table="MAC_Binding"/> table tracks the bindings from IP addresses | |
111 | to Ethernet addresses that are dynamically discovered using ARP (for IPv4) | |
112 | and neighbor discovery (for IPv6). Usually, IP-to-MAC bindings for virtual | |
113 | machines are statically populated into the <ref table="Port_Binding"/> | |
114 | table, so <ref table="MAC_Binding"/> is primarily used to discover bindings | |
115 | on physical networks. | |
116 | </p> | |
117 | ||
5868eb24 BP |
118 | <h2>Common Columns</h2> |
119 | ||
120 | <p> | |
121 | Some tables contain a special column named <code>external_ids</code>. This | |
122 | column has the same form and purpose each place that it appears, so we | |
123 | describe it here to save space later. | |
124 | </p> | |
125 | ||
126 | <dl> | |
127 | <dt><code>external_ids</code>: map of string-string pairs</dt> | |
128 | <dd> | |
129 | Key-value pairs for use by the software that manages the OVN Southbound | |
88058f19 AW |
130 | database rather than by |
131 | <code>ovn-controller</code>/<code>ovn-controller-vtep</code>. In | |
132 | particular, <code>ovn-northd</code> can use key-value pairs in this | |
133 | column to relate entities in the southbound database to higher-level | |
134 | entities (such as entities in the OVN Northbound database). Individual | |
135 | key-value pairs in this column may be documented in some cases to aid | |
136 | in understanding and troubleshooting, but the reader should not mistake | |
137 | such documentation as comprehensive. | |
5868eb24 BP |
138 | </dd> |
139 | </dl> | |
140 | ||
fa183acc BP |
141 | <table name="SB_Global" title="Southbound configuration"> |
142 | <p> | |
143 | Southbound configuration for an OVN system. This table must have exactly | |
144 | one row. | |
145 | </p> | |
146 | ||
147 | <group title="Status"> | |
148 | This column allow a client to track the overall configuration state of | |
149 | the system. | |
150 | ||
151 | <column name="nb_cfg"> | |
152 | Sequence number for the configuration. When a CMS or | |
153 | <code>ovn-nbctl</code> updates the northbound database, it increments | |
154 | the <code>nb_cfg</code> column in the <code>NB_Global</code> table in | |
155 | the northbound database. In turn, when <code>ovn-northd</code> updates | |
156 | the southbound database to bring it up to date with these changes, it | |
157 | updates this column to the same value. | |
158 | </column> | |
159 | </group> | |
160 | ||
161 | <group title="Common Columns"> | |
162 | <column name="external_ids"> | |
163 | See <em>External IDs</em> at the beginning of this document. | |
164 | </column> | |
165 | </group> | |
7fff4eb7 LR |
166 | <group title="Connection Options"> |
167 | <column name="connections"> | |
168 | Database clients to which the Open vSwitch database server should | |
169 | connect or on which it should listen, along with options for how these | |
170 | connections should be configured. See the <ref table="Connection"/> | |
171 | table for more information. | |
172 | </column> | |
10471820 LR |
173 | <column name="ssl"> |
174 | Global SSL configuration. | |
175 | </column> | |
7fff4eb7 | 176 | </group> |
fa183acc BP |
177 | </table> |
178 | ||
fe36184b BP |
179 | <table name="Chassis" title="Physical Network Hypervisor and Gateway Information"> |
180 | <p> | |
181 | Each row in this table represents a hypervisor or gateway (a chassis) in | |
2357e695 | 182 | the physical network. Each chassis, via |
88058f19 AW |
183 | <code>ovn-controller</code>/<code>ovn-controller-vtep</code>, adds |
184 | and updates its own row, and keeps a copy of the remaining rows to | |
185 | determine how to reach other hypervisors. | |
fe36184b BP |
186 | </p> |
187 | ||
188 | <p> | |
189 | When a chassis shuts down gracefully, it should remove its own row. | |
190 | (This is not critical because resources hosted on the chassis are equally | |
191 | unreachable regardless of whether the row is present.) If a chassis | |
192 | shuts down permanently without removing its row, some kind of manual or | |
193 | automatic cleanup is eventually needed; we can devise a process for that | |
194 | as necessary. | |
195 | </p> | |
196 | ||
197 | <column name="name"> | |
fc26cf25 RB |
198 | OVN does not prescribe a particular format for chassis names. |
199 | ovn-controller populates this column using <ref key="system-id" | |
200 | table="Open_vSwitch" column="external_ids" db="Open_vSwitch"/> | |
201 | in the Open_vSwitch database's <ref table="Open_vSwitch" | |
202 | db="Open_vSwitch"/> table. ovn-controller-vtep populates this | |
203 | column with <ref table="Physical_Switch" column="name" | |
204 | db="hardware_vtep"/> in the hardware_vtep database's | |
205 | <ref table="Physical_Switch" db="hardware_vtep"/> table. | |
fe36184b BP |
206 | </column> |
207 | ||
2229f3ec RB |
208 | <column name="hostname"> |
209 | The hostname of the chassis, if applicable. ovn-controller will populate | |
210 | this column with the hostname of the host it is running on. | |
211 | ovn-controller-vtep will leave this column empty. | |
212 | </column> | |
213 | ||
fa183acc BP |
214 | <column name="nb_cfg"> |
215 | Sequence number for the configuration. When <code>ovn-controller</code> | |
216 | updates the configuration of a chassis from the contents of the | |
217 | southbound database, it copies <ref table="SB_Global" column="nb_cfg"/> | |
218 | from the <ref table="SB_Global"/> table into this column. | |
219 | </column> | |
220 | ||
4250ee37 RB |
221 | <column name="external_ids" key="ovn-bridge-mappings"> |
222 | <code>ovn-controller</code> populates this key with the set of bridge | |
223 | mappings it has been configured to use. Other applications should treat | |
224 | this key as read-only. See <code>ovn-controller</code>(8) for more | |
225 | information. | |
226 | </column> | |
227 | ||
5236c73a NS |
228 | <column name="external_ids" key="datapath-type"> |
229 | <code>ovn-controller</code> populates this key with the datapath type | |
230 | configured in the <ref table="Bridge" column="datapath_type"/> column of | |
231 | the Open_vSwitch database's <ref table="Bridge" db="Open_vSwitch"/> | |
232 | table. Other applications should treat this key as read-only. See | |
233 | <code>ovn-controller</code>(8) for more information. | |
234 | </column> | |
235 | ||
236 | <column name="external_ids" key="iface-types"> | |
237 | <code>ovn-controller</code> populates this key with the interface types | |
238 | configured in the <ref table="Open_vSwitch" column="iface_types"/> column | |
239 | of the Open_vSwitch database's <ref table="Open_vSwitch" | |
240 | db="Open_vSwitch"/> table. Other applications should treat this key as | |
241 | read-only. See <code>ovn-controller</code>(8) for more information. | |
242 | </column> | |
243 | ||
1cef5fff RB |
244 | <group title="Common Columns"> |
245 | The overall purpose of these columns is described under <code>Common | |
246 | Columns</code> at the beginning of this document. | |
247 | ||
248 | <column name="external_ids"/> | |
249 | </group> | |
250 | ||
09db214c | 251 | <group title="Encapsulation Configuration"> |
fe36184b | 252 | <p> |
09db214c JP |
253 | OVN uses encapsulation to transmit logical dataplane packets |
254 | between chassis. | |
fe36184b BP |
255 | </p> |
256 | ||
09db214c JP |
257 | <column name="encaps"> |
258 | Points to supported encapsulation configurations to transmit | |
259 | logical dataplane packets to this chassis. Each entry is a <ref | |
260 | table="Encap"/> record that describes the configuration. | |
fe36184b BP |
261 | </column> |
262 | </group> | |
263 | ||
a8cb558a DJ |
264 | <group title="Gateway Configuration"> |
265 | <p> | |
62fdd819 AW |
266 | A <dfn>gateway</dfn> is a chassis that forwards traffic between the |
267 | OVN-managed part of a logical network and a physical VLAN, extending a | |
268 | tunnel-based logical network into a physical network. Gateways are | |
88058f19 AW |
269 | typically dedicated nodes that do not host VMs and will be controlled |
270 | by <code>ovn-controller-vtep</code>. | |
fe36184b BP |
271 | </p> |
272 | ||
62fdd819 | 273 | <column name="vtep_logical_switches"> |
88058f19 AW |
274 | Stores all VTEP logical switch names connected by this gateway |
275 | chassis. The <ref table="Port_Binding"/> table entry with | |
276 | <ref column="options" table="Port_Binding"/>:<code>vtep-physical-switch</code> | |
277 | equal <ref table="Chassis"/> <ref column="name" table="Chassis"/>, and | |
278 | <ref column="options" table="Port_Binding"/>:<code>vtep-logical-switch</code> | |
279 | value in <ref table="Chassis"/> | |
280 | <ref column="vtep_logical_switches" table="Chassis"/>, will be | |
281 | associated with this <ref table="Chassis"/>. | |
fe36184b | 282 | </column> |
a8cb558a | 283 | </group> |
fe36184b BP |
284 | </table> |
285 | ||
09db214c JP |
286 | <table name="Encap" title="Encapsulation Types"> |
287 | <p> | |
288 | The <ref column="encaps" table="Chassis"/> column in the <ref | |
289 | table="Chassis"/> table refers to rows in this table to identify | |
290 | how OVN may transmit logical dataplane packets to this chassis. | |
88058f19 AW |
291 | Each chassis, via <code>ovn-controller</code>(8) or |
292 | <code>ovn-controller-vtep</code>(8), adds and updates its own rows | |
293 | and keeps a copy of the remaining rows to determine how to reach | |
294 | other chassis. | |
09db214c JP |
295 | </p> |
296 | ||
297 | <column name="type"> | |
298 | The encapsulation to use to transmit packets to this chassis. | |
b705f9ea JP |
299 | Hypervisors must use either <code>geneve</code> or |
300 | <code>stt</code>. Gateways may use <code>vxlan</code>, | |
301 | <code>geneve</code>, or <code>stt</code>. | |
09db214c JP |
302 | </column> |
303 | ||
304 | <column name="options"> | |
36283d78 JG |
305 | <p> |
306 | Options for configuring the encapsulation. Currently, the only | |
307 | option that has been defined is <code>csum</code>. | |
a8cb558a | 308 | </p> |
36283d78 JG |
309 | |
310 | <p> | |
311 | <code>csum</code> indicates that encapsulation checksums can be | |
312 | transmitted and received with reasonable performance. It is a hint | |
313 | to senders transmitting data to this chassis that they should use | |
924f0e9f | 314 | checksums to protect OVN metadata. <code>ovn-controller</code> |
ea991ad2 | 315 | populates this key with the value defined in |
924f0e9f NS |
316 | <ref table="Open_vSwitch" column="external_ids:ovn-encap-csum"/> column |
317 | of the Open_vSwitch database's <ref table="Open_vSwitch" | |
318 | db="Open_vSwitch"/> table. Other applications should treat this key as | |
319 | read-only. See <code>ovn-controller</code>(8) for more information. | |
36283d78 JG |
320 | </p> |
321 | ||
322 | <p> | |
323 | In terms of performance, this actually significantly increases | |
324 | throughput in most common cases when running on Linux based hosts | |
325 | without NICs supporting encapsulation hardware offload (around 60% for | |
326 | bulk traffic). The reason is that generally all NICs are capable of | |
327 | offloading transmitted and received TCP/UDP checksums (viewed as | |
328 | ordinary data packets and not as tunnels). The benefit comes on the | |
329 | receive side where the validated outer checksum can be used to | |
330 | additionally validate an inner checksum (such as TCP), which in turn | |
331 | allows aggregation of packets to be more efficiently handled by the | |
332 | rest of the stack. | |
333 | </p> | |
334 | ||
335 | <p> | |
336 | Not all devices see such a benefit. The most notable exception is | |
337 | hardware VTEPs. These devices are designed to not buffer entire | |
338 | packets in their switching engines and are therefore unable to | |
339 | efficiently compute or validate full packet checksums. In addition | |
340 | certain versions of the Linux kernel are not able to fully take | |
341 | advantage of encapsulation NIC offloads in the presence of checksums. | |
342 | (This is actually a pretty narrow corner case though - earlier | |
343 | versions of Linux don't support encapsulation offloads at all and | |
344 | later versions support both offloads and checksums well.) | |
345 | </p> | |
346 | ||
347 | <p> | |
348 | <code>csum</code> defaults to <code>false</code> for hardware VTEPs and | |
349 | <code>true</code> for all other cases. | |
350 | </p> | |
09db214c JP |
351 | </column> |
352 | ||
353 | <column name="ip"> | |
354 | The IPv4 address of the encapsulation tunnel endpoint. | |
355 | </column> | |
af0e9721 MM |
356 | <column name="chassis_name"> |
357 | The name of the chassis that created this encap. | |
358 | </column> | |
09db214c JP |
359 | </table> |
360 | ||
ea382567 RB |
361 | <table name="Address_Set" title="Address Sets"> |
362 | <p> | |
363 | See the documentation for the <ref table="Address_Set" | |
364 | db="OVN_Northbound"/> table in the <ref db="OVN_Northbound"/> database | |
365 | for details. | |
366 | </p> | |
367 | ||
368 | <column name="name"/> | |
369 | <column name="addresses"/> | |
370 | </table> | |
371 | ||
5868eb24 | 372 | <table name="Logical_Flow" title="Logical Network Flows"> |
fe36184b | 373 | <p> |
09986f8c JP |
374 | Each row in this table represents one logical flow. |
375 | <code>ovn-northd</code> populates this table with logical flows | |
376 | that implement the L2 and L3 topologies specified in the | |
377 | <ref db="OVN_Northbound"/> database. Each hypervisor, via | |
378 | <code>ovn-controller</code>, translates the logical flows into | |
379 | OpenFlow flows specific to its hypervisor and installs them into | |
380 | Open vSwitch. | |
fe36184b BP |
381 | </p> |
382 | ||
383 | <p> | |
384 | Logical flows are expressed in an OVN-specific format, described here. A | |
385 | logical datapath flow is much like an OpenFlow flow, except that the | |
386 | flows are written in terms of logical ports and logical datapaths instead | |
387 | of physical ports and physical datapaths. Translation between logical | |
388 | and physical flows helps to ensure isolation between logical datapaths. | |
09986f8c JP |
389 | (The logical flow abstraction also allows the OVN centralized |
390 | components to do less work, since they do not have to separately | |
391 | compute and push out physical flows to each chassis.) | |
fe36184b BP |
392 | </p> |
393 | ||
394 | <p> | |
395 | The default action when no flow matches is to drop packets. | |
396 | </p> | |
397 | ||
69a832cf | 398 | <p><em>Architectural Logical Life Cycle of a Packet</em></p> |
5868eb24 BP |
399 | |
400 | <p> | |
401 | This following description focuses on the life cycle of a packet through | |
402 | a logical datapath, ignoring physical details of the implementation. | |
69a832cf | 403 | Please refer to <em>Architectural Physical Life Cycle of a Packet</em> in |
5868eb24 BP |
404 | <code>ovn-architecture</code>(7) for the physical information. |
405 | </p> | |
406 | ||
407 | <p> | |
408 | The description here is written as if OVN itself executes these steps, | |
409 | but in fact OVN (that is, <code>ovn-controller</code>) programs Open | |
410 | vSwitch, via OpenFlow and OVSDB, to execute them on its behalf. | |
411 | </p> | |
412 | ||
413 | <p> | |
414 | At a high level, OVN passes each packet through the logical datapath's | |
415 | logical ingress pipeline, which may output the packet to one or more | |
416 | logical port or logical multicast groups. For each such logical output | |
417 | port, OVN passes the packet through the datapath's logical egress | |
418 | pipeline, which may either drop the packet or deliver it to the | |
419 | destination. Between the two pipelines, outputs to logical multicast | |
420 | groups are expanded into logical ports, so that the egress pipeline only | |
421 | processes a single logical output port at a time. Between the two | |
422 | pipelines is also where, when necessary, OVN encapsulates a packet in a | |
423 | tunnel (or tunnels) to transmit to remote hypervisors. | |
424 | </p> | |
425 | ||
426 | <p> | |
427 | In more detail, to start, OVN searches the <ref table="Logical_Flow"/> | |
428 | table for a row with correct <ref column="logical_datapath"/>, a <ref | |
429 | column="pipeline"/> of <code>ingress</code>, a <ref column="table_id"/> | |
430 | of 0, and a <ref column="match"/> that is true for the packet. If none | |
431 | is found, OVN drops the packet. If OVN finds more than one, it chooses | |
432 | the match with the highest <ref column="priority"/>. Then OVN executes | |
433 | each of the actions specified in the row's <ref table="actions"/> column, | |
434 | in the order specified. Some actions, such as those to modify packet | |
435 | headers, require no further details. The <code>next</code> and | |
436 | <code>output</code> actions are special. | |
437 | </p> | |
438 | ||
439 | <p> | |
440 | The <code>next</code> action causes the above process to be repeated | |
441 | recursively, except that OVN searches for <ref column="table_id"/> of 1 | |
442 | instead of 0. Similarly, any <code>next</code> action in a row found in | |
443 | that table would cause a further search for a <ref column="table_id"/> of | |
444 | 2, and so on. When recursive processing completes, flow control returns | |
445 | to the action following <code>next</code>. | |
446 | </p> | |
447 | ||
448 | <p> | |
449 | The <code>output</code> action also introduces recursion. Its effect | |
450 | depends on the current value of the <code>outport</code> field. Suppose | |
451 | <code>outport</code> designates a logical port. First, OVN compares | |
452 | <code>inport</code> to <code>outport</code>; if they are equal, it treats | |
bf143492 JP |
453 | the <code>output</code> as a no-op by default. In the common |
454 | case, where they are different, the packet enters the egress | |
455 | pipeline. This transition to the egress pipeline discards | |
456 | register data, e.g. <code>reg0</code> ... <code>reg9</code> and | |
457 | connection tracking state, to achieve uniform behavior regardless | |
458 | of whether the egress pipeline is on a different hypervisor | |
459 | (because registers aren't preserve across tunnel encapsulation). | |
5868eb24 BP |
460 | </p> |
461 | ||
462 | <p> | |
463 | To execute the egress pipeline, OVN again searches the <ref | |
464 | table="Logical_Flow"/> table for a row with correct <ref | |
465 | column="logical_datapath"/>, a <ref column="table_id"/> of 0, a <ref | |
466 | column="match"/> that is true for the packet, but now looking for a <ref | |
467 | column="pipeline"/> of <code>egress</code>. If no matching row is found, | |
468 | the output becomes a no-op. Otherwise, OVN executes the actions for the | |
469 | matching flow (which is chosen from multiple, if necessary, as already | |
470 | described). | |
471 | </p> | |
472 | ||
473 | <p> | |
474 | In the <code>egress</code> pipeline, the <code>next</code> action acts as | |
475 | already described, except that it, of course, searches for | |
476 | <code>egress</code> flows. The <code>output</code> action, however, now | |
477 | directly outputs the packet to the output port (which is now fixed, | |
478 | because <code>outport</code> is read-only within the egress pipeline). | |
479 | </p> | |
480 | ||
481 | <p> | |
482 | The description earlier assumed that <code>outport</code> referred to a | |
483 | logical port. If it instead designates a logical multicast group, then | |
484 | the description above still applies, with the addition of fan-out from | |
485 | the logical multicast group to each logical port in the group. For each | |
486 | member of the group, OVN executes the logical pipeline as described, with | |
487 | the logical output port replaced by the group member. | |
488 | </p> | |
489 | ||
8d6e5516 JP |
490 | <p><em>Pipeline Stages</em></p> |
491 | ||
492 | <p> | |
398be42b BP |
493 | <code>ovn-northd</code> populates the <ref table="Logical_Flow"/> table |
494 | with the logical flows described in detail in <code>ovn-northd</code>(8). | |
8d6e5516 JP |
495 | </p> |
496 | ||
747b2a45 | 497 | <column name="logical_datapath"> |
5868eb24 BP |
498 | The logical datapath to which the logical flow belongs. |
499 | </column> | |
500 | ||
501 | <column name="pipeline"> | |
502 | <p> | |
503 | The primary flows used for deciding on a packet's destination are the | |
504 | <code>ingress</code> flows. The <code>egress</code> flows implement | |
505 | ACLs. See <em>Logical Life Cycle of a Packet</em>, above, for details. | |
506 | </p> | |
747b2a45 BP |
507 | </column> |
508 | ||
fe36184b BP |
509 | <column name="table_id"> |
510 | The stage in the logical pipeline, analogous to an OpenFlow table number. | |
511 | </column> | |
512 | ||
513 | <column name="priority"> | |
514 | The flow's priority. Flows with numerically higher priority take | |
515 | precedence over those with lower. If two logical datapath flows with the | |
516 | same priority both match, then the one actually applied to the packet is | |
517 | undefined. | |
518 | </column> | |
519 | ||
520 | <column name="match"> | |
521 | <p> | |
522 | A matching expression. OVN provides a superset of OpenFlow matching | |
523 | capabilities, using a syntax similar to Boolean expressions in a | |
524 | programming language. | |
525 | </p> | |
526 | ||
527 | <p> | |
fa6aeaeb RB |
528 | The most important components of match expression are |
529 | <dfn>comparisons</dfn> between <dfn>symbols</dfn> and | |
530 | <dfn>constants</dfn>, e.g. <code>ip4.dst == 192.168.0.1</code>, | |
531 | <code>ip.proto == 6</code>, <code>arp.op == 1</code>, <code>eth.type == | |
532 | 0x800</code>. The logical AND operator <code>&&</code> and | |
533 | logical OR operator <code>||</code> can combine comparisons into a | |
534 | larger expression. | |
fe36184b BP |
535 | </p> |
536 | ||
fe36184b | 537 | <p> |
e0840f11 BP |
538 | Matching expressions also support parentheses for grouping, the logical |
539 | NOT prefix operator <code>!</code>, and literals <code>0</code> and | |
540 | <code>1</code> to express ``false'' or ``true,'' respectively. The | |
541 | latter is useful by itself as a catch-all expression that matches every | |
542 | packet. | |
fe36184b BP |
543 | </p> |
544 | ||
ba8d3816 MS |
545 | <p> |
546 | Match expressions also support a kind of function syntax. The | |
547 | following functions are supported: | |
548 | </p> | |
549 | ||
550 | <dl> | |
551 | <dt><code>is_chassis_resident(<var>lport</var>)</code></dt> | |
552 | <dd> | |
553 | Evaluates to true on a chassis on which logical port <var>lport</var> | |
554 | (a quoted string) resides, and to false elsewhere. This function was | |
555 | introduced in OVN 2.7. | |
556 | </dd> | |
557 | </dl> | |
558 | ||
e0840f11 | 559 | <p><em>Symbols</em></p> |
fe36184b BP |
560 | |
561 | <p> | |
fa6aeaeb RB |
562 | <em>Type</em>. Symbols have <dfn>integer</dfn> or <dfn>string</dfn> |
563 | type. Integer symbols have a <dfn>width</dfn> in bits. | |
fe36184b BP |
564 | </p> |
565 | ||
566 | <p> | |
fa6aeaeb | 567 | <em>Kinds</em>. There are three kinds of symbols: |
fe36184b BP |
568 | </p> |
569 | ||
e0840f11 | 570 | <ul> |
fa6aeaeb RB |
571 | <li> |
572 | <p> | |
573 | <dfn>Fields</dfn>. A field symbol represents a packet header or | |
574 | metadata field. For example, a field | |
575 | named <code>vlan.tci</code> might represent the VLAN TCI field in a | |
576 | packet. | |
577 | </p> | |
578 | ||
579 | <p> | |
580 | A field symbol can have integer or string type. Integer fields can | |
581 | be nominal or ordinal (see <em>Level of Measurement</em>, | |
582 | below). | |
583 | </p> | |
584 | </li> | |
585 | ||
586 | <li> | |
587 | <p> | |
588 | <dfn>Subfields</dfn>. A subfield represents a subset of bits from | |
589 | a larger field. For example, a field <code>vlan.vid</code> might | |
590 | be defined as an alias for <code>vlan.tci[0..11]</code>. Subfields | |
591 | are provided for syntactic convenience, because it is always | |
592 | possible to instead refer to a subset of bits from a field | |
593 | directly. | |
594 | </p> | |
595 | ||
596 | <p> | |
597 | Only ordinal fields (see <em>Level of Measurement</em>, | |
598 | below) may have subfields. Subfields are always ordinal. | |
599 | </p> | |
600 | </li> | |
601 | ||
602 | <li> | |
603 | <p> | |
604 | <dfn>Predicates</dfn>. A predicate is shorthand for a Boolean | |
605 | expression. Predicates may be used much like 1-bit fields. For | |
606 | example, <code>ip4</code> might expand to <code>eth.type == | |
607 | 0x800</code>. Predicates are provided for syntactic convenience, | |
608 | because it is always possible to instead specify the underlying | |
609 | expression directly. | |
610 | </p> | |
611 | ||
612 | <p> | |
613 | A predicate whose expansion refers to any nominal field or | |
614 | predicate (see <em>Level of Measurement</em>, below) is nominal; | |
615 | other predicates have Boolean level of measurement. | |
616 | </p> | |
617 | </li> | |
e0840f11 BP |
618 | </ul> |
619 | ||
fe36184b | 620 | <p> |
fa6aeaeb RB |
621 | <em>Level of Measurement</em>. See |
622 | http://en.wikipedia.org/wiki/Level_of_measurement for the statistical | |
623 | concept on which this classification is based. There are three | |
624 | levels: | |
fe36184b BP |
625 | </p> |
626 | ||
627 | <ul> | |
fa6aeaeb RB |
628 | <li> |
629 | <p> | |
630 | <dfn>Ordinal</dfn>. In statistics, ordinal values can be ordered | |
631 | on a scale. OVN considers a field (or subfield) to be ordinal if | |
632 | its bits can be examined individually. This is true for the | |
633 | OpenFlow fields that OpenFlow or Open vSwitch makes ``maskable.'' | |
634 | </p> | |
635 | ||
636 | <p> | |
637 | Any use of a nominal field may specify a single bit or a range of | |
638 | bits, e.g. <code>vlan.tci[13..15]</code> refers to the PCP field | |
639 | within the VLAN TCI, and <code>eth.dst[40]</code> refers to the | |
640 | multicast bit in the Ethernet destination address. | |
641 | </p> | |
642 | ||
643 | <p> | |
644 | OVN supports all the usual arithmetic relations (<code>==</code>, | |
645 | <code>!=</code>, <code><</code>, <code><=</code>, | |
646 | <code>></code>, and <code>>=</code>) on ordinal fields and | |
647 | their subfields, because OVN can implement these in OpenFlow and | |
648 | Open vSwitch as collections of bitwise tests. | |
649 | </p> | |
650 | </li> | |
651 | ||
652 | <li> | |
653 | <p> | |
654 | <dfn>Nominal</dfn>. In statistics, nominal values cannot be | |
655 | usefully compared except for equality. This is true of OpenFlow | |
656 | port numbers, Ethernet types, and IP protocols are examples: all of | |
657 | these are just identifiers assigned arbitrarily with no deeper | |
658 | meaning. In OpenFlow and Open vSwitch, bits in these fields | |
659 | generally aren't individually addressable. | |
660 | </p> | |
661 | ||
662 | <p> | |
663 | OVN only supports arithmetic tests for equality on nominal fields, | |
664 | because OpenFlow and Open vSwitch provide no way for a flow to | |
665 | efficiently implement other comparisons on them. (A test for | |
666 | inequality can be sort of built out of two flows with different | |
667 | priorities, but OVN matching expressions always generate flows with | |
668 | a single priority.) | |
669 | </p> | |
670 | ||
671 | <p> | |
672 | String fields are always nominal. | |
673 | </p> | |
674 | </li> | |
675 | ||
676 | <li> | |
677 | <p> | |
678 | <dfn>Boolean</dfn>. A nominal field that has only two values, 0 | |
679 | and 1, is somewhat exceptional, since it is easy to support both | |
680 | equality and inequality tests on such a field: either one can be | |
681 | implemented as a test for 0 or 1. | |
682 | </p> | |
683 | ||
684 | <p> | |
685 | Only predicates (see above) have a Boolean level of measurement. | |
686 | </p> | |
687 | ||
688 | <p> | |
689 | This isn't a standard level of measurement. | |
690 | </p> | |
691 | </li> | |
fe36184b BP |
692 | </ul> |
693 | ||
694 | <p> | |
fa6aeaeb RB |
695 | <em>Prerequisites</em>. Any symbol can have prerequisites, which are |
696 | additional condition implied by the use of the symbol. For example, | |
697 | For example, <code>icmp4.type</code> symbol might have prerequisite | |
698 | <code>icmp4</code>, which would cause an expression <code>icmp4.type == | |
699 | 0</code> to be interpreted as <code>icmp4.type == 0 && | |
700 | icmp4</code>, which would in turn expand to <code>icmp4.type == 0 | |
701 | && eth.type == 0x800 && ip4.proto == 1</code> (assuming | |
702 | <code>icmp4</code> is a predicate defined as suggested under | |
703 | <em>Types</em> above). | |
fe36184b BP |
704 | </p> |
705 | ||
e0840f11 BP |
706 | <p><em>Relational operators</em></p> |
707 | ||
fe36184b | 708 | <p> |
fa6aeaeb RB |
709 | All of the standard relational operators <code>==</code>, |
710 | <code>!=</code>, <code><</code>, <code><=</code>, | |
711 | <code>></code>, and <code>>=</code> are supported. Nominal | |
712 | fields support only <code>==</code> and <code>!=</code>, and only in a | |
713 | positive sense when outer <code>!</code> are taken into account, | |
714 | e.g. given string field <code>inport</code>, <code>inport == | |
715 | "eth0"</code> and <code>!(inport != "eth0")</code> are acceptable, but | |
716 | not <code>inport != "eth0"</code>. | |
fe36184b BP |
717 | </p> |
718 | ||
719 | <p> | |
fa6aeaeb RB |
720 | The implementation of <code>==</code> (or <code>!=</code> when it is |
721 | negated), is more efficient than that of the other relational | |
722 | operators. | |
fe36184b BP |
723 | </p> |
724 | ||
e0840f11 BP |
725 | <p><em>Constants</em></p> |
726 | ||
fe36184b | 727 | <p> |
e0840f11 BP |
728 | Integer constants may be expressed in decimal, hexadecimal prefixed by |
729 | <code>0x</code>, or as dotted-quad IPv4 addresses, IPv6 addresses in | |
730 | their standard forms, or Ethernet addresses as colon-separated hex | |
731 | digits. A constant in any of these forms may be followed by a slash | |
732 | and a second constant (the mask) in the same form, to form a masked | |
733 | constant. IPv4 and IPv6 masks may be given as integers, to express | |
734 | CIDR prefixes. | |
735 | </p> | |
736 | ||
737 | <p> | |
738 | String constants have the same syntax as quoted strings in JSON (thus, | |
5868eb24 | 739 | they are Unicode strings). |
fe36184b BP |
740 | </p> |
741 | ||
742 | <p> | |
e0840f11 BP |
743 | Some operators support sets of constants written inside curly braces |
744 | <code>{</code> ... <code>}</code>. Commas between elements of a set, | |
745 | and after the last elements, are optional. With <code>==</code>, | |
746 | ``<code><var>field</var> == { <var>constant1</var>, | |
747 | <var>constant2</var>,</code> ... <code>}</code>'' is syntactic sugar | |
748 | for ``<code><var>field</var> == <var>constant1</var> || | |
749 | <var>field</var> == <var>constant2</var> || </code>...<code></code>. | |
750 | Similarly, ``<code><var>field</var> != { <var>constant1</var>, | |
751 | <var>constant2</var>, </code>...<code> }</code>'' is equivalent to | |
752 | ``<code><var>field</var> != <var>constant1</var> && | |
fe36184b | 753 | <var>field</var> != <var>constant2</var> && |
e0840f11 | 754 | </code>...<code></code>''. |
fe36184b BP |
755 | </p> |
756 | ||
ea382567 RB |
757 | <p> |
758 | You may refer to a set of IPv4, IPv6, or MAC addresses stored in the | |
759 | <ref table="Address_Set"/> table by its <ref column="name" | |
760 | table="Address_Set"/>. An <ref table="Address_Set"/> with a name | |
761 | of <code>set1</code> can be referred to as | |
762 | <code>$set1</code>. | |
763 | </p> | |
764 | ||
e0840f11 BP |
765 | <p><em>Miscellaneous</em></p> |
766 | ||
fe36184b | 767 | <p> |
fa6aeaeb RB |
768 | Comparisons may name the symbol or the constant first, |
769 | e.g. <code>tcp.src == 80</code> and <code>80 == tcp.src</code> are both | |
770 | acceptable. | |
fe36184b BP |
771 | </p> |
772 | ||
773 | <p> | |
fa6aeaeb RB |
774 | Tests for a range may be expressed using a syntax like <code>1024 <= |
775 | tcp.src <= 49151</code>, which is equivalent to <code>1024 <= | |
776 | tcp.src && tcp.src <= 49151</code>. | |
fe36184b BP |
777 | </p> |
778 | ||
779 | <p> | |
fa6aeaeb RB |
780 | For a one-bit field or predicate, a mention of its name is equivalent |
781 | to <code><var>symobl</var> == 1</code>, e.g. <code>vlan.present</code> | |
782 | is equivalent to <code>vlan.present == 1</code>. The same is true for | |
783 | one-bit subfields, e.g. <code>vlan.tci[12]</code>. There is no | |
784 | technical limitation to implementing the same for ordinal fields of all | |
785 | widths, but the implementation is expensive enough that the syntax | |
786 | parser requires writing an explicit comparison against zero to make | |
787 | mistakes less likely, e.g. in <code>tcp.src != 0</code> the comparison | |
788 | against 0 is required. | |
fe36184b BP |
789 | </p> |
790 | ||
791 | <p> | |
fa6aeaeb RB |
792 | <em>Operator precedence</em> is as shown below, from highest to lowest. |
793 | There are two exceptions where parentheses are required even though the | |
794 | table would suggest that they are not: <code>&&</code> and | |
795 | <code>||</code> require parentheses when used together, and | |
796 | <code>!</code> requires parentheses when applied to a relational | |
797 | expression. Thus, in <code>(eth.type == 0x800 || eth.type == 0x86dd) | |
798 | && ip.proto == 6</code> or <code>!(arp.op == 1)</code>, the | |
799 | parentheses are mandatory. | |
fe36184b BP |
800 | </p> |
801 | ||
e0840f11 BP |
802 | <ul> |
803 | <li><code>()</code></li> | |
804 | <li><code>== != < <= > >=</code></li> | |
805 | <li><code>!</code></li> | |
806 | <li><code>&& ||</code></li> | |
807 | </ul> | |
808 | ||
10b1662b BP |
809 | <p> |
810 | <em>Comments</em> may be introduced by <code>//</code>, which extends | |
811 | to the next new-line. Comments within a line may be bracketed by | |
812 | <code>/*</code> and <code>*/</code>. Multiline comments are not | |
813 | supported. | |
814 | </p> | |
815 | ||
e0840f11 BP |
816 | <p><em>Symbols</em></p> |
817 | ||
5868eb24 BP |
818 | <p> |
819 | Most of the symbols below have integer type. Only <code>inport</code> | |
820 | and <code>outport</code> have string type. <code>inport</code> names a | |
821 | logical port. Thus, its value is a <ref column="logical_port"/> name | |
62fdd819 AW |
822 | from the <ref table="Port_Binding"/> table. <code>outport</code> may |
823 | name a logical port, as <code>inport</code>, or a logical multicast | |
824 | group defined in the <ref table="Multicast_Group"/> table. For both | |
825 | symbols, only names within the flow's logical datapath may be used. | |
5868eb24 BP |
826 | </p> |
827 | ||
394e883d JP |
828 | <p> |
829 | The <code>reg</code><var>X</var> symbols are 32-bit integers. | |
830 | The <code>xxreg</code><var>X</var> symbols are 128-bit integers, | |
831 | which overlay four of the 32-bit registers: <code>xxreg0</code> | |
832 | overlays <code>reg0</code> through <code>reg3</code>, with | |
833 | <code>reg0</code> supplying the most-significant bits of | |
834 | <code>xxreg0</code> and <code>reg3</code> the least-signficant. | |
835 | <code>xxreg1</code> similarly overlays <code>reg4</code> through | |
836 | <code>reg7</code>. | |
837 | </p> | |
838 | ||
e0840f11 | 839 | <ul> |
cc5e28d8 | 840 | <li><code>reg0</code>...<code>reg9</code></li> |
394e883d | 841 | <li><code>xxreg0</code> <code>xxreg1</code></li> |
5868eb24 | 842 | <li><code>inport</code> <code>outport</code></li> |
bf143492 | 843 | <li><code>flags.loopback</code></li> |
e0840f11 BP |
844 | <li><code>eth.src</code> <code>eth.dst</code> <code>eth.type</code></li> |
845 | <li><code>vlan.tci</code> <code>vlan.vid</code> <code>vlan.pcp</code> <code>vlan.present</code></li> | |
846 | <li><code>ip.proto</code> <code>ip.dscp</code> <code>ip.ecn</code> <code>ip.ttl</code> <code>ip.frag</code></li> | |
847 | <li><code>ip4.src</code> <code>ip4.dst</code></li> | |
848 | <li><code>ip6.src</code> <code>ip6.dst</code> <code>ip6.label</code></li> | |
849 | <li><code>arp.op</code> <code>arp.spa</code> <code>arp.tpa</code> <code>arp.sha</code> <code>arp.tha</code></li> | |
850 | <li><code>tcp.src</code> <code>tcp.dst</code> <code>tcp.flags</code></li> | |
851 | <li><code>udp.src</code> <code>udp.dst</code></li> | |
852 | <li><code>sctp.src</code> <code>sctp.dst</code></li> | |
853 | <li><code>icmp4.type</code> <code>icmp4.code</code></li> | |
854 | <li><code>icmp6.type</code> <code>icmp6.code</code></li> | |
855 | <li><code>nd.target</code> <code>nd.sll</code> <code>nd.tll</code></li> | |
e3d81ade | 856 | <li><code>ct_mark</code> <code>ct_label</code></li> |
78aab811 JP |
857 | <li> |
858 | <p> | |
a96d26d7 BP |
859 | <code>ct_state</code>, which has several Boolean subfields. The |
860 | <code>ct_next</code> action initializes the following subfields: | |
78aab811 JP |
861 | </p> |
862 | <ul> | |
a96d26d7 BP |
863 | <li> |
864 | <code>ct.trk</code>: Always set to true by <code>ct_next</code> | |
865 | to indicate that connection tracking has taken place. All other | |
866 | <code>ct</code> subfields have <code>ct.trk</code> as a | |
867 | prerequisite. | |
868 | </li> | |
78aab811 JP |
869 | <li><code>ct.new</code>: True for a new flow</li> |
870 | <li><code>ct.est</code>: True for an established flow</li> | |
871 | <li><code>ct.rel</code>: True for a related flow</li> | |
872 | <li><code>ct.rpl</code>: True for a reply flow</li> | |
873 | <li><code>ct.inv</code>: True for a connection entry in a bad state</li> | |
874 | </ul> | |
875 | <p> | |
a96d26d7 BP |
876 | The <code>ct_dnat</code>, <code>ct_snat</code>, and |
877 | <code>ct_lb</code> actions initialize the following subfields: | |
858c2f76 GS |
878 | </p> |
879 | <ul> | |
880 | <li> | |
881 | <code>ct.dnat</code>: True for a packet whose destination IP | |
882 | address has been changed. | |
883 | </li> | |
884 | <li> | |
885 | <code>ct.snat</code>: True for a packet whose source IP | |
886 | address has been changed. | |
887 | </li> | |
888 | </ul> | |
78aab811 | 889 | </li> |
e0840f11 BP |
890 | </ul> |
891 | ||
25030d47 RB |
892 | <p> |
893 | The following predicates are supported: | |
894 | </p> | |
895 | ||
896 | <ul> | |
a2011117 BP |
897 | <li><code>eth.bcast</code> expands to <code>eth.dst == ff:ff:ff:ff:ff:ff</code></li> |
898 | <li><code>eth.mcast</code> expands to <code>eth.dst[40]</code></li> | |
25030d47 RB |
899 | <li><code>vlan.present</code> expands to <code>vlan.tci[12]</code></li> |
900 | <li><code>ip4</code> expands to <code>eth.type == 0x800</code></li> | |
a2011117 | 901 | <li><code>ip4.mcast</code> expands to <code>ip4.dst[28..31] == 0xe</code></li> |
25030d47 RB |
902 | <li><code>ip6</code> expands to <code>eth.type == 0x86dd</code></li> |
903 | <li><code>ip</code> expands to <code>ip4 || ip6</code></li> | |
904 | <li><code>icmp4</code> expands to <code>ip4 && ip.proto == 1</code></li> | |
905 | <li><code>icmp6</code> expands to <code>ip6 && ip.proto == 58</code></li> | |
906 | <li><code>icmp</code> expands to <code>icmp4 || icmp6</code></li> | |
907 | <li><code>ip.is_frag</code> expands to <code>ip.frag[0]</code></li> | |
908 | <li><code>ip.later_frag</code> expands to <code>ip.frag[1]</code></li> | |
909 | <li><code>ip.first_frag</code> expands to <code>ip.is_frag && !ip.later_frag</code></li> | |
910 | <li><code>arp</code> expands to <code>eth.type == 0x806</code></li> | |
acdd9220 JP |
911 | <li><code>nd</code> expands to <code>icmp6.type == {135, 136} && icmp6.code == 0 && ip.ttl == 255</code></li> |
912 | <li><code>nd_ns</code> expands to <code>icmp6.type == 135 && icmp6.code == 0 && ip.ttl == 255</code></li> | |
913 | <li><code>nd_na</code> expands to <code>icmp6.type == 136 && icmp6.code == 0 && ip.ttl == 255</code></li> | |
25030d47 RB |
914 | <li><code>tcp</code> expands to <code>ip.proto == 6</code></li> |
915 | <li><code>udp</code> expands to <code>ip.proto == 17</code></li> | |
916 | <li><code>sctp</code> expands to <code>ip.proto == 132</code></li> | |
917 | </ul> | |
fe36184b BP |
918 | </column> |
919 | ||
920 | <column name="actions"> | |
921 | <p> | |
2cd87fce RB |
922 | Logical datapath actions, to be executed when the logical flow |
923 | represented by this row is the highest-priority match. | |
fe36184b BP |
924 | </p> |
925 | ||
35060cdc | 926 | <p> |
2cd87fce RB |
927 | Actions share lexical syntax with the <ref column="match"/> column. An |
928 | empty set of actions (or one that contains just white space or | |
929 | comments), or a set of actions that consists of just | |
930 | <code>drop;</code>, causes the matched packets to be dropped. | |
931 | Otherwise, the column should contain a sequence of actions, each | |
932 | terminated by a semicolon. | |
35060cdc | 933 | </p> |
fe36184b | 934 | |
35060cdc | 935 | <p> |
eee7a8ed | 936 | The following actions are defined: |
35060cdc | 937 | </p> |
fe36184b | 938 | |
35060cdc BP |
939 | <dl> |
940 | <dt><code>output;</code></dt> | |
941 | <dd> | |
5868eb24 | 942 | <p> |
eee7a8ed JP |
943 | In the ingress pipeline, this action executes the |
944 | <code>egress</code> pipeline as a subroutine. If | |
945 | <code>outport</code> names a logical port, the egress pipeline | |
946 | executes once; if it is a multicast group, the egress pipeline runs | |
947 | once for each logical port in the group. | |
5868eb24 BP |
948 | </p> |
949 | ||
950 | <p> | |
951 | In the egress pipeline, this action performs the actual | |
952 | output to the <code>outport</code> logical port. (In the egress | |
953 | pipeline, <code>outport</code> never names a multicast group.) | |
954 | </p> | |
955 | ||
956 | <p> | |
bf143492 JP |
957 | By default, output to the input port is implicitly dropped, |
958 | that is, <code>output</code> becomes a no-op if | |
959 | <code>outport</code> == <code>inport</code>. Occasionally | |
960 | it may be useful to override this behavior, e.g. to send an | |
961 | ARP reply to an ARP request; to do so, use | |
962 | <code>flags.loopback = 1</code> to allow the packet to | |
963 | "hair-pin" back to the input port. | |
5868eb24 | 964 | </p> |
eee7a8ed | 965 | </dd> |
fe36184b | 966 | |
35060cdc | 967 | <dt><code>next;</code></dt> |
558ec83d | 968 | <dt><code>next(<var>table</var>);</code></dt> |
4c99cb18 | 969 | <dt><code>next(pipeline=<var>pipeline</var>, table=<var>table</var>);</code></dt> |
35060cdc | 970 | <dd> |
4c99cb18 BP |
971 | Executes the given logical datapath <var>table</var> in |
972 | <var>pipeline</var> as a subroutine. The default <var>table</var> is | |
973 | just after the current one. If <var>pipeline</var> is specified, it | |
974 | may be <code>ingress</code> or <code>egress</code>; the default | |
975 | <var>pipeline</var> is the one currently executing. Actions in the | |
976 | ingress pipeline may not use <code>next</code> to jump into the | |
977 | egress pipeline (use the <code>output</code> instead), but | |
978 | transitions in the opposite direction are allowed. | |
2cd87fce | 979 | </dd> |
fe36184b | 980 | |
35060cdc BP |
981 | <dt><code><var>field</var> = <var>constant</var>;</code></dt> |
982 | <dd> | |
5868eb24 | 983 | <p> |
5ee054fb BP |
984 | Sets data or metadata field <var>field</var> to constant value |
985 | <var>constant</var>, e.g. <code>outport = "vif0";</code> to set the | |
986 | logical output port. To set only a subset of bits in a field, | |
987 | specify a subfield for <var>field</var> or a masked | |
988 | <var>constant</var>, e.g. one may use <code>vlan.pcp[2] = 1;</code> | |
989 | or <code>vlan.pcp = 4/4;</code> to set the most sigificant bit of | |
990 | the VLAN PCP. | |
5868eb24 BP |
991 | </p> |
992 | ||
993 | <p> | |
994 | Assigning to a field with prerequisites implicitly adds those | |
995 | prerequisites to <ref column="match"/>; thus, for example, a flow | |
996 | that sets <code>tcp.dst</code> applies only to TCP flows, | |
997 | regardless of whether its <ref column="match"/> mentions any TCP | |
998 | field. | |
999 | </p> | |
1000 | ||
1001 | <p> | |
1002 | Not all fields are modifiable (e.g. <code>eth.type</code> and | |
1003 | <code>ip.proto</code> are read-only), and not all modifiable fields | |
1004 | may be partially modified (e.g. <code>ip.ttl</code> must assigned | |
1005 | as a whole). The <code>outport</code> field is modifiable in the | |
1006 | <code>ingress</code> pipeline but not in the <code>egress</code> | |
1007 | pipeline. | |
1008 | </p> | |
eee7a8ed | 1009 | </dd> |
5ee054fb BP |
1010 | |
1011 | <dt><code><var>field1</var> = <var>field2</var>;</code></dt> | |
1012 | <dd> | |
1013 | <p> | |
1014 | Sets data or metadata field <var>field1</var> to the value of data | |
1015 | or metadata field <var>field2</var>, e.g. <code>reg0 = | |
1016 | ip4.src;</code> copies <code>ip4.src</code> into <code>reg0</code>. | |
1017 | To modify only a subset of a field's bits, specify a subfield for | |
1018 | <var>field1</var> or <var>field2</var> or both, e.g. <code>vlan.pcp | |
1019 | = reg0[0..2];</code> copies the least-significant bits of | |
1020 | <code>reg0</code> into the VLAN PCP. | |
1021 | </p> | |
1022 | ||
1023 | <p> | |
1024 | <var>field1</var> and <var>field2</var> must be the same type, | |
1025 | either both string or both integer fields. If they are both | |
1026 | integer fields, they must have the same width. | |
1027 | </p> | |
1028 | ||
1029 | <p> | |
1030 | If <var>field1</var> or <var>field2</var> has prerequisites, they | |
1031 | are added implicitly to <ref column="match"/>. It is possible to | |
1032 | write an assignment with contradictory prerequisites, such as | |
1033 | <code>ip4.src = ip6.src[0..31];</code>, but the contradiction means | |
1034 | that a logical flow with such an assignment will never be matched. | |
1035 | </p> | |
1036 | </dd> | |
a20c96c6 BP |
1037 | |
1038 | <dt><code><var>field1</var> <-> <var>field2</var>;</code></dt> | |
1039 | <dd> | |
1040 | <p> | |
1041 | Similar to <code><var>field1</var> = <var>field2</var>;</code> | |
1042 | except that the two values are exchanged instead of copied. Both | |
1043 | <var>field1</var> and <var>field2</var> must modifiable. | |
1044 | </p> | |
1045 | </dd> | |
78aab811 | 1046 | |
00ea19e4 BP |
1047 | <dt><code>ip.ttl--;</code></dt> |
1048 | <dd> | |
1049 | <p> | |
1050 | Decrements the IPv4 or IPv6 TTL. If this would make the TTL zero | |
1051 | or negative, then processing of the packet halts; no further | |
1052 | actions are processed. (To properly handle such cases, a | |
4c20b9f2 JP |
1053 | higher-priority flow should match on |
1054 | <code>ip.ttl == {0, 1};</code>.) | |
00ea19e4 BP |
1055 | </p> |
1056 | ||
1057 | <p><b>Prerequisite:</b> <code>ip</code></p> | |
1058 | </dd> | |
1059 | ||
78aab811 JP |
1060 | <dt><code>ct_next;</code></dt> |
1061 | <dd> | |
1062 | <p> | |
1063 | Apply connection tracking to the flow, initializing | |
1064 | <code>ct_state</code> for matching in later tables. | |
1065 | Automatically moves on to the next table, as if followed by | |
1066 | <code>next</code>. | |
1067 | </p> | |
1068 | ||
1069 | <p> | |
1070 | As a side effect, IP fragments will be reassembled for matching. | |
1071 | If a fragmented packet is output, then it will be sent with any | |
1072 | overlapping fragments squashed. The connection tracking state is | |
d7039b9a GS |
1073 | scoped by the logical port when the action is used in a flow for |
1074 | a logical switch, so overlapping addresses may be used. To allow | |
1075 | traffic related to the matched flow, execute <code>ct_commit | |
1076 | </code>. Connection tracking state is scoped by the logical | |
1077 | topology when the action is used in a flow for a router. | |
78aab811 JP |
1078 | </p> |
1079 | ||
1080 | <p> | |
1081 | It is possible to have actions follow <code>ct_next</code>, | |
1082 | but they will not have access to any of its side-effects and | |
1083 | is not generally useful. | |
1084 | </p> | |
1085 | </dd> | |
1086 | ||
1087 | <dt><code>ct_commit;</code></dt> | |
a9e1b66f RB |
1088 | <dt><code>ct_commit(ct_mark=<var>value[/mask]</var>);</code></dt> |
1089 | <dt><code>ct_commit(ct_label=<var>value[/mask]</var>);</code></dt> | |
1090 | <dt><code>ct_commit(ct_mark=<var>value[/mask]</var>, ct_label=<var>value[/mask]</var>);</code></dt> | |
78aab811 | 1091 | <dd> |
c4623bb8 | 1092 | <p> |
a9e1b66f RB |
1093 | Commit the flow to the connection tracking entry associated with it |
1094 | by a previous call to <code>ct_next</code>. When | |
1095 | <code>ct_mark=<var>value[/mask]</var></code> and/or | |
1096 | <code>ct_label=<var>value[/mask]</var></code> are supplied, | |
1097 | <code>ct_mark</code> and/or <code>ct_label</code> will be set to the | |
1098 | values indicated by <var>value[/mask]</var> on the connection | |
1099 | tracking entry. <code>ct_mark</code> is a 32-bit field. | |
354b8f27 NS |
1100 | <code>ct_label</code> is a 128-bit field. The <var>value[/mask]</var> |
1101 | should be specified in hex string if more than 64bits are to be used. | |
c4623bb8 | 1102 | </p> |
a9e1b66f | 1103 | |
c4623bb8 RB |
1104 | <p> |
1105 | Note that if you want processing to continue in the next table, | |
1106 | you must execute the <code>next</code> action after | |
a9e1b66f RB |
1107 | <code>ct_commit</code>. You may also leave out <code>next</code> |
1108 | which will commit connection tracking state, and then drop the | |
1109 | packet. This could be useful for setting <code>ct_mark</code> | |
1110 | on a connection tracking entry before dropping a packet, | |
1111 | for example. | |
c4623bb8 | 1112 | </p> |
78aab811 | 1113 | </dd> |
fe36184b | 1114 | |
de297547 GS |
1115 | <dt><code>ct_dnat;</code></dt> |
1116 | <dt><code>ct_dnat(<var>IP</var>);</code></dt> | |
1117 | <dd> | |
1118 | <p> | |
1119 | <code>ct_dnat</code> sends the packet through the DNAT zone in | |
1120 | connection tracking table to unDNAT any packet that was DNATed in | |
1121 | the opposite direction. The packet is then automatically sent to | |
1122 | to the next tables as if followed by <code>next;</code> action. | |
1123 | The next tables will see the changes in the packet caused by | |
1124 | the connection tracker. | |
1125 | </p> | |
1126 | <p> | |
1127 | <code>ct_dnat(<var>IP</var>)</code> sends the packet through the | |
1128 | DNAT zone to change the destination IP address of the packet to | |
467085fd | 1129 | the one provided inside the parentheses and commits the connection. |
de297547 GS |
1130 | The packet is then automatically sent to the next tables as if |
1131 | followed by <code>next;</code> action. The next tables will see | |
1132 | the changes in the packet caused by the connection tracker. | |
1133 | </p> | |
1134 | </dd> | |
1135 | ||
1136 | <dt><code>ct_snat;</code></dt> | |
1137 | <dt><code>ct_snat(<var>IP</var>);</code></dt> | |
1138 | <dd> | |
1139 | <p> | |
1140 | <code>ct_snat</code> sends the packet through the SNAT zone to | |
1b441300 MS |
1141 | unSNAT any packet that was SNATed in the opposite direction. The |
1142 | behavior on gateway routers differs from the behavior on a | |
1143 | distributed router: | |
de297547 | 1144 | </p> |
1b441300 MS |
1145 | <ul> |
1146 | <li> | |
1147 | On a gateway router, if the packet needs to be sent to the next | |
1148 | tables, then it should be followed by a <code>next;</code> | |
1149 | action. The next tables will not see the changes in the packet | |
1150 | caused by the connection tracker. | |
1151 | </li> | |
1152 | <li> | |
1153 | On a distributed router, if the connection tracker finds a | |
1154 | connection that was SNATed in the opposite direction, then the | |
1155 | destination IP address of the packet is UNSNATed. The packet is | |
1156 | automatically sent to the next tables as if followed by the | |
1157 | <code>next;</code> action. The next tables will see the changes | |
1158 | in the packet caused by the connection tracker. | |
1159 | </li> | |
1160 | </ul> | |
de297547 GS |
1161 | <p> |
1162 | <code>ct_snat(<var>IP</var>)</code> sends the packet through the | |
1163 | SNAT zone to change the source IP address of the packet to | |
1164 | the one provided inside the parenthesis and commits the connection. | |
1165 | The packet is then automatically sent to the next tables as if | |
1166 | followed by <code>next;</code> action. The next tables will see the | |
1167 | changes in the packet caused by the connection tracker. | |
1168 | </p> | |
1169 | </dd> | |
1170 | ||
db0e819b BP |
1171 | <dt><code>ct_clear;</code></dt> |
1172 | <dd> | |
1173 | Clears connection tracking state. | |
1174 | </dd> | |
b3bd2c33 BP |
1175 | |
1176 | <dt><code>clone { <var>action</var>; </code>...<code> };</code></dt> | |
1177 | <dd> | |
1178 | Makes a copy of the packet being processed and executes each | |
1179 | <code>action</code> on the copy. Actions following the | |
1180 | <var>clone</var> action, if any, apply to the original, unmodified | |
1181 | packet. This can be used as a way to ``save and restore'' the packet | |
1182 | around a set of actions that may modify it and should not persist. | |
1183 | </dd> | |
1184 | ||
69a832cf BP |
1185 | <dt><code>arp { <var>action</var>; </code>...<code> };</code></dt> |
1186 | <dd> | |
1187 | <p> | |
1188 | Temporarily replaces the IPv4 packet being processed by an ARP | |
1189 | packet and executes each nested <var>action</var> on the ARP | |
1190 | packet. Actions following the <var>arp</var> action, if any, apply | |
1191 | to the original, unmodified packet. | |
1192 | </p> | |
1193 | ||
1194 | <p> | |
1195 | The ARP packet that this action operates on is initialized based on | |
1196 | the IPv4 packet being processed, as follows. These are default | |
1197 | values that the nested actions will probably want to change: | |
1198 | </p> | |
1199 | ||
1200 | <ul> | |
1201 | <li><code>eth.src</code> unchanged</li> | |
1202 | <li><code>eth.dst</code> unchanged</li> | |
1203 | <li><code>eth.type = 0x0806</code></li> | |
1204 | <li><code>arp.op = 1</code> (ARP request)</li> | |
1205 | <li><code>arp.sha</code> copied from <code>eth.src</code></li> | |
1206 | <li><code>arp.spa</code> copied from <code>ip4.src</code></li> | |
1207 | <li><code>arp.tha = 00:00:00:00:00:00</code></li> | |
1208 | <li><code>arp.tpa</code> copied from <code>ip4.dst</code></li> | |
1209 | </ul> | |
1210 | ||
6335d074 BP |
1211 | <p> |
1212 | The ARP packet has the same VLAN header, if any, as the IP packet | |
1213 | it replaces. | |
1214 | </p> | |
1215 | ||
69a832cf BP |
1216 | <p><b>Prerequisite:</b> <code>ip4</code></p> |
1217 | </dd> | |
1218 | ||
c34a87b6 JP |
1219 | <dt><code>get_arp(<var>P</var>, <var>A</var>);</code></dt> |
1220 | ||
1221 | <dd> | |
1222 | <p> | |
1223 | <b>Parameters</b>: logical port string field <var>P</var>, 32-bit | |
1224 | IP address field <var>A</var>. | |
1225 | </p> | |
1226 | ||
1227 | <p> | |
1228 | Looks up <var>A</var> in <var>P</var>'s mac binding table. | |
1229 | If an entry is found, stores its Ethernet address in | |
1230 | <code>eth.dst</code>, otherwise stores | |
1231 | <code>00:00:00:00:00:00</code> in <code>eth.dst</code>. | |
1232 | </p> | |
1233 | ||
1234 | <p><b>Example:</b> <code>get_arp(outport, ip4.dst);</code></p> | |
1235 | </dd> | |
1236 | ||
1237 | <dt> | |
1238 | <code>put_arp(<var>P</var>, <var>A</var>, <var>E</var>);</code> | |
1239 | </dt> | |
1240 | ||
1241 | <dd> | |
1242 | <p> | |
1243 | <b>Parameters</b>: logical port string field <var>P</var>, 32-bit | |
1244 | IP address field <var>A</var>, 48-bit Ethernet address field | |
1245 | <var>E</var>. | |
1246 | </p> | |
1247 | ||
1248 | <p> | |
1249 | Adds or updates the entry for IP address <var>A</var> in | |
1250 | logical port <var>P</var>'s mac binding table, setting its | |
1251 | Ethernet address to <var>E</var>. | |
1252 | </p> | |
1253 | ||
1254 | <p><b>Example:</b> <code>put_arp(inport, arp.spa, arp.sha);</code></p> | |
1255 | </dd> | |
1256 | ||
e75451fe | 1257 | <dt> |
f8a8db39 | 1258 | <code>nd_na { <var>action</var>; </code>...<code> };</code> |
e75451fe ZKL |
1259 | </dt> |
1260 | ||
1261 | <dd> | |
1262 | <p> | |
f8a8db39 JP |
1263 | Temporarily replaces the IPv6 neighbor solicitation packet |
1264 | being processed by an IPv6 neighbor advertisement (NA) | |
1265 | packet and executes each nested <var>action</var> on the NA | |
1266 | packet. Actions following the <code>nd_na</code> action, | |
1267 | if any, apply to the original, unmodified packet. | |
e75451fe ZKL |
1268 | </p> |
1269 | ||
1270 | <p> | |
1271 | The NA packet that this action operates on is initialized based on | |
1272 | the IPv6 packet being processed, as follows. These are default | |
1273 | values that the nested actions will probably want to change: | |
1274 | </p> | |
1275 | ||
1276 | <ul> | |
1277 | <li><code>eth.dst</code> exchanged with <code>eth.src</code></li> | |
1278 | <li><code>eth.type = 0x86dd</code></li> | |
1279 | <li><code>ip6.dst</code> copied from <code>ip6.src</code></li> | |
1280 | <li><code>ip6.src</code> copied from <code>nd.target</code></li> | |
1281 | <li><code>icmp6.type = 136</code> (Neighbor Advertisement)</li> | |
1282 | <li><code>nd.target</code> unchanged</li> | |
1283 | <li><code>nd.sll = 00:00:00:00:00:00</code></li> | |
1284 | <li><code>nd.tll</code> copied from <code>eth.dst</code></li> | |
1285 | </ul> | |
1286 | ||
1287 | <p> | |
1288 | The ND packet has the same VLAN header, if any, as the IPv6 packet | |
1289 | it replaces. | |
1290 | </p> | |
1291 | ||
1292 | <p> | |
f8a8db39 | 1293 | <b>Prerequisite:</b> <code>nd_ns</code> |
e75451fe ZKL |
1294 | </p> |
1295 | </dd> | |
1296 | ||
c34a87b6 | 1297 | <dt><code>get_nd(<var>P</var>, <var>A</var>);</code></dt> |
0bac7164 BP |
1298 | |
1299 | <dd> | |
1300 | <p> | |
c34a87b6 JP |
1301 | <b>Parameters</b>: logical port string field <var>P</var>, 128-bit |
1302 | IPv6 address field <var>A</var>. | |
0bac7164 BP |
1303 | </p> |
1304 | ||
1305 | <p> | |
c34a87b6 JP |
1306 | Looks up <var>A</var> in <var>P</var>'s mac binding table. |
1307 | If an entry is found, stores its Ethernet address in | |
1308 | <code>eth.dst</code>, otherwise stores | |
1309 | <code>00:00:00:00:00:00</code> in <code>eth.dst</code>. | |
0bac7164 BP |
1310 | </p> |
1311 | ||
c34a87b6 | 1312 | <p><b>Example:</b> <code>get_nd(outport, ip6.dst);</code></p> |
0bac7164 BP |
1313 | </dd> |
1314 | ||
1315 | <dt> | |
c34a87b6 | 1316 | <code>put_nd(<var>P</var>, <var>A</var>, <var>E</var>);</code> |
0bac7164 BP |
1317 | </dt> |
1318 | ||
1319 | <dd> | |
1320 | <p> | |
c34a87b6 JP |
1321 | <b>Parameters</b>: logical port string field <var>P</var>, |
1322 | 128-bit IPv6 address field <var>A</var>, 48-bit Ethernet | |
1323 | address field <var>E</var>. | |
0bac7164 BP |
1324 | </p> |
1325 | ||
1326 | <p> | |
c34a87b6 JP |
1327 | Adds or updates the entry for IPv6 address <var>A</var> in |
1328 | logical port <var>P</var>'s mac binding table, setting its | |
1329 | Ethernet address to <var>E</var>. | |
0bac7164 BP |
1330 | </p> |
1331 | ||
c34a87b6 | 1332 | <p><b>Example:</b> <code>put_nd(inport, nd.target, nd.tll);</code></p> |
0bac7164 | 1333 | </dd> |
42814145 NS |
1334 | |
1335 | <dt> | |
d5a76da4 | 1336 | <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> |
42814145 NS |
1337 | </dt> |
1338 | ||
1339 | <dd> | |
1340 | <p> | |
d5a76da4 BP |
1341 | <b>Parameters</b>: one or more DHCP option/value pairs, which must |
1342 | include an <code>offerip</code> option (with code 0). | |
42814145 NS |
1343 | </p> |
1344 | ||
1345 | <p> | |
1346 | <b>Result</b>: stored to a 1-bit subfield <var>R</var>. | |
1347 | </p> | |
1348 | ||
1349 | <p> | |
1350 | Valid only in the ingress pipeline. | |
1351 | </p> | |
1352 | ||
1353 | <p> | |
1354 | When this action is applied to a DHCP request packet (DHCPDISCOVER | |
1355 | or DHCPREQUEST), it changes the packet into a DHCP reply (DHCPOFFER | |
1356 | or DHCPACK, respectively), replaces the options by those specified | |
1357 | as parameters, and stores 1 in <var>R</var>. | |
1358 | </p> | |
1359 | ||
1360 | <p> | |
1361 | When this action is applied to a non-DHCP packet or a DHCP packet | |
1362 | that is not DHCPDISCOVER or DHCPREQUEST, it leaves the packet | |
1363 | unchanged and stores 0 in <var>R</var>. | |
1364 | </p> | |
1365 | ||
1366 | <p> | |
1367 | The contents of the <ref table="DHCP_Option"/> table control the | |
1368 | DHCP option names and values that this action supports. | |
1369 | </p> | |
1370 | ||
1371 | <p> | |
1372 | <b>Example:</b> | |
1373 | <code> | |
1374 | reg0[0] = put_dhcp_opts(offerip = 10.0.0.2, router = 10.0.0.1, | |
1375 | netmask = 255.255.255.0, dns_server = {8.8.8.8, 7.7.7.7}); | |
1376 | </code> | |
1377 | </p> | |
1378 | </dd> | |
467085fd | 1379 | |
01cfdb2f NS |
1380 | <dt> |
1381 | <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> | |
1382 | </dt> | |
1383 | ||
1384 | <dd> | |
1385 | <p> | |
1386 | <b>Parameters</b>: one or more DHCPv6 option/value pairs. | |
1387 | </p> | |
1388 | ||
1389 | <p> | |
1390 | <b>Result</b>: stored to a 1-bit subfield <var>R</var>. | |
1391 | </p> | |
1392 | ||
1393 | <p> | |
1394 | Valid only in the ingress pipeline. | |
1395 | </p> | |
1396 | ||
1397 | <p> | |
1398 | When this action is applied to a DHCPv6 request packet, it changes | |
1399 | the packet into a DHCPv6 reply, replaces the options by those | |
1400 | specified as parameters, and stores 1 in <var>R</var>. | |
1401 | </p> | |
1402 | ||
1403 | <p> | |
1404 | When this action is applied to a non-DHCPv6 packet or an invalid | |
1405 | DHCPv6 request packet , it leaves the packet unchanged and stores | |
1406 | 0 in <var>R</var>. | |
1407 | </p> | |
1408 | ||
1409 | <p> | |
1410 | The contents of the <ref table="DHCPv6_Options"/> table control the | |
1411 | DHCPv6 option names and values that this action supports. | |
1412 | </p> | |
1413 | ||
1414 | <p> | |
1415 | <b>Example:</b> | |
1416 | <code> | |
1417 | reg0[3] = put_dhcpv6_opts(ia_addr = aef0::4, server_id = 00:00:00:00:10:02, | |
1418 | dns_server={ae70::1,ae70::2}); | |
1419 | </code> | |
1420 | </p> | |
1421 | </dd> | |
1422 | ||
a6095f81 BS |
1423 | <dt> |
1424 | <code>set_queue(<var>queue_number</var>);</code> | |
1425 | </dt> | |
1426 | ||
1427 | <dd> | |
1428 | <p> | |
1429 | <b>Parameters</b>: Queue number <var>queue_number</var>, in the range 0 to 61440. | |
1430 | </p> | |
1431 | ||
1432 | <p> | |
1433 | This is a logical equivalent of the OpenFlow <code>set_queue</code> | |
1434 | action. It affects packets that egress a hypervisor through a | |
1435 | physical interface. For nonzero <var>queue_number</var>, it | |
1436 | configures packet queuing to match the settings configured for the | |
1437 | <ref table="Port_Binding"/> with | |
1438 | <code>options:qdisc_queue_id</code> matching | |
1439 | <var>queue_number</var>. When <var>queue_number</var> is zero, it | |
1440 | resets queuing to the default strategy. | |
1441 | </p> | |
1442 | ||
1443 | <p><b>Example:</b> <code>set_queue(10);</code></p> | |
1444 | </dd> | |
1445 | ||
467085fd GS |
1446 | <dt><code>ct_lb;</code></dt> |
1447 | <dt><code>ct_lb(</code><var>ip</var>[<code>:</code><var>port</var>]...<code>);</code></dt> | |
1448 | <dd> | |
1449 | <p> | |
1450 | With one or more arguments, <code>ct_lb</code> commits the packet | |
1451 | to the connection tracking table and DNATs the packet's destination | |
1452 | IP address (and port) to the IP address or addresses (and optional | |
1453 | ports) specified in the string. If multiple comma-separated IP | |
1454 | addresses are specified, each is given equal weight for picking the | |
1455 | DNAT address. Processing automatically moves on to the next table, | |
1456 | as if <code>next;</code> were specified, and later tables act on | |
1457 | the packet as modified by the connection tracker. Connection | |
c2e954a1 GS |
1458 | tracking state is scoped by the logical port when the action is |
1459 | used in a flow for a logical switch, so overlapping | |
1460 | addresses may be used. Connection tracking state is scoped by the | |
1461 | logical topology when the action is used in a flow for a router. | |
467085fd GS |
1462 | </p> |
1463 | <p> | |
1464 | Without arguments, <code>ct_lb</code> sends the packet to the | |
1465 | connection tracking table to NAT the packets. If the packet is | |
1466 | part of an established connection that was previously committed to | |
1467 | the connection tracker via <code>ct_lb(</code>...<code>)</code>, it | |
1468 | will automatically get DNATed to the same IP address as the first | |
1469 | packet in that connection. | |
1470 | </p> | |
1471 | </dd> | |
ea991ad2 NS |
1472 | |
1473 | <dt> | |
1474 | <code><var>R</var> = dns_lookup();</code> | |
1475 | </dt> | |
1476 | ||
1477 | <dd> | |
1478 | <p> | |
1479 | <b>Parameters</b>: No parameters. | |
1480 | </p> | |
1481 | ||
1482 | <p> | |
1483 | <b>Result</b>: stored to a 1-bit subfield <var>R</var>. | |
1484 | </p> | |
1485 | ||
1486 | <p> | |
1487 | Valid only in the ingress pipeline. | |
1488 | </p> | |
1489 | ||
1490 | <p> | |
1491 | When this action is applied to a valid DNS request (a UDP packet | |
1492 | typically directed to port 53), it attempts to resolve the query | |
1493 | using the contents of the <ref table="DNS"/> table. If it is | |
1494 | successful, it changes the packet into a DNS reply and stores 1 in | |
1495 | <var>R</var>. If the action is applied to a non-DNS packet, an | |
1496 | invalid DNS request packet, or a valid DNS request for which the | |
1497 | <ref table="DNS"/> table does not supply an answer, it leaves the | |
1498 | packet unchanged and stores 0 in <var>R</var>. | |
1499 | </p> | |
1500 | ||
1501 | <p> | |
1502 | Regardless of success, the action does not make any of the changes | |
1503 | to the flow that are necessary to direct the packet back to the | |
1504 | requester. The logical pipeline can implement this behavior with | |
1505 | matches and actions in later tables. | |
1506 | </p> | |
1507 | ||
1508 | <p> | |
1509 | <b>Example:</b> | |
1510 | <code> | |
1511 | reg0[3] = dns_lookup(); | |
1512 | </code> | |
1513 | </p> | |
1514 | ||
1515 | <p> | |
1516 | <b>Prerequisite:</b> <code>udp</code> | |
1517 | </p> | |
1518 | </dd> | |
6335d074 BP |
1519 | </dl> |
1520 | ||
d383eed5 JP |
1521 | <dl> |
1522 | <dt> | |
1523 | <code>log(<var>key</var>=<var>value</var>, </code>...<code>);</code> | |
1524 | </dt> | |
1525 | ||
1526 | <dd> | |
1527 | <p> | |
1528 | Causes <code>ovn-controller</code> to log the packet on the chassis | |
1529 | that processes it. Packet logging currently uses the same logging | |
1530 | mechanism as other Open vSwitch and OVN messages, which means that | |
1531 | whether and where log messages appear depends on the local logging | |
1532 | configuration that can be configured with <code>ovs-appctl</code>, | |
1533 | etc. | |
1534 | </p> | |
1535 | <p> | |
1536 | The <code>log</code> action takes zero or more of the following | |
1537 | key-value pair arguments that control what is logged: | |
1538 | </p> | |
1539 | <dl> | |
1540 | <dt><code>name=</code><var>string</var></dt> | |
1541 | <dd> | |
1542 | An optional name for the ACL. The <var>string</var> is | |
1543 | currently limited to 64 bytes. | |
1544 | </dd> | |
1545 | <dt><code>severity=</code><var>level</var></dt> | |
1546 | <dd> | |
1547 | Indicates the severity of the event. The <var>level</var> is one | |
1548 | of following (from more to less serious): <code>alert</code>, | |
1549 | <code>warning</code>, <code>notice</code>, <code>info</code>, or | |
1550 | <code>debug</code>. If a severity is not provided, the default | |
1551 | is <code>info</code>. | |
1552 | </dd> | |
1553 | <dt><code>verdict=</code><var>value</var></dt> | |
1554 | <dd> | |
1555 | The verdict for packets matching the flow. The value must be one | |
1556 | of <code>allow</code>, <code>deny</code>, or <code>reject</code>. | |
1557 | </dd> | |
1558 | </dl> | |
1559 | </dd> | |
1560 | </dl> | |
1561 | ||
6335d074 BP |
1562 | <p> |
1563 | The following actions will likely be useful later, but they have not | |
1564 | been thought out carefully. | |
1565 | </p> | |
1566 | ||
1567 | <dl> | |
69a832cf BP |
1568 | <dt><code>icmp4 { <var>action</var>; </code>...<code> };</code></dt> |
1569 | <dd> | |
1570 | <p> | |
1571 | Temporarily replaces the IPv4 packet being processed by an ICMPv4 | |
1572 | packet and executes each nested <var>action</var> on the ICMPv4 | |
1573 | packet. Actions following the <var>icmp4</var> action, if any, | |
1574 | apply to the original, unmodified packet. | |
1575 | </p> | |
1576 | ||
1577 | <p> | |
1578 | The ICMPv4 packet that this action operates on is initialized based | |
1579 | on the IPv4 packet being processed, as follows. These are default | |
1580 | values that the nested actions will probably want to change. | |
1581 | Ethernet and IPv4 fields not listed here are not changed: | |
1582 | </p> | |
1583 | ||
1584 | <ul> | |
1585 | <li><code>ip.proto = 1</code> (ICMPv4)</li> | |
1586 | <li><code>ip.frag = 0</code> (not a fragment)</li> | |
1587 | <li><code>icmp4.type = 3</code> (destination unreachable)</li> | |
1588 | <li><code>icmp4.code = 1</code> (host unreachable)</li> | |
1589 | </ul> | |
1590 | ||
1591 | <p> | |
1592 | Details TBD. | |
1593 | </p> | |
fe36184b | 1594 | |
69a832cf BP |
1595 | <p><b>Prerequisite:</b> <code>ip4</code></p> |
1596 | </dd> | |
1597 | ||
1598 | <dt><code>tcp_reset;</code></dt> | |
1599 | <dd> | |
1600 | <p> | |
1601 | This action transforms the current TCP packet according to the | |
1602 | following pseudocode: | |
1603 | </p> | |
1604 | ||
1605 | <pre> | |
1606 | if (tcp.ack) { | |
1607 | tcp.seq = tcp.ack; | |
1608 | } else { | |
1609 | tcp.ack = tcp.seq + length(tcp.payload); | |
1610 | tcp.seq = 0; | |
1611 | } | |
1612 | tcp.flags = RST; | |
1613 | </pre> | |
1614 | ||
1615 | <p> | |
1616 | Then, the action drops all TCP options and payload data, and | |
1617 | updates the TCP checksum. | |
1618 | </p> | |
1619 | ||
1620 | <p> | |
1621 | Details TBD. | |
1622 | </p> | |
1623 | ||
1624 | <p><b>Prerequisite:</b> <code>tcp</code></p> | |
1625 | </dd> | |
fe36184b | 1626 | </dl> |
fe36184b | 1627 | </column> |
091e3af9 JP |
1628 | |
1629 | <column name="external_ids" key="stage-name"> | |
1630 | Human-readable name for this flow's stage in the pipeline. | |
1631 | </column> | |
1632 | ||
17bfa2aa HZ |
1633 | <column name="external_ids" key="stage-hint" type='{"type": "uuid"}'> |
1634 | UUID of a <ref db="OVN_Northbound"/> record that caused this logical flow | |
1635 | to be created. Currently used only for attribute of logical flows to | |
1636 | northbound <ref db="OVN_Northbound" table="ACL"/> records. | |
1637 | </column> | |
1638 | ||
d8026bbf BP |
1639 | <column name="external_ids" key="source"> |
1640 | Source file and line number of the code that added this flow to the | |
1641 | pipeline. | |
1642 | </column> | |
1643 | ||
091e3af9 JP |
1644 | <group title="Common Columns"> |
1645 | The overall purpose of these columns is described under <code>Common | |
1646 | Columns</code> at the beginning of this document. | |
1647 | ||
1648 | <column name="external_ids"/> | |
1649 | </group> | |
fe36184b BP |
1650 | </table> |
1651 | ||
5868eb24 BP |
1652 | <table name="Multicast_Group" title="Logical Port Multicast Groups"> |
1653 | <p> | |
1654 | The rows in this table define multicast groups of logical ports. | |
1655 | Multicast groups allow a single packet transmitted over a tunnel to a | |
1656 | hypervisor to be delivered to multiple VMs on that hypervisor, which | |
1657 | uses bandwidth more efficiently. | |
1658 | </p> | |
1659 | ||
1660 | <p> | |
1661 | Each row in this table defines a logical multicast group numbered <ref | |
1662 | column="tunnel_key"/> within <ref column="datapath"/>, whose logical | |
1663 | ports are listed in the <ref column="ports"/> column. | |
1664 | </p> | |
1665 | ||
1666 | <column name="datapath"> | |
1667 | The logical datapath in which the multicast group resides. | |
1668 | </column> | |
1669 | ||
1670 | <column name="tunnel_key"> | |
1671 | The value used to designate this logical egress port in tunnel | |
1672 | encapsulations. An index forces the key to be unique within the <ref | |
1673 | column="datapath"/>. The unusual range ensures that multicast group IDs | |
1674 | do not overlap with logical port IDs. | |
1675 | </column> | |
1676 | ||
1677 | <column name="name"> | |
1678 | <p> | |
1679 | The logical multicast group's name. An index forces the name to be | |
1680 | unique within the <ref column="datapath"/>. Logical flows in the | |
1681 | ingress pipeline may output to the group just as for individual logical | |
1682 | ports, by assigning the group's name to <code>outport</code> and | |
1683 | executing an <code>output</code> action. | |
1684 | </p> | |
1685 | ||
1686 | <p> | |
1687 | Multicast group names and logical port names share a single namespace | |
1688 | and thus should not overlap (but the database schema cannot enforce | |
1689 | this). To try to avoid conflicts, <code>ovn-northd</code> uses names | |
1690 | that begin with <code>_MC_</code>. | |
1691 | </p> | |
1692 | </column> | |
1693 | ||
1694 | <column name="ports"> | |
1695 | The logical ports included in the multicast group. All of these ports | |
1696 | must be in the <ref column="datapath"/> logical datapath (but the | |
1697 | database schema cannot enforce this). | |
1698 | </column> | |
1699 | </table> | |
1700 | ||
1701 | <table name="Datapath_Binding" title="Physical-Logical Datapath Bindings"> | |
1702 | <p> | |
2357e695 BP |
1703 | Each row in this table represents a logical datapath, which implements a |
1704 | logical pipeline among the ports in the <ref table="Port_Binding"/> table | |
1705 | associated with it. In practice, the pipeline in a given logical | |
1706 | datapath implements either a logical switch or a logical router. | |
1707 | </p> | |
1708 | ||
1709 | <p> | |
1710 | The main purpose of a row in this table is provide a physical binding for | |
1711 | a logical datapath. A logical datapath does not have a physical | |
1712 | location, so its physical binding information is limited: just <ref | |
1713 | column="tunnel_key"/>. The rest of the data in this table does not | |
1714 | affect packet forwarding. | |
5868eb24 BP |
1715 | </p> |
1716 | ||
1717 | <column name="tunnel_key"> | |
1718 | The tunnel key value to which the logical datapath is bound. | |
1719 | The <code>Tunnel Encapsulation</code> section in | |
1720 | <code>ovn-architecture</code>(7) describes how tunnel keys are | |
1721 | constructed for each supported encapsulation. | |
1722 | </column> | |
1723 | ||
9975d7be BP |
1724 | <group title="OVN_Northbound Relationship"> |
1725 | <p> | |
1726 | Each row in <ref table="Datapath_Binding"/> is associated with some | |
1727 | logical datapath. <code>ovn-northd</code> uses these keys to track the | |
1728 | association of a logical datapath with concepts in the <ref | |
1729 | db="OVN_Northbound"/> database. | |
1730 | </p> | |
1731 | ||
1732 | <column name="external_ids" key="logical-switch" type='{"type": "uuid"}'> | |
1733 | For a logical datapath that represents a logical switch, | |
1734 | <code>ovn-northd</code> stores in this key the UUID of the | |
1735 | corresponding <ref table="Logical_Switch" db="OVN_Northbound"/> row in | |
1736 | the <ref db="OVN_Northbound"/> database. | |
1737 | </column> | |
1738 | ||
1739 | <column name="external_ids" key="logical-router" type='{"type": "uuid"}'> | |
1740 | For a logical datapath that represents a logical router, | |
1741 | <code>ovn-northd</code> stores in this key the UUID of the | |
1742 | corresponding <ref table="Logical_Router" db="OVN_Northbound"/> row in | |
1743 | the <ref db="OVN_Northbound"/> database. | |
1744 | </column> | |
0f8e9c12 | 1745 | |
cacc55af BP |
1746 | <group title="Naming"> |
1747 | <p> | |
1748 | <code>ovn-northd</code> copies these from the name fields in the <ref | |
1749 | db="OVN_Northbound"/> database, either from <ref | |
1750 | table="Logical_Router" db="OVN_Northbound" column="name"/> and <ref | |
1751 | table="Logical_Router" db="OVN_Northbound" column="external_ids" | |
1752 | key="neutron:router_name"/> in the <ref table="Logical_Router" | |
1753 | db="OVN_Northbound"/> table or from <ref table="Logical_Switch" | |
1754 | db="OVN_Northbound" column="name"/> and <ref table="Logical_Switch" | |
1755 | db="OVN_Northbound" column="external_ids" | |
1756 | key="neutron:network_name"/> in the <ref table="Logical_Switch" | |
1757 | db="OVN_Northbound"/> table. | |
1758 | </p> | |
1759 | ||
1760 | <column name="external_ids" key="name"> | |
1761 | A name for the logical datapath. | |
1762 | </column> | |
1763 | ||
1764 | <column name="external_ids" key="name2"> | |
1765 | Another name for the logical datapath. | |
1766 | </column> | |
1767 | </group> | |
9975d7be | 1768 | </group> |
5868eb24 BP |
1769 | |
1770 | <group title="Common Columns"> | |
1771 | The overall purpose of these columns is described under <code>Common | |
1772 | Columns</code> at the beginning of this document. | |
1773 | ||
1774 | <column name="external_ids"/> | |
1775 | </group> | |
1776 | </table> | |
1777 | ||
dcda6e0d | 1778 | <table name="Port_Binding" title="Physical-Logical Port Bindings"> |
fe36184b | 1779 | <p> |
2357e695 BP |
1780 | Each row in this table binds a logical port to a realization. For most |
1781 | logical ports, this means binding to some physical location, for example | |
1782 | by binding a logical port to a VIF that belongs to a VM running on a | |
1783 | particular hypervisor. Other logical ports, such as logical patch ports, | |
1784 | can be realized without a specific physical location, but their bindings | |
1785 | are still expressed through rows in this table. | |
fe36184b BP |
1786 | </p> |
1787 | ||
1788 | <p> | |
80f408f4 JP |
1789 | For every <code>Logical_Switch_Port</code> record in |
1790 | <code>OVN_Northbound</code> database, <code>ovn-northd</code> | |
1791 | creates a record in this table. <code>ovn-northd</code> populates | |
1792 | and maintains every column except the <code>chassis</code> column, | |
1793 | which it leaves empty in new records. | |
9fb4636f GS |
1794 | </p> |
1795 | ||
1796 | <p> | |
88058f19 AW |
1797 | <code>ovn-controller</code>/<code>ovn-controller-vtep</code> |
1798 | populates the <code>chassis</code> column for the records that | |
1799 | identify the logical ports that are located on its hypervisor/gateway, | |
1800 | which <code>ovn-controller</code>/<code>ovn-controller-vtep</code> in | |
1801 | turn finds out by monitoring the local hypervisor's Open_vSwitch | |
1802 | database, which identifies logical ports via the conventions described | |
2567fb84 | 1803 | in <code>IntegrationGuide.rst</code>. (The exceptions are for |
c1645003 | 1804 | <code>Port_Binding</code> records with <code>type</code> of |
17bac0ff RB |
1805 | <code>l3gateway</code>, whose locations are identified by |
1806 | <code>ovn-northd</code> via the <code>options:l3gateway-chassis</code> | |
c1645003 GS |
1807 | column in this table. <code>ovn-controller</code> is still responsible |
1808 | to populate the <code>chassis</code> column.) | |
9fb4636f GS |
1809 | </p> |
1810 | ||
1811 | <p> | |
5868eb24 | 1812 | When a chassis shuts down gracefully, it should clean up the |
9fb4636f | 1813 | <code>chassis</code> column that it previously had populated. |
fe36184b BP |
1814 | (This is not critical because resources hosted on the chassis are equally |
1815 | unreachable regardless of whether their rows are present.) To handle the | |
1816 | case where a VM is shut down abruptly on one chassis, then brought up | |
88058f19 AW |
1817 | again on a different one, |
1818 | <code>ovn-controller</code>/<code>ovn-controller-vtep</code> must | |
1819 | overwrite the <code>chassis</code> column with new information. | |
fe36184b BP |
1820 | </p> |
1821 | ||
c96ba502 BP |
1822 | <group title="Core Features"> |
1823 | <column name="datapath"> | |
1824 | The logical datapath to which the logical port belongs. | |
1825 | </column> | |
1a76c93e | 1826 | |
c96ba502 | 1827 | <column name="logical_port"> |
80f408f4 JP |
1828 | A logical port, taken from <ref table="Logical_Switch_Port" |
1829 | column="name" db="OVN_Northbound"/> in the OVN_Northbound | |
1830 | database's <ref table="Logical_Switch_Port" db="OVN_Northbound"/> | |
1831 | table. OVN does not prescribe a particular format for the | |
1832 | logical port ID. | |
c96ba502 | 1833 | </column> |
c0281929 | 1834 | |
c96ba502 | 1835 | <column name="chassis"> |
184bc3ca RB |
1836 | The meaning of this column depends on the value of the <ref column="type"/> |
1837 | column. This is the meaning for each <ref column="type"/> | |
1838 | ||
1839 | <dl> | |
1840 | <dt>(empty string)</dt> | |
1841 | <dd> | |
1842 | The physical location of the logical port. To successfully identify a | |
1843 | chassis, this column must be a <ref table="Chassis"/> record. This is | |
1844 | populated by <code>ovn-controller</code>. | |
1845 | </dd> | |
1846 | ||
1847 | <dt>vtep</dt> | |
1848 | <dd> | |
1849 | The physical location of the hardware_vtep gateway. To successfully | |
1850 | identify a chassis, this column must be a <ref table="Chassis"/> record. | |
1851 | This is populated by <code>ovn-controller-vtep</code>. | |
1852 | </dd> | |
1853 | ||
1854 | <dt>localnet</dt> | |
1855 | <dd> | |
1856 | Always empty. A localnet port is realized on every chassis that has | |
1857 | connectivity to the corresponding physical network. | |
1858 | </dd> | |
1859 | ||
2a38ef45 DA |
1860 | <dt>localport</dt> |
1861 | <dd> | |
1862 | Always empty. A localport port is present on every chassis. | |
1863 | </dd> | |
1864 | ||
17bac0ff | 1865 | <dt>l3gateway</dt> |
184bc3ca RB |
1866 | <dd> |
1867 | The physical location of the L3 gateway. To successfully identify a | |
1868 | chassis, this column must be a <ref table="Chassis"/> record. This is | |
1869 | populated by <code>ovn-controller</code> based on the value of | |
17bac0ff | 1870 | the <code>options:l3gateway-chassis</code> column in this table. |
184bc3ca RB |
1871 | </dd> |
1872 | ||
1873 | <dt>l2gateway</dt> | |
1874 | <dd> | |
1875 | The physical location of this L2 gateway. To successfully identify a | |
1876 | chassis, this column must be a <ref table="Chassis"/> record. | |
62b87eab NS |
1877 | This is populated by <code>ovn-controller</code> based on the value |
1878 | of the <code>options:l2gateway-chassis</code> column in this table. | |
184bc3ca RB |
1879 | </dd> |
1880 | </dl> | |
1881 | ||
c96ba502 | 1882 | </column> |
c0281929 | 1883 | |
dc65a07c | 1884 | <column name="gateway_chassis"> |
1885 | <p> | |
1886 | A list of <ref table="Gateway_Chassis"/>. | |
1887 | </p> | |
1888 | <p> | |
1889 | This should only be populated for ports with | |
1890 | <ref column="type"/> set to <code>chassisredirect</code>. | |
1891 | This column defines the list of chassis used as gateways where | |
1892 | traffic will be redirected through. | |
1893 | </p> | |
1894 | </column> | |
1895 | ||
c96ba502 BP |
1896 | <column name="tunnel_key"> |
1897 | <p> | |
1898 | A number that represents the logical port in the key (e.g. STT key or | |
1899 | Geneve TLV) field carried within tunnel protocol packets. | |
1900 | </p> | |
c0281929 | 1901 | |
c96ba502 BP |
1902 | <p> |
1903 | The tunnel ID must be unique within the scope of a logical datapath. | |
1904 | </p> | |
1905 | </column> | |
88058f19 | 1906 | |
c96ba502 BP |
1907 | <column name="mac"> |
1908 | <p> | |
1909 | The Ethernet address or addresses used as a source address on the | |
1910 | logical port, each in the form | |
1911 | <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>. | |
1912 | The string <code>unknown</code> is also allowed to indicate that the | |
1913 | logical port has an unknown set of (additional) source addresses. | |
1914 | </p> | |
1915 | ||
1916 | <p> | |
1917 | A VM interface would ordinarily have a single Ethernet address. A | |
1918 | gateway port might initially only have <code>unknown</code>, and then | |
1919 | add MAC addresses to the set as it learns new source addresses. | |
1920 | </p> | |
1921 | </column> | |
88058f19 | 1922 | |
c96ba502 BP |
1923 | <column name="type"> |
1924 | <p> | |
1925 | A type for this logical port. Logical ports can be used to model other | |
1926 | types of connectivity into an OVN logical switch. The following types | |
1927 | are defined: | |
1928 | </p> | |
1929 | ||
1930 | <dl> | |
1931 | <dt>(empty string)</dt> | |
1932 | <dd>VM (or VIF) interface.</dd> | |
d387d24d BP |
1933 | |
1934 | <dt><code>patch</code></dt> | |
1935 | <dd> | |
1936 | One of a pair of logical ports that act as if connected by a patch | |
1937 | cable. Useful for connecting two logical datapaths, e.g. to connect | |
1938 | a logical router to a logical switch or to another logical router. | |
1939 | </dd> | |
1940 | ||
17bac0ff | 1941 | <dt><code>l3gateway</code></dt> |
c1645003 GS |
1942 | <dd> |
1943 | One of a pair of logical ports that act as if connected by a patch | |
1944 | cable across multiple chassis. Useful for connecting a logical | |
1945 | switch with a Gateway router (which is only resident on a | |
1946 | particular chassis). | |
1947 | </dd> | |
1948 | ||
c96ba502 BP |
1949 | <dt><code>localnet</code></dt> |
1950 | <dd> | |
1951 | A connection to a locally accessible network from each | |
1952 | <code>ovn-controller</code> instance. A logical switch can only | |
6e6c3f91 HZ |
1953 | have a single <code>localnet</code> port attached. This is used |
1954 | to model direct connectivity to an existing network. | |
c96ba502 BP |
1955 | </dd> |
1956 | ||
2a38ef45 DA |
1957 | <dt><code>localport</code></dt> |
1958 | <dd> | |
1959 | A connection to a local VIF. Traffic that arrives on a | |
1960 | <code>localport</code> is never forwarded over a tunnel to another | |
1961 | chassis. These ports are present on every chassis and have the same | |
1962 | address in all of them. This is used to model connectivity to local | |
1963 | services that run on every hypervisor. | |
1964 | </dd> | |
1965 | ||
184bc3ca RB |
1966 | <dt><code>l2gateway</code></dt> |
1967 | <dd> | |
1968 | An L2 connection to a physical network. The chassis this | |
1969 | <ref table="Port_Binding"/> is bound to will serve as | |
1970 | an L2 gateway to the network named by | |
1971 | <ref column="options" table="Port_Binding"/>:<code>network_name</code>. | |
1972 | </dd> | |
1973 | ||
c96ba502 BP |
1974 | <dt><code>vtep</code></dt> |
1975 | <dd> | |
1976 | A port to a logical switch on a VTEP gateway chassis. In order to | |
1977 | get this port correctly recognized by the OVN controller, the <ref | |
1978 | column="options" | |
1979 | table="Port_Binding"/>:<code>vtep-physical-switch</code> and <ref | |
1980 | column="options" | |
1981 | table="Port_Binding"/>:<code>vtep-logical-switch</code> must also | |
1982 | be defined. | |
1983 | </dd> | |
41a15b71 MS |
1984 | |
1985 | <dt><code>chassisredirect</code></dt> | |
1986 | <dd> | |
1987 | A logical port that represents a particular instance, bound | |
1988 | to a specific chassis, of an otherwise distributed parent | |
1989 | port (e.g. of type <code>patch</code>). A | |
1990 | <code>chassisredirect</code> port should never be used as an | |
1991 | <code>inport</code>. When an ingress pipeline sets the | |
1992 | <code>outport</code>, it may set the value to a logical port | |
1993 | of type <code>chassisredirect</code>. This will cause the | |
1994 | packet to be directed to a specific chassis to carry out the | |
1995 | egress pipeline. At the beginning of the egress pipeline, | |
1996 | the <code>outport</code> will be reset to the value of the | |
1997 | distributed port. | |
1998 | </dd> | |
c96ba502 BP |
1999 | </dl> |
2000 | </column> | |
2001 | </group> | |
1a76c93e | 2002 | |
d387d24d BP |
2003 | <group title="Patch Options"> |
2004 | <p> | |
2005 | These options apply to logical ports with <ref column="type"/> of | |
2006 | <code>patch</code>. | |
2007 | </p> | |
2008 | ||
2009 | <column name="options" key="peer"> | |
2010 | The <ref column="logical_port"/> in the <ref table="Port_Binding"/> | |
2011 | record for the other side of the patch. The named <ref | |
2012 | column="logical_port"/> must specify this <ref column="logical_port"/> | |
2013 | in its own <code>peer</code> option. That is, the two patch logical | |
2014 | ports must have reversed <ref column="logical_port"/> and | |
2015 | <code>peer</code> values. | |
2016 | </column> | |
26b9e08d | 2017 | |
f40c5588 MS |
2018 | <column name="nat_addresses"> |
2019 | MAC address followed by a list of SNAT and DNAT external IP | |
2020 | addresses, followed by | |
26b9e08d MS |
2021 | <code>is_chassis_resident("<var>lport</var>")</code>, where |
2022 | <var>lport</var> is the name of a logical port on the same chassis | |
2023 | where the corresponding NAT rules are applied. This is used to | |
2024 | send gratuitous ARPs for SNAT and DNAT external IP addresses via | |
2025 | <code>localnet</code>, from the chassis where <var>lport</var> | |
2026 | resides. Example: <code>80:fa:5b:06:72:b7 158.36.44.22 | |
2027 | 158.36.44.24 is_chassis_resident("foo1")</code>. This would result | |
2028 | in generation of gratuitous ARPs for IP addresses 158.36.44.22 and | |
2029 | 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7 from the chassis | |
2030 | where the logical port "foo1" resides. | |
2031 | </column> | |
d387d24d BP |
2032 | </group> |
2033 | ||
184bc3ca | 2034 | <group title="L3 Gateway Options"> |
c1645003 GS |
2035 | <p> |
2036 | These options apply to logical ports with <ref column="type"/> of | |
17bac0ff | 2037 | <code>l3gateway</code>. |
c1645003 GS |
2038 | </p> |
2039 | ||
2040 | <column name="options" key="peer"> | |
2041 | The <ref column="logical_port"/> in the <ref table="Port_Binding"/> | |
17bac0ff | 2042 | record for the other side of the 'l3gateway' port. The named <ref |
c1645003 | 2043 | column="logical_port"/> must specify this <ref column="logical_port"/> |
17bac0ff | 2044 | in its own <code>peer</code> option. That is, the two 'l3gateway' |
c1645003 GS |
2045 | logical ports must have reversed <ref column="logical_port"/> and |
2046 | <code>peer</code> values. | |
2047 | </column> | |
2048 | ||
17bac0ff | 2049 | <column name="options" key="l3gateway-chassis"> |
c1645003 GS |
2050 | The <code>chassis</code> in which the port resides. |
2051 | </column> | |
8439c2eb | 2052 | |
26b9e08d MS |
2053 | <column name="options" key="nat-addresses"> |
2054 | MAC address of the <code>l3gateway</code> port followed by a list of | |
2055 | SNAT and DNAT external IP addresses. This is used to send gratuitous | |
2056 | ARPs for SNAT and DNAT external IP addresses via <code>localnet</code>. | |
2057 | Example: <code>80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24</code>. | |
2058 | This would result in generation of gratuitous ARPs for IP addresses | |
2059 | 158.36.44.22 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. | |
f40c5588 MS |
2060 | This is used in OVS versions prior to 2.8. |
2061 | </column> | |
2062 | ||
2063 | <column name="nat_addresses"> | |
2064 | MAC address of the <code>l3gateway</code> port followed by a list of | |
2065 | SNAT and DNAT external IP addresses. This is used to send gratuitous | |
2066 | ARPs for SNAT and DNAT external IP addresses via <code>localnet</code>. | |
2067 | Example: <code>80:fa:5b:06:72:b7 158.36.44.22 158.36.44.24</code>. | |
2068 | This would result in generation of gratuitous ARPs for IP addresses | |
2069 | 158.36.44.22 and 158.36.44.24 with a MAC address of 80:fa:5b:06:72:b7. | |
2070 | This is used in OVS version 2.8 and later versions. | |
26b9e08d | 2071 | </column> |
c1645003 GS |
2072 | </group> |
2073 | ||
c96ba502 | 2074 | <group title="Localnet Options"> |
eb00399e | 2075 | <p> |
c96ba502 BP |
2076 | These options apply to logical ports with <ref column="type"/> of |
2077 | <code>localnet</code>. | |
eb00399e BP |
2078 | </p> |
2079 | ||
c96ba502 BP |
2080 | <column name="options" key="network_name"> |
2081 | Required. <code>ovn-controller</code> uses the configuration entry | |
2082 | <code>ovn-bridge-mappings</code> to determine how to connect to this | |
2083 | network. <code>ovn-bridge-mappings</code> is a list of network names | |
2084 | mapped to a local OVS bridge that provides access to that network. An | |
2085 | example of configuring <code>ovn-bridge-mappings</code> would be: | |
2086 | ||
2087 | <pre>$ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1</pre> | |
2088 | ||
2089 | <p> | |
2090 | When a logical switch has a <code>localnet</code> port attached, | |
2091 | every chassis that may have a local vif attached to that logical | |
2092 | switch must have a bridge mapping configured to reach that | |
2093 | <code>localnet</code>. Traffic that arrives on a | |
2094 | <code>localnet</code> port is never forwarded over a tunnel to | |
2095 | another chassis. | |
2096 | </p> | |
2097 | </column> | |
2098 | ||
2099 | <column name="tag"> | |
2100 | If set, indicates that the port represents a connection to a specific | |
2101 | VLAN on a locally accessible network. The VLAN ID is used to match | |
2102 | incoming traffic and is also added to outgoing traffic. | |
2103 | </column> | |
2104 | </group> | |
2105 | ||
184bc3ca RB |
2106 | <group title="L2 Gateway Options"> |
2107 | <p> | |
2108 | These options apply to logical ports with <ref column="type"/> of | |
2109 | <code>l2gateway</code>. | |
2110 | </p> | |
2111 | ||
2112 | <column name="options" key="network_name"> | |
2113 | Required. <code>ovn-controller</code> uses the configuration entry | |
2114 | <code>ovn-bridge-mappings</code> to determine how to connect to this | |
2115 | network. <code>ovn-bridge-mappings</code> is a list of network names | |
2116 | mapped to a local OVS bridge that provides access to that network. An | |
2117 | example of configuring <code>ovn-bridge-mappings</code> would be: | |
2118 | ||
2119 | <pre>$ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1</pre> | |
2120 | ||
2121 | <p> | |
2122 | When a logical switch has a <code>l2gateway</code> port attached, | |
2123 | the chassis that the <code>l2gateway</code> port is bound to | |
2124 | must have a bridge mapping configured to reach the network | |
2125 | identified by <code>network_name</code>. | |
2126 | </p> | |
2127 | </column> | |
2128 | ||
62b87eab NS |
2129 | <column name="options" key="l2gateway-chassis"> |
2130 | Required. The <code>chassis</code> in which the port resides. | |
2131 | </column> | |
2132 | ||
184bc3ca RB |
2133 | <column name="tag"> |
2134 | If set, indicates that the gateway is connected to a specific | |
2135 | VLAN on the physical network. The VLAN ID is used to match | |
2136 | incoming traffic and is also added to outgoing traffic. | |
2137 | </column> | |
2138 | </group> | |
2139 | ||
c96ba502 | 2140 | <group title="VTEP Options"> |
eb00399e | 2141 | <p> |
c96ba502 BP |
2142 | These options apply to logical ports with <ref column="type"/> of |
2143 | <code>vtep</code>. | |
eb00399e | 2144 | </p> |
9fb4636f | 2145 | |
c96ba502 BP |
2146 | <column name="options" key="vtep-physical-switch"> |
2147 | Required. The name of the VTEP gateway. | |
2148 | </column> | |
fe36184b | 2149 | |
c96ba502 BP |
2150 | <column name="options" key="vtep-logical-switch"> |
2151 | Required. A logical switch name connected by the VTEP gateway. Must | |
2152 | be set when <ref column="type"/> is <code>vtep</code>. | |
2153 | </column> | |
2154 | </group> | |
fe36184b | 2155 | |
aef5f431 BP |
2156 | <group title="VMI (or VIF) Options"> |
2157 | <p> | |
2158 | These options apply to logical ports with <ref column="type"/> having | |
2159 | (empty string) | |
2160 | </p> | |
2161 | ||
63d91afa | 2162 | <column name="options" key="requested-chassis"> |
bd32425f RB |
2163 | If set, identifies a specific chassis (by name or hostname) that |
2164 | is allowed to bind this port. Using this option will prevent | |
2165 | thrashing between two chassis trying to bind the same port during | |
2166 | a live migration. It can also prevent similar thrashing due to a | |
2167 | mis-configuration, if a port is accidentally created on more than | |
2168 | one chassis. | |
63d91afa LR |
2169 | </column> |
2170 | ||
a6095f81 | 2171 | <column name="options" key="qos_max_rate"> |
aef5f431 | 2172 | If set, indicates the maximum rate for data sent from this interface, |
a6095f81 | 2173 | in bit/s. The traffic will be shaped according to this limit. |
aef5f431 BP |
2174 | </column> |
2175 | ||
a6095f81 | 2176 | <column name="options" key="qos_burst"> |
aef5f431 | 2177 | If set, indicates the maximum burst size for data sent from this |
a6095f81 BS |
2178 | interface, in bits. |
2179 | </column> | |
2180 | ||
2181 | <column name="options" key="qdisc_queue_id" | |
2182 | type='{"type": "integer", "minInteger": 1, "maxInteger": 61440}'> | |
2183 | Indicates the queue number on the physical device. This is same as the | |
2184 | <code>queue_id</code> used in OpenFlow in <code>struct | |
2185 | ofp_action_enqueue</code>. | |
aef5f431 BP |
2186 | </column> |
2187 | </group> | |
2188 | ||
41a15b71 MS |
2189 | <group title="Chassis Redirect Options"> |
2190 | <p> | |
2191 | These options apply to logical ports with <ref column="type"/> | |
2192 | of <code>chassisredirect</code>. | |
2193 | </p> | |
2194 | ||
2195 | <column name="options" key="distributed-port"> | |
2196 | The name of the distributed port for which this | |
2197 | <code>chassisredirect</code> port represents a particular instance. | |
2198 | </column> | |
2199 | ||
2200 | <column name="options" key="redirect-chassis"> | |
2201 | The <code>chassis</code> that this <code>chassisredirect</code> port | |
2202 | is bound to. This is taken from <ref table="Logical_Router_Port" | |
2203 | column="options" key="redirect-chassis" db="OVN_Northbound"/> | |
2204 | in the OVN_Northbound database's <ref table="Logical_Router_Port" | |
2205 | db="OVN_Northbound"/> table. | |
2206 | </column> | |
2207 | </group> | |
2208 | ||
c96ba502 | 2209 | <group title="Nested Containers"> |
fe36184b | 2210 | <p> |
c96ba502 BP |
2211 | These columns support containers nested within a VM. Specifically, |
2212 | they are used when <ref column="type"/> is empty and <ref | |
2213 | column="logical_port"/> identifies the interface of a container spawned | |
2214 | inside a VM. They are empty for containers or VMs that run directly on | |
2215 | a hypervisor. | |
fe36184b BP |
2216 | </p> |
2217 | ||
c96ba502 BP |
2218 | <column name="parent_port"> |
2219 | This is taken from | |
80f408f4 JP |
2220 | <ref table="Logical_Switch_Port" column="parent_name" |
2221 | db="OVN_Northbound"/> in the OVN_Northbound database's | |
2222 | <ref table="Logical_Switch_Port" db="OVN_Northbound"/> table. | |
c96ba502 BP |
2223 | </column> |
2224 | ||
2225 | <column name="tag"> | |
2226 | <p> | |
2227 | Identifies the VLAN tag in the network traffic associated with that | |
2228 | container's network interface. | |
2229 | </p> | |
2230 | ||
2231 | <p> | |
2232 | This column is used for a different purpose when <ref column="type"/> | |
184bc3ca RB |
2233 | is <code>localnet</code> (see <code>Localnet Options</code>, above) |
2234 | or <code>l2gateway</code> (see <code>L2 Gateway Options</code>, above). | |
c96ba502 BP |
2235 | </p> |
2236 | </column> | |
2237 | </group> | |
4a680bff BP |
2238 | |
2239 | <group title="Naming"> | |
2240 | <column name="external_ids" key="name"> | |
2241 | <p> | |
2242 | For a logical switch port, <code>ovn-northd</code> copies this from | |
2243 | <ref table="Logical_Switch_Port" db="OVN_Northbound" | |
2244 | column="external_ids" key="neutron:port_name"/> in the <ref | |
2245 | table="Logical_Switch_Port" db="OVN_Northbound"/> table in the | |
2246 | OVN_Northbound database, if it is a nonempty string. | |
2247 | </p> | |
2248 | ||
2249 | <p> | |
2250 | For a logical switch port, <code>ovn-northd</code> does not currently | |
2251 | set this key. | |
2252 | </p> | |
2253 | </column> | |
2254 | </group> | |
2255 | ||
2256 | <group title="Common Columns"> | |
2257 | <column name="external_ids"> | |
37737b96 DAS |
2258 | <p> |
2259 | See <em>External IDs</em> at the beginning of this document. | |
2260 | </p> | |
2261 | ||
2262 | <p> | |
2263 | The <code>ovn-northd</code> program populates this column with | |
2264 | all entries into the <ref column="external_ids"/> column of the | |
2265 | <ref table="Logical_Switch_Port"/> table of the | |
2266 | <ref db="OVN_Northbound"/> database. | |
2267 | </p> | |
4a680bff BP |
2268 | </column> |
2269 | </group> | |
fe36184b | 2270 | </table> |
0bac7164 BP |
2271 | |
2272 | <table name="MAC_Binding" title="IP to MAC bindings"> | |
2273 | <p> | |
2274 | Each row in this table specifies a binding from an IP address to an | |
2275 | Ethernet address that has been discovered through ARP (for IPv4) or | |
2276 | neighbor discovery (for IPv6). This table is primarily used to discover | |
2277 | bindings on physical networks, because IP-to-MAC bindings for virtual | |
2278 | machines are usually populated statically into the <ref | |
2279 | table="Port_Binding"/> table. | |
2280 | </p> | |
2281 | ||
2282 | <p> | |
2283 | This table expresses a functional relationship: <ref | |
2284 | table="MAC_Binding"/>(<ref column="logical_port"/>, <ref column="ip"/>) = | |
2285 | <ref column="mac"/>. | |
2286 | </p> | |
2287 | ||
2288 | <p> | |
2289 | In outline, the lifetime of a logical router's MAC binding looks like | |
2290 | this: | |
2291 | </p> | |
2292 | ||
2293 | <ol> | |
2294 | <li> | |
2295 | On hypervisor 1, a logical router determines that a packet should be | |
2296 | forwarded to IP address <var>A</var> on one of its router ports. It | |
2297 | uses its logical flow table to determine that <var>A</var> lacks a | |
2298 | static IP-to-MAC binding and the <code>get_arp</code> action to | |
2299 | determine that it lacks a dynamic IP-to-MAC binding. | |
2300 | </li> | |
2301 | ||
2302 | <li> | |
2303 | Using an OVN logical <code>arp</code> action, the logical router | |
2304 | generates and sends a broadcast ARP request to the router port. It | |
2305 | drops the IP packet. | |
2306 | </li> | |
2307 | ||
2308 | <li> | |
2309 | The logical switch attached to the router port delivers the ARP request | |
2310 | to all of its ports. (It might make sense to deliver it only to ports | |
2311 | that have no static IP-to-MAC bindings, but this could also be | |
2312 | surprising behavior.) | |
2313 | </li> | |
2314 | ||
2315 | <li> | |
2316 | A host or VM on hypervisor 2 (which might be the same as hypervisor 1) | |
2317 | attached to the logical switch owns the IP address in question. It | |
2318 | composes an ARP reply and unicasts it to the logical router port's | |
2319 | Ethernet address. | |
2320 | </li> | |
2321 | ||
2322 | <li> | |
2323 | The logical switch delivers the ARP reply to the logical router port. | |
2324 | </li> | |
2325 | ||
2326 | <li> | |
2327 | The logical router flow table executes a <code>put_arp</code> action. | |
2328 | To record the IP-to-MAC binding, <code>ovn-controller</code> adds a row | |
2329 | to the <ref table="MAC_Binding"/> table. | |
2330 | </li> | |
2331 | ||
2332 | <li> | |
2333 | On hypervisor 1, <code>ovn-controller</code> receives the updated <ref | |
2334 | table="MAC_Binding"/> table from the OVN southbound database. The next | |
2335 | packet destined to <var>A</var> through the logical router is sent | |
2336 | directly to the bound Ethernet address. | |
2337 | </li> | |
2338 | </ol> | |
2339 | ||
2340 | <column name="logical_port"> | |
2341 | The logical port on which the binding was discovered. | |
2342 | </column> | |
2343 | ||
2344 | <column name="ip"> | |
2345 | The bound IP address. | |
2346 | </column> | |
2347 | ||
2348 | <column name="mac"> | |
2349 | The Ethernet address to which the IP is bound. | |
2350 | </column> | |
791a7747 LS |
2351 | <column name="datapath"> |
2352 | The logical datapath to which the logical port belongs. | |
2353 | </column> | |
0bac7164 | 2354 | </table> |
42814145 NS |
2355 | |
2356 | <table name="DHCP_Options" title="DHCP Options supported by native OVN DHCP"> | |
2357 | <p> | |
2358 | Each row in this table stores the DHCP Options supported by native OVN | |
2359 | DHCP. <code>ovn-northd</code> populates this table with the supported | |
2360 | DHCP options. <code>ovn-controller</code> looks up this table to get the | |
2361 | DHCP codes of the DHCP options defined in the "put_dhcp_opts" action. | |
2362 | Please refer to the RFC 2132 <code>"https://tools.ietf.org/html/rfc2132"</code> | |
2363 | for the possible list of DHCP options that can be defined here. | |
2364 | </p> | |
2365 | ||
2366 | <column name="name"> | |
2367 | <p> | |
2368 | Name of the DHCP option. | |
2369 | </p> | |
2370 | ||
2371 | <p> | |
2372 | Example. name="router" | |
2373 | </p> | |
2374 | </column> | |
2375 | ||
2376 | <column name="code"> | |
2377 | <p> | |
2378 | DHCP option code for the DHCP option as defined in the RFC 2132. | |
2379 | </p> | |
2380 | ||
2381 | <p> | |
2382 | Example. code=3 | |
2383 | </p> | |
2384 | </column> | |
2385 | ||
2386 | <column name="type"> | |
2387 | <p> | |
2388 | Data type of the DHCP option code. | |
2389 | </p> | |
2390 | ||
2391 | <dl> | |
2392 | <dt><code>value: bool</code></dt> | |
2393 | <dd> | |
2394 | <p> | |
2395 | This indicates that the value of the DHCP option is a bool. | |
2396 | </p> | |
2397 | ||
2398 | <p> | |
2399 | Example. "name=ip_forward_enable", "code=19", "type=bool". | |
2400 | </p> | |
2401 | ||
2402 | <p> | |
2403 | put_dhcp_opts(..., ip_forward_enable = 1,...) | |
2404 | </p> | |
2405 | </dd> | |
2406 | ||
2407 | <dt><code>value: uint8</code></dt> | |
2408 | <dd> | |
2409 | <p> | |
2410 | This indicates that the value of the DHCP option is an unsigned | |
2411 | int8 (8 bits) | |
2412 | </p> | |
2413 | ||
2414 | <p> | |
2415 | Example. "name=default_ttl", "code=23", "type=uint8". | |
2416 | </p> | |
2417 | ||
2418 | <p> | |
2419 | put_dhcp_opts(..., default_ttl = 50,...) | |
2420 | </p> | |
2421 | </dd> | |
2422 | ||
2423 | <dt><code>value: uint16</code></dt> | |
2424 | <dd> | |
2425 | <p> | |
2426 | This indicates that the value of the DHCP option is an unsigned | |
2427 | int16 (16 bits). | |
2428 | </p> | |
2429 | ||
2430 | <p> | |
2431 | Example. "name=mtu", "code=26", "type=uint16". | |
2432 | </p> | |
2433 | ||
2434 | <p> | |
2435 | put_dhcp_opts(..., mtu = 1450,...) | |
2436 | </p> | |
2437 | </dd> | |
2438 | ||
2439 | <dt><code>value: uint32</code></dt> | |
2440 | <dd> | |
2441 | <p> | |
2442 | This indicates that the value of the DHCP option is an unsigned | |
2443 | int32 (32 bits). | |
2444 | </p> | |
2445 | ||
2446 | <p> | |
2447 | Example. "name=lease_time", "code=51", "type=uint32". | |
2448 | </p> | |
2449 | ||
2450 | <p> | |
2451 | put_dhcp_opts(..., lease_time = 86400,...) | |
2452 | </p> | |
2453 | </dd> | |
2454 | ||
2455 | <dt><code>value: ipv4</code></dt> | |
2456 | <dd> | |
2457 | <p> | |
2458 | This indicates that the value of the DHCP option is an IPv4 | |
2459 | address or addresses. | |
2460 | </p> | |
2461 | ||
2462 | <p> | |
2463 | Example. "name=router", "code=3", "type=ipv4". | |
2464 | </p> | |
2465 | ||
2466 | <p> | |
2467 | put_dhcp_opts(..., router = 10.0.0.1,...) | |
2468 | </p> | |
2469 | ||
2470 | <p> | |
2471 | Example. "name=dns_server", "code=6", "type=ipv4". | |
2472 | </p> | |
2473 | ||
2474 | <p> | |
2475 | put_dhcp_opts(..., dns_server = {8.8.8.8 7.7.7.7},...) | |
2476 | </p> | |
2477 | </dd> | |
2478 | ||
2479 | <dt><code>value: static_routes</code></dt> | |
2480 | <dd> | |
2481 | <p> | |
2482 | This indicates that the value of the DHCP option contains a pair of | |
2483 | IPv4 route and next hop addresses. | |
2484 | </p> | |
2485 | ||
2486 | <p> | |
2487 | Example. "name=classless_static_route", "code=121", "type=static_routes". | |
2488 | </p> | |
2489 | ||
2490 | <p> | |
2491 | put_dhcp_opts(..., classless_static_route = {30.0.0.0/24,10.0.0.4,0.0.0.0/0,10.0.0.1}...) | |
2492 | </p> | |
2493 | </dd> | |
2494 | ||
2495 | <dt><code>value: str</code></dt> | |
2496 | <dd> | |
2497 | <p> | |
2498 | This indicates that the value of the DHCP option is a string. | |
2499 | </p> | |
2500 | ||
2501 | <p> | |
2502 | Example. "name=host_name", "code=12", "type=str". | |
2503 | </p> | |
2504 | </dd> | |
2505 | </dl> | |
2506 | </column> | |
2507 | </table> | |
01cfdb2f NS |
2508 | |
2509 | <table name="DHCPv6_Options" title="DHCPv6 Options supported by native OVN DHCPv6"> | |
2510 | <p> | |
2511 | Each row in this table stores the DHCPv6 Options supported by native OVN | |
2512 | DHCPv6. <code>ovn-northd</code> populates this table with the supported | |
2513 | DHCPv6 options. <code>ovn-controller</code> looks up this table to get | |
2514 | the DHCPv6 codes of the DHCPv6 options defined in the | |
2515 | <code>put_dhcpv6_opts</code> action. Please refer to RFC 3315 and RFC | |
2516 | 3646 for the list of DHCPv6 options that can be defined here. | |
2517 | </p> | |
2518 | ||
2519 | <column name="name"> | |
2520 | <p> | |
2521 | Name of the DHCPv6 option. | |
2522 | </p> | |
2523 | ||
2524 | <p> | |
2525 | Example. name="ia_addr" | |
2526 | </p> | |
2527 | </column> | |
2528 | ||
2529 | <column name="code"> | |
2530 | <p> | |
2531 | DHCPv6 option code for the DHCPv6 option as defined in the appropriate | |
2532 | RFC. | |
2533 | </p> | |
2534 | ||
2535 | <p> | |
2536 | Example. code=3 | |
2537 | </p> | |
2538 | </column> | |
2539 | ||
2540 | <column name="type"> | |
2541 | <p> | |
2542 | Data type of the DHCPv6 option code. | |
2543 | </p> | |
2544 | ||
2545 | <dl> | |
2546 | <dt><code>value: ipv6</code></dt> | |
2547 | <dd> | |
2548 | <p> | |
2549 | This indicates that the value of the DHCPv6 option is an IPv6 | |
2550 | address(es). | |
2551 | </p> | |
2552 | ||
2553 | <p> | |
2554 | Example. "name=ia_addr", "code=5", "type=ipv6". | |
2555 | </p> | |
2556 | ||
2557 | <p> | |
2558 | put_dhcpv6_opts(..., ia_addr = ae70::4,...) | |
2559 | </p> | |
2560 | </dd> | |
2561 | ||
2562 | <dt><code>value: str</code></dt> | |
2563 | <dd> | |
2564 | <p> | |
2565 | This indicates that the value of the DHCPv6 option is a string. | |
2566 | </p> | |
2567 | ||
2568 | <p> | |
2569 | Example. "name=domain_search", "code=24", "type=str". | |
2570 | </p> | |
2571 | ||
2572 | <p> | |
2573 | put_dhcpv6_opts(..., domain_search = ovn.domain,...) | |
2574 | </p> | |
2575 | </dd> | |
2576 | ||
2577 | <dt><code>value: mac</code></dt> | |
2578 | <dd> | |
2579 | <p> | |
2580 | This indicates that the value of the DHCPv6 option is a MAC address. | |
2581 | </p> | |
2582 | ||
2583 | <p> | |
2584 | Example. "name=server_id", "code=2", "type=mac". | |
2585 | </p> | |
2586 | ||
2587 | <p> | |
2588 | put_dhcpv6_opts(..., server_id = 01:02:03:04L05:06,...) | |
2589 | </p> | |
2590 | </dd> | |
2591 | </dl> | |
2592 | </column> | |
2593 | </table> | |
7fff4eb7 LR |
2594 | <table name="Connection" title="OVSDB client connections."> |
2595 | <p> | |
2596 | Configuration for a database connection to an Open vSwitch database | |
2597 | (OVSDB) client. | |
2598 | </p> | |
2599 | ||
2600 | <p> | |
2601 | This table primarily configures the Open vSwitch database server | |
2602 | (<code>ovsdb-server</code>). | |
2603 | </p> | |
2604 | ||
2605 | <p> | |
2606 | The Open vSwitch database server can initiate and maintain active | |
2607 | connections to remote clients. It can also listen for database | |
2608 | connections. | |
2609 | </p> | |
2610 | ||
2611 | <group title="Core Features"> | |
2612 | <column name="target"> | |
2613 | <p>Connection methods for clients.</p> | |
2614 | <p> | |
2615 | The following connection methods are currently supported: | |
2616 | </p> | |
2617 | <dl> | |
2618 | <dt><code>ssl:<var>ip</var></code>[<code>:<var>port</var></code>]</dt> | |
2619 | <dd> | |
2620 | <p> | |
2621 | The specified SSL <var>port</var> on the host at the given | |
2622 | <var>ip</var>, which must be expressed as an IP address | |
10471820 LR |
2623 | (not a DNS name). A valid SSL configuration must be provided |
2624 | when this form is used, this configuration can be specified | |
2625 | via command-line options or the <ref table="SSL"/> table. | |
7fff4eb7 LR |
2626 | </p> |
2627 | <p> | |
2628 | If <var>port</var> is not specified, it defaults to 6640. | |
2629 | </p> | |
2630 | <p> | |
2631 | SSL support is an optional feature that is not always | |
2632 | built as part of Open vSwitch. | |
2633 | </p> | |
2634 | </dd> | |
2635 | ||
2636 | <dt><code>tcp:<var>ip</var></code>[<code>:<var>port</var></code>]</dt> | |
2637 | <dd> | |
2638 | <p> | |
2639 | The specified TCP <var>port</var> on the host at the given | |
2640 | <var>ip</var>, which must be expressed as an IP address (not a | |
2641 | DNS name), where <var>ip</var> can be IPv4 or IPv6 address. If | |
2642 | <var>ip</var> is an IPv6 address, wrap it in square brackets, | |
2643 | e.g. <code>tcp:[::1]:6640</code>. | |
2644 | </p> | |
2645 | <p> | |
2646 | If <var>port</var> is not specified, it defaults to 6640. | |
2647 | </p> | |
2648 | </dd> | |
2649 | <dt><code>pssl:</code>[<var>port</var>][<code>:<var>ip</var></code>]</dt> | |
2650 | <dd> | |
2651 | <p> | |
2652 | Listens for SSL connections on the specified TCP <var>port</var>. | |
2653 | Specify 0 for <var>port</var> to have the kernel automatically | |
2654 | choose an available port. If <var>ip</var>, which must be | |
2655 | expressed as an IP address (not a DNS name), is specified, then | |
2656 | connections are restricted to the specified local IP address | |
2657 | (either IPv4 or IPv6 address). If <var>ip</var> is an IPv6 | |
2658 | address, wrap in square brackets, | |
2659 | e.g. <code>pssl:6640:[::1]</code>. If <var>ip</var> is not | |
2660 | specified then it listens only on IPv4 (but not IPv6) addresses. | |
10471820 | 2661 | A valid SSL configuration must be provided when this form is used, |
a8cb558a DJ |
2662 | this can be specified either via command-line options or the |
2663 | <ref table="SSL"/> table. | |
7fff4eb7 LR |
2664 | </p> |
2665 | <p> | |
2666 | If <var>port</var> is not specified, it defaults to 6640. | |
2667 | </p> | |
2668 | <p> | |
2669 | SSL support is an optional feature that is not always built as | |
2670 | part of Open vSwitch. | |
2671 | </p> | |
2672 | </dd> | |
2673 | <dt><code>ptcp:</code>[<var>port</var>][<code>:<var>ip</var></code>]</dt> | |
2674 | <dd> | |
2675 | <p> | |
2676 | Listens for connections on the specified TCP <var>port</var>. | |
2677 | Specify 0 for <var>port</var> to have the kernel automatically | |
2678 | choose an available port. If <var>ip</var>, which must be | |
2679 | expressed as an IP address (not a DNS name), is specified, then | |
2680 | connections are restricted to the specified local IP address | |
2681 | (either IPv4 or IPv6 address). If <var>ip</var> is an IPv6 | |
2682 | address, wrap it in square brackets, | |
2683 | e.g. <code>ptcp:6640:[::1]</code>. If <var>ip</var> is not | |
2684 | specified then it listens only on IPv4 addresses. | |
2685 | </p> | |
2686 | <p> | |
2687 | If <var>port</var> is not specified, it defaults to 6640. | |
2688 | </p> | |
2689 | </dd> | |
2690 | </dl> | |
2691 | <p>When multiple clients are configured, the <ref column="target"/> | |
2692 | values must be unique. Duplicate <ref column="target"/> values yield | |
2693 | unspecified results.</p> | |
2694 | </column> | |
2695 | ||
2696 | <column name="read_only"> | |
2697 | <code>true</code> to restrict these connections to read-only | |
2698 | transactions, <code>false</code> to allow them to modify the database. | |
2699 | </column> | |
75ddb5f4 LR |
2700 | <column name="role"> |
2701 | String containing role name for this connection entry. | |
2702 | </column> | |
7fff4eb7 LR |
2703 | </group> |
2704 | ||
2705 | <group title="Client Failure Detection and Handling"> | |
2706 | <column name="max_backoff"> | |
2707 | Maximum number of milliseconds to wait between connection attempts. | |
2708 | Default is implementation-specific. | |
2709 | </column> | |
2710 | ||
2711 | <column name="inactivity_probe"> | |
2712 | Maximum number of milliseconds of idle time on connection to the client | |
2713 | before sending an inactivity probe message. If Open vSwitch does not | |
2714 | communicate with the client for the specified number of seconds, it | |
2715 | will send a probe. If a response is not received for the same | |
2716 | additional amount of time, Open vSwitch assumes the connection has been | |
2717 | broken and attempts to reconnect. Default is implementation-specific. | |
2718 | A value of 0 disables inactivity probes. | |
2719 | </column> | |
2720 | </group> | |
2721 | ||
2722 | <group title="Status"> | |
2723 | <p> | |
2724 | Key-value pair of <ref column="is_connected"/> is always updated. | |
2725 | Other key-value pairs in the status columns may be updated depends | |
2726 | on the <ref column="target"/> type. | |
2727 | </p> | |
2728 | ||
2729 | <p> | |
2730 | When <ref column="target"/> specifies a connection method that | |
2731 | listens for inbound connections (e.g. <code>ptcp:</code> or | |
2732 | <code>punix:</code>), both <ref column="n_connections"/> and | |
2733 | <ref column="is_connected"/> may also be updated while the | |
2734 | remaining key-value pairs are omitted. | |
2735 | </p> | |
2736 | ||
2737 | <p> | |
2738 | On the other hand, when <ref column="target"/> specifies an | |
2739 | outbound connection, all key-value pairs may be updated, except | |
2740 | the above-mentioned two key-value pairs associated with inbound | |
2741 | connection targets. They are omitted. | |
2742 | </p> | |
2743 | ||
a8cb558a | 2744 | <column name="is_connected"> |
7fff4eb7 LR |
2745 | <code>true</code> if currently connected to this client, |
2746 | <code>false</code> otherwise. | |
2747 | </column> | |
2748 | ||
2749 | <column name="status" key="last_error"> | |
2750 | A human-readable description of the last error on the connection | |
2751 | to the manager; i.e. <code>strerror(errno)</code>. This key | |
2752 | will exist only if an error has occurred. | |
2753 | </column> | |
2754 | ||
2755 | <column name="status" key="state" | |
2756 | type='{"type": "string", "enum": ["set", ["VOID", "BACKOFF", "CONNECTING", "ACTIVE", "IDLE"]]}'> | |
2757 | <p> | |
2758 | The state of the connection to the manager: | |
2759 | </p> | |
2760 | <dl> | |
2761 | <dt><code>VOID</code></dt> | |
2762 | <dd>Connection is disabled.</dd> | |
2763 | ||
2764 | <dt><code>BACKOFF</code></dt> | |
2765 | <dd>Attempting to reconnect at an increasing period.</dd> | |
2766 | ||
2767 | <dt><code>CONNECTING</code></dt> | |
2768 | <dd>Attempting to connect.</dd> | |
2769 | ||
2770 | <dt><code>ACTIVE</code></dt> | |
2771 | <dd>Connected, remote host responsive.</dd> | |
2772 | ||
2773 | <dt><code>IDLE</code></dt> | |
2774 | <dd>Connection is idle. Waiting for response to keep-alive.</dd> | |
2775 | </dl> | |
2776 | <p> | |
2777 | These values may change in the future. They are provided only for | |
2778 | human consumption. | |
2779 | </p> | |
2780 | </column> | |
2781 | ||
2782 | <column name="status" key="sec_since_connect" | |
2783 | type='{"type": "integer", "minInteger": 0}'> | |
2784 | The amount of time since this client last successfully connected | |
2785 | to the database (in seconds). Value is empty if client has never | |
2786 | successfully been connected. | |
2787 | </column> | |
2788 | ||
2789 | <column name="status" key="sec_since_disconnect" | |
2790 | type='{"type": "integer", "minInteger": 0}'> | |
2791 | The amount of time since this client last disconnected from the | |
2792 | database (in seconds). Value is empty if client has never | |
2793 | disconnected. | |
2794 | </column> | |
2795 | ||
2796 | <column name="status" key="locks_held"> | |
2797 | Space-separated list of the names of OVSDB locks that the connection | |
2798 | holds. Omitted if the connection does not hold any locks. | |
2799 | </column> | |
2800 | ||
2801 | <column name="status" key="locks_waiting"> | |
2802 | Space-separated list of the names of OVSDB locks that the connection is | |
2803 | currently waiting to acquire. Omitted if the connection is not waiting | |
2804 | for any locks. | |
2805 | </column> | |
2806 | ||
2807 | <column name="status" key="locks_lost"> | |
2808 | Space-separated list of the names of OVSDB locks that the connection | |
2809 | has had stolen by another OVSDB client. Omitted if no locks have been | |
2810 | stolen from this connection. | |
2811 | </column> | |
2812 | ||
2813 | <column name="status" key="n_connections" | |
2814 | type='{"type": "integer", "minInteger": 2}'> | |
2815 | When <ref column="target"/> specifies a connection method that | |
2816 | listens for inbound connections (e.g. <code>ptcp:</code> or | |
2817 | <code>pssl:</code>) and more than one connection is actually active, | |
2818 | the value is the number of active connections. Otherwise, this | |
2819 | key-value pair is omitted. | |
2820 | </column> | |
2821 | ||
2822 | <column name="status" key="bound_port" type='{"type": "integer"}'> | |
2823 | When <ref column="target"/> is <code>ptcp:</code> or | |
2824 | <code>pssl:</code>, this is the TCP port on which the OVSDB server is | |
2825 | listening. (This is particularly useful when <ref | |
2826 | column="target"/> specifies a port of 0, allowing the kernel to | |
2827 | choose any available port.) | |
2828 | </column> | |
2829 | </group> | |
2830 | ||
2831 | <group title="Common Columns"> | |
2832 | The overall purpose of these columns is described under <code>Common | |
2833 | Columns</code> at the beginning of this document. | |
2834 | ||
2835 | <column name="external_ids"/> | |
2836 | <column name="other_config"/> | |
2837 | </group> | |
2838 | </table> | |
10471820 LR |
2839 | <table name="SSL"> |
2840 | SSL configuration for ovn-sb database access. | |
2841 | ||
2842 | <column name="private_key"> | |
2843 | Name of a PEM file containing the private key used as the switch's | |
2844 | identity for SSL connections to the controller. | |
2845 | </column> | |
2846 | ||
2847 | <column name="certificate"> | |
2848 | Name of a PEM file containing a certificate, signed by the | |
2849 | certificate authority (CA) used by the controller and manager, | |
2850 | that certifies the switch's private key, identifying a trustworthy | |
2851 | switch. | |
2852 | </column> | |
2853 | ||
2854 | <column name="ca_cert"> | |
2855 | Name of a PEM file containing the CA certificate used to verify | |
2856 | that the switch is connected to a trustworthy controller. | |
2857 | </column> | |
2858 | ||
2859 | <column name="bootstrap_ca_cert"> | |
2860 | If set to <code>true</code>, then Open vSwitch will attempt to | |
2861 | obtain the CA certificate from the controller on its first SSL | |
2862 | connection and save it to the named PEM file. If it is successful, | |
2863 | it will immediately drop the connection and reconnect, and from then | |
2864 | on all SSL connections must be authenticated by a certificate signed | |
2865 | by the CA certificate thus obtained. <em>This option exposes the | |
2866 | SSL connection to a man-in-the-middle attack obtaining the initial | |
2867 | CA certificate.</em> It may still be useful for bootstrapping. | |
2868 | </column> | |
2869 | ||
51af591b LR |
2870 | <column name="ssl_protocols"> |
2871 | List of SSL protocols to be enabled for SSL connections. The default | |
2872 | when this option is omitted is <code>TLSv1,TLSv1.1,TLSv1.2</code>. | |
2873 | </column> | |
2874 | ||
2875 | <column name="ssl_ciphers"> | |
2876 | List of ciphers (in OpenSSL cipher string format) to be supported | |
2877 | for SSL connections. The default when this option is omitted is | |
2878 | <code>HIGH:!aNULL:!MD5</code>. | |
2879 | </column> | |
2880 | ||
10471820 LR |
2881 | <group title="Common Columns"> |
2882 | The overall purpose of these columns is described under <code>Common | |
2883 | Columns</code> at the beginning of this document. | |
2884 | ||
2885 | <column name="external_ids"/> | |
2886 | </group> | |
2887 | </table> | |
ea991ad2 NS |
2888 | <table name="DNS" title="Native DNS resolution"> |
2889 | <p> | |
2890 | Each row in this table stores the DNS records. The OVN action | |
2891 | <code>dns_lookup</code> uses this table for DNS resolution. | |
2892 | </p> | |
2893 | ||
2894 | <column name="records"> | |
2895 | Key-value pair of DNS records with <code>DNS query name</code> as the key | |
2896 | and a string of IP address(es) separated by comma or space as the | |
2897 | value. | |
2898 | ||
2899 | <p><b>Example: </b> "vm1.ovn.org" = "10.0.0.4 aef0::4"</p> | |
2900 | </column> | |
2901 | ||
2902 | <column name="datapaths"> | |
2903 | The DNS records defined in the column <ref column="records"/> will be | |
2904 | applied only to the DNS queries originating from the datapaths defined | |
2905 | in this column. | |
2906 | </column> | |
2907 | ||
2908 | <group title="Common Columns"> | |
2909 | <column name="external_ids"> | |
2910 | See <em>External IDs</em> at the beginning of this document. | |
2911 | </column> | |
2912 | </group> | |
2913 | </table> | |
75ddb5f4 LR |
2914 | |
2915 | <table name="RBAC_Role"> | |
2916 | Role table for role-based access controls. | |
2917 | ||
2918 | <column name="name"> | |
2919 | The role name, corresponding to the <code>role</code> | |
2920 | column in the <code>Connection</code> table. | |
2921 | </column> | |
2922 | ||
2923 | <column name="permissions"> | |
2924 | A mapping of table names to rows in the | |
2925 | <code>RBAC_Permission</code> table. | |
2926 | </column> | |
2927 | </table> | |
2928 | <table name="RBAC_Permission"> | |
2929 | Permissions table for role-based access controls. | |
2930 | ||
2931 | <column name="table"> | |
2932 | Name of table to which this row applies. | |
2933 | </column> | |
2934 | ||
2935 | <column name="authorization"> | |
2936 | Set of strings identifying columns and column:key pairs to be compared | |
2937 | with client ID. At least one match is required in order to be | |
2938 | authorized. A zero-length string is treated as a special value | |
2939 | indicating all clients should be considered authorized. | |
2940 | </column> | |
2941 | ||
2942 | <column name="insert_delete"> | |
2943 | When "true", row insertions and authorized row | |
2944 | deletions are permitted. | |
2945 | </column> | |
2946 | <column name="update"> | |
2947 | Set of strings identifying columns and column:key pairs that authorized | |
2948 | clients are allowed to modify. | |
2949 | </column> | |
2950 | </table> | |
dc65a07c | 2951 | <table name="Gateway_Chassis"> |
2952 | <p> | |
2953 | Association of <ref table="Port_Binding"/> rows of | |
2954 | <ref table="Port_Binding" column="type"/> <code>chassisredirect</code> to | |
2955 | a <ref table="Chassis"/>. The traffic going out through a specific | |
2956 | <code>chassisredirect</code> port will be redirected to a chassis, | |
2957 | or a set of them in high availability configurations. | |
2958 | </p> | |
2959 | ||
2960 | <column name="name"> | |
2961 | <p> | |
2962 | Name of the <ref table="Gateway_Chassis"/>. | |
2963 | </p> | |
2964 | <p> | |
2965 | A suggested, but not required naming convention is | |
2966 | <code>${port_name}_${chassis_name}</code>. | |
2967 | </p> | |
2968 | </column> | |
2969 | ||
2970 | <column name="chassis"> | |
2971 | The <ref table="Chassis"/> to which we send the traffic. | |
2972 | </column> | |
2973 | ||
2974 | <column name="priority"> | |
2975 | This is the priority the specific <ref table="Chassis"/> among all | |
2976 | Gateway_Chassis belonging to the same <ref table="Port_Binding"/>. | |
2977 | </column> | |
2978 | ||
2979 | <column name="options"> | |
2980 | Reserved for future use. | |
2981 | </column> | |
2982 | ||
2983 | <group title="Common Columns"> | |
2984 | The overall purpose of these columns is described under <code>Common | |
2985 | Columns</code> at the beginning of this document. | |
2986 | ||
2987 | <column name="external_ids"/> | |
2988 | </group> | |
2989 | </table> | |
fe36184b | 2990 | </database> |