]>
Commit | Line | Data |
---|---|---|
add17b69 | 1 | <?xml version="1.0" encoding="utf-8"?> |
57ba0a77 | 2 | <database name="vtep" title="Hardware VTEP Database"> |
add17b69 BD |
3 | <p> |
4 | This schema specifies relations that a VTEP can use to integrate | |
5 | physical ports into logical switches maintained by a network | |
6 | virtualization controller such as NSX. | |
7 | </p> | |
f86f54a9 | 8 | |
add17b69 BD |
9 | <p>Glossary:</p> |
10 | ||
11 | <dl> | |
12 | <dt>VTEP</dt> | |
13 | <dd> | |
14 | VXLAN Tunnel End Point, an entity which originates and/or terminates | |
15 | VXLAN tunnels. | |
16 | </dd> | |
17 | ||
18 | <dt>HSC</dt> | |
19 | <dd> | |
20 | Hardware Switch Controller. | |
21 | </dd> | |
22 | ||
23 | <dt>NVC</dt> | |
24 | <dd> | |
25 | Network Virtualization Controller, e.g. NSX. | |
26 | </dd> | |
27 | ||
28 | <dt>VRF</dt> | |
29 | <dd> | |
30 | Virtual Routing and Forwarding instance. | |
31 | </dd> | |
f86f54a9 | 32 | </dl> |
add17b69 BD |
33 | |
34 | <table name="Global" title="Top-level configuration."> | |
35 | Top-level configuration for a hardware VTEP. There must be | |
36 | exactly one record in the <ref table="Global"/> table. | |
37 | ||
38 | <column name="switches"> | |
849222dd BP |
39 | <p> |
40 | The physical switch or switches managed by the VTEP. | |
41 | </p> | |
42 | ||
43 | <p> | |
44 | When a physical switch integrates support for this VTEP schema, which | |
45 | is expected to be the most common case, this column should point to one | |
46 | <ref table="Physical_Switch"/> record that represents the switch | |
47 | itself. In another possible implementation, a server or a VM presents | |
48 | a VTEP schema front-end interface to one or more physical switches, | |
49 | presumably communicating with those physical switches over a | |
50 | proprietary protocol. In that case, this column would point to one | |
51 | <ref table="Physical_Switch"/> for each physical switch, and the set | |
52 | might change over time as the front-end server comes to represent a | |
53 | differing set of switches. | |
54 | </p> | |
add17b69 BD |
55 | </column> |
56 | ||
57 | <group title="Database Configuration"> | |
58 | <p> | |
59 | These columns primarily configure the database server | |
60 | (<code>ovsdb-server</code>), not the hardware VTEP itself. | |
61 | </p> | |
62 | ||
63 | <column name="managers"> | |
64 | Database clients to which the database server should connect or | |
65 | to which it should listen, along with options for how these | |
66 | connection should be configured. See the <ref table="Manager"/> | |
67 | table for more information. | |
68 | </column> | |
69 | </group> | |
70 | </table> | |
71 | ||
72 | <table name="Manager" title="OVSDB management connection."> | |
73 | <p> | |
74 | Configuration for a database connection to an Open vSwitch Database | |
75 | (OVSDB) client. | |
76 | </p> | |
77 | ||
78 | <p> | |
79 | The database server can initiate and maintain active connections | |
80 | to remote clients. It can also listen for database connections. | |
81 | </p> | |
82 | ||
83 | <group title="Core Features"> | |
84 | <column name="target"> | |
85 | <p>Connection method for managers.</p> | |
86 | <p> | |
87 | The following connection methods are currently supported: | |
88 | </p> | |
89 | <dl> | |
90 | <dt><code>ssl:<var>ip</var></code>[<code>:<var>port</var></code>]</dt> | |
91 | <dd> | |
92 | <p> | |
d4763d1d | 93 | The specified SSL <var>port</var> (default: 6640) on the host at |
add17b69 BD |
94 | the given <var>ip</var>, which must be expressed as an IP address |
95 | (not a DNS name). | |
96 | </p> | |
97 | <p> | |
fdf059ff BD |
98 | SSL key and certificate configuration happens outside the |
99 | database. | |
add17b69 BD |
100 | </p> |
101 | </dd> | |
102 | ||
103 | <dt><code>tcp:<var>ip</var></code>[<code>:<var>port</var></code>]</dt> | |
104 | <dd> | |
d4763d1d | 105 | The specified TCP <var>port</var> (default: 6640) on the host at |
add17b69 BD |
106 | the given <var>ip</var>, which must be expressed as an IP address |
107 | (not a DNS name). | |
108 | </dd> | |
109 | <dt><code>pssl:</code>[<var>port</var>][<code>:<var>ip</var></code>]</dt> | |
110 | <dd> | |
111 | <p> | |
112 | Listens for SSL connections on the specified TCP <var>port</var> | |
d4763d1d | 113 | (default: 6640). If <var>ip</var>, which must be expressed as an |
add17b69 BD |
114 | IP address (not a DNS name), is specified, then connections are |
115 | restricted to the specified local IP address. | |
116 | </p> | |
117 | </dd> | |
118 | <dt><code>ptcp:</code>[<var>port</var>][<code>:<var>ip</var></code>]</dt> | |
119 | <dd> | |
120 | Listens for connections on the specified TCP <var>port</var> | |
d4763d1d | 121 | (default: 6640). If <var>ip</var>, which must be expressed as an |
add17b69 BD |
122 | IP address (not a DNS name), is specified, then connections are |
123 | restricted to the specified local IP address. | |
124 | </dd> | |
125 | </dl> | |
126 | </column> | |
127 | </group> | |
128 | ||
129 | <group title="Client Failure Detection and Handling"> | |
130 | <column name="max_backoff"> | |
131 | Maximum number of milliseconds to wait between connection attempts. | |
132 | Default is implementation-specific. | |
133 | </column> | |
134 | ||
135 | <column name="inactivity_probe"> | |
136 | Maximum number of milliseconds of idle time on connection to the | |
137 | client before sending an inactivity probe message. If the Open | |
138 | vSwitch database does not communicate with the client for the | |
139 | specified number of seconds, it will send a probe. If a | |
140 | response is not received for the same additional amount of time, | |
141 | the database server assumes the connection has been broken | |
142 | and attempts to reconnect. Default is implementation-specific. | |
143 | A value of 0 disables inactivity probes. | |
144 | </column> | |
145 | </group> | |
146 | ||
147 | <group title="Status"> | |
148 | <column name="is_connected"> | |
149 | <code>true</code> if currently connected to this manager, | |
150 | <code>false</code> otherwise. | |
151 | </column> | |
152 | ||
153 | <column name="status" key="last_error"> | |
154 | A human-readable description of the last error on the connection | |
155 | to the manager; i.e. <code>strerror(errno)</code>. This key | |
156 | will exist only if an error has occurred. | |
157 | </column> | |
158 | ||
159 | <column name="status" key="state" | |
160 | type='{"type": "string", "enum": ["set", ["VOID", "BACKOFF", "CONNECTING", "ACTIVE", "IDLE"]]}'> | |
161 | <p> | |
162 | The state of the connection to the manager: | |
163 | </p> | |
164 | <dl> | |
165 | <dt><code>VOID</code></dt> | |
166 | <dd>Connection is disabled.</dd> | |
167 | ||
168 | <dt><code>BACKOFF</code></dt> | |
169 | <dd>Attempting to reconnect at an increasing period.</dd> | |
170 | ||
171 | <dt><code>CONNECTING</code></dt> | |
172 | <dd>Attempting to connect.</dd> | |
173 | ||
174 | <dt><code>ACTIVE</code></dt> | |
175 | <dd>Connected, remote host responsive.</dd> | |
176 | ||
177 | <dt><code>IDLE</code></dt> | |
178 | <dd>Connection is idle. Waiting for response to keep-alive.</dd> | |
179 | </dl> | |
180 | <p> | |
181 | These values may change in the future. They are provided only for | |
182 | human consumption. | |
183 | </p> | |
184 | </column> | |
185 | ||
186 | <column name="status" key="sec_since_connect" | |
187 | type='{"type": "integer", "minInteger": 0}'> | |
188 | The amount of time since this manager last successfully connected | |
189 | to the database (in seconds). Value is empty if manager has never | |
190 | successfully connected. | |
191 | </column> | |
192 | ||
193 | <column name="status" key="sec_since_disconnect" | |
194 | type='{"type": "integer", "minInteger": 0}'> | |
195 | The amount of time since this manager last disconnected from the | |
196 | database (in seconds). Value is empty if manager has never | |
197 | disconnected. | |
198 | </column> | |
199 | ||
200 | <column name="status" key="locks_held"> | |
201 | Space-separated list of the names of OVSDB locks that the connection | |
202 | holds. Omitted if the connection does not hold any locks. | |
203 | </column> | |
204 | ||
205 | <column name="status" key="locks_waiting"> | |
206 | Space-separated list of the names of OVSDB locks that the connection is | |
207 | currently waiting to acquire. Omitted if the connection is not waiting | |
208 | for any locks. | |
209 | </column> | |
210 | ||
211 | <column name="status" key="locks_lost"> | |
212 | Space-separated list of the names of OVSDB locks that the connection | |
213 | has had stolen by another OVSDB client. Omitted if no locks have been | |
214 | stolen from this connection. | |
215 | </column> | |
216 | ||
217 | <column name="status" key="n_connections" | |
218 | type='{"type": "integer", "minInteger": 2}'> | |
219 | <p> | |
220 | When <ref column="target"/> specifies a connection method that | |
221 | listens for inbound connections (e.g. <code>ptcp:</code> or | |
222 | <code>pssl:</code>) and more than one connection is actually active, | |
223 | the value is the number of active connections. Otherwise, this | |
224 | key-value pair is omitted. | |
225 | </p> | |
226 | <p> | |
227 | When multiple connections are active, status columns and key-value | |
228 | pairs (other than this one) report the status of one arbitrarily | |
229 | chosen connection. | |
230 | </p> | |
231 | </column> | |
232 | </group> | |
233 | ||
234 | <group title="Connection Parameters"> | |
235 | <p> | |
236 | Additional configuration for a connection between the manager | |
237 | and the database server. | |
238 | </p> | |
239 | ||
240 | <column name="other_config" key="dscp" | |
f86f54a9 | 241 | type='{"type": "integer"}'> |
add17b69 BD |
242 | The Differentiated Service Code Point (DSCP) is specified using 6 bits |
243 | in the Type of Service (TOS) field in the IP header. DSCP provides a | |
244 | mechanism to classify the network traffic and provide Quality of | |
245 | Service (QoS) on IP networks. | |
246 | ||
247 | The DSCP value specified here is used when establishing the | |
248 | connection between the manager and the database server. If no | |
249 | value is specified, a default value of 48 is chosen. Valid DSCP | |
250 | values must be in the range 0 to 63. | |
251 | </column> | |
252 | </group> | |
253 | </table> | |
254 | ||
255 | <table name="Physical_Switch" title="A physical switch."> | |
256 | A physical switch that implements a VTEP. | |
257 | ||
258 | <column name="ports"> | |
259 | The physical ports within the switch. | |
260 | </column> | |
261 | ||
c8f4eed5 AS |
262 | <column name="tunnels"> |
263 | Tunnels created by this switch as instructed by the NVC. | |
264 | </column> | |
265 | ||
add17b69 BD |
266 | <group title="Network Status"> |
267 | <column name="management_ips"> | |
268 | IPv4 or IPv6 addresses at which the switch may be contacted | |
269 | for management purposes. | |
270 | </column> | |
271 | ||
272 | <column name="tunnel_ips"> | |
273 | <p> | |
274 | IPv4 or IPv6 addresses on which the switch may originate or | |
275 | terminate tunnels. | |
276 | </p> | |
277 | ||
278 | <p> | |
279 | This column is intended to allow a <ref table="Manager"/> to | |
280 | determine the <ref table="Physical_Switch"/> that terminates | |
281 | the tunnel represented by a <ref table="Physical_Locator"/>. | |
282 | </p> | |
283 | </column> | |
284 | </group> | |
285 | ||
286 | <group title="Identification"> | |
287 | <column name="name"> | |
fdf059ff | 288 | Symbolic name for the switch, such as its hostname. |
add17b69 | 289 | </column> |
f86f54a9 | 290 | |
add17b69 | 291 | <column name="description"> |
fdf059ff BD |
292 | An extended description for the switch, such as its switch login |
293 | banner. | |
add17b69 BD |
294 | </column> |
295 | </group> | |
255842d9 BD |
296 | <group title="Error Notification"> |
297 | <p> | |
fdf059ff BD |
298 | An entry in this column indicates to the NVC that this switch |
299 | has encountered a fault. The switch must clear this column | |
300 | when the fault has been cleared. | |
255842d9 BD |
301 | </p> |
302 | ||
303 | <column name="switch_fault_status" key="mac_table_exhaustion"> | |
304 | Indicates that the switch has been unable to process MAC | |
305 | entries requested by the NVC due to lack of table resources. | |
306 | </column> | |
307 | ||
308 | <column name="switch_fault_status" key="tunnel_exhaustion"> | |
309 | Indicates that the switch has been unable to create tunnels | |
310 | requested by the NVC due to lack of resources. | |
311 | </column> | |
312 | ||
313 | <column name="switch_fault_status" key="unspecified_fault"> | |
314 | Indicates that an error has occurred in the switch but that no | |
315 | more specific information is available. | |
316 | </column> | |
317 | ||
318 | </group> | |
add17b69 BD |
319 | </table> |
320 | ||
c8f4eed5 AS |
321 | <table name="Tunnel" title="A tunnel created by a physical switch."> |
322 | A tunnel created by a <ref table="Physical_Switch"/>. | |
323 | ||
324 | <column name="local"> | |
325 | Tunnel end-point local to the physical switch. | |
326 | </column> | |
327 | ||
328 | <column name="remote"> | |
329 | Tunnel end-point remote to the physical switch. | |
330 | </column> | |
331 | ||
332 | <group title="Bidirectional Forwarding Detection (BFD)"> | |
333 | <p> | |
334 | BFD, defined in RFC 5880, allows point to point detection of | |
335 | connectivity failures by occasional transmission of BFD control | |
336 | messages. VTEPs are expected to implement BFD. | |
337 | </p> | |
338 | ||
339 | <p> | |
340 | BFD operates by regularly transmitting BFD control messages at a | |
341 | rate negotiated independently in each direction. Each endpoint | |
342 | specifies the rate at which it expects to receive control messages, | |
343 | and the rate at which it's willing to transmit them. An endpoint | |
344 | which fails to receive BFD control messages for a period of three | |
345 | times the expected reception rate will signal a connectivity | |
346 | fault. In the case of a unidirectional connectivity issue, the | |
347 | system not receiving BFD control messages will signal the problem | |
348 | to its peer in the messages it transmits. | |
349 | </p> | |
350 | ||
351 | <p> | |
352 | A hardware VTEP is expected to use BFD to determine reachability of | |
353 | devices at the end of the tunnels with which it exchanges data. This | |
354 | can enable the VTEP to choose a functioning service node among a set of | |
355 | service nodes providing high availability. It also enables the NVC to | |
356 | report the health status of tunnels. | |
357 | </p> | |
358 | ||
359 | <p> | |
19289787 | 360 | In many cases the BFD peer of a hardware VTEP will be an Open vSwitch |
c8f4eed5 AS |
361 | instance. The Open vSwitch implementation of BFD aims to comply |
362 | faithfully with the requirements put forth in RFC 5880. Open vSwitch | |
363 | does not implement the optional Authentication or ``Echo Mode'' | |
364 | features. | |
365 | </p> | |
366 | ||
367 | <group title="BFD Local Configuration"> | |
368 | <p> | |
369 | The HSC writes the key-value pairs in the | |
07bb41a9 | 370 | <ref column="bfd_config_local"/> column to specify the local |
c8f4eed5 AS |
371 | configurations to be used for BFD sessions on this tunnel. |
372 | </p> | |
373 | ||
374 | <column name="bfd_config_local" key="bfd_dst_mac"> | |
375 | Set to an Ethernet address in the form | |
376 | <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> | |
377 | to set the MAC expected as destination for received BFD packets. | |
16ee1400 | 378 | The default is <code>00:23:20:00:00:01</code>. |
c8f4eed5 AS |
379 | </column> |
380 | ||
381 | <column name="bfd_config_local" key="bfd_dst_ip"> | |
382 | Set to an IPv4 address to set the IP address that is expected as destination | |
383 | for received BFD packets. The default is <code>169.254.1.0</code>. | |
384 | </column> | |
385 | ||
386 | </group> | |
387 | ||
388 | <group title="BFD Remote Configuration"> | |
389 | <p> | |
390 | The <ref column="bfd_config_remote"/> column is the remote | |
391 | counterpart of the <ref column="bfd_config_local"/> column. | |
392 | The NVC writes the key-value pairs in this column. | |
393 | </p> | |
394 | ||
395 | <column name="bfd_config_remote" key="bfd_dst_mac"> | |
396 | Set to an Ethernet address in the form | |
397 | <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> | |
398 | to set the destination MAC to be used for transmitted BFD packets. | |
399 | The default is <code>00:23:20:00:00:01</code>. | |
400 | </column> | |
401 | ||
402 | <column name="bfd_config_remote" key="bfd_dst_ip"> | |
403 | Set to an IPv4 address to set the IP address used as destination | |
404 | for transmitted BFD packets. The default is <code>169.254.1.1</code>. | |
405 | </column> | |
406 | ||
407 | </group> | |
408 | ||
409 | <group title="BFD Parameters"> | |
410 | <p> | |
411 | The NVC sets up key-value pairs in the <ref column="bfd_params"/> | |
412 | column to enable and configure BFD. | |
413 | </p> | |
414 | ||
415 | <column name="bfd_params" key="enable" type='{"type": "boolean"}'> | |
19289787 AT |
416 | True to enable BFD on this <ref table="Tunnel"/>. If not |
417 | specified, BFD will not be enabled by default. | |
c8f4eed5 AS |
418 | </column> |
419 | ||
420 | <column name="bfd_params" key="min_rx" | |
421 | type='{"type": "integer", "minInteger": 1}'> | |
422 | The shortest interval, in milliseconds, at which this BFD session | |
423 | offers to receive BFD control messages. The remote endpoint may | |
424 | choose to send messages at a slower rate. Defaults to | |
425 | <code>1000</code>. | |
426 | </column> | |
427 | ||
428 | <column name="bfd_params" key="min_tx" | |
429 | type='{"type": "integer", "minInteger": 1}'> | |
430 | The shortest interval, in milliseconds, at which this BFD session is | |
431 | willing to transmit BFD control messages. Messages will actually be | |
432 | transmitted at a slower rate if the remote endpoint is not willing to | |
433 | receive as quickly as specified. Defaults to <code>100</code>. | |
434 | </column> | |
435 | ||
436 | <column name="bfd_params" key="decay_min_rx" type='{"type": "integer"}'> | |
437 | An alternate receive interval, in milliseconds, that must be greater | |
19289787 AT |
438 | than or equal to <ref column="bfd_params" key="min_rx"/>. The |
439 | implementation should switch from <ref column="bfd_params" key="min_rx"/> | |
440 | to <ref column="bfd_params" key="decay_min_rx"/> when there is no obvious | |
441 | incoming data traffic at the tunnel, to reduce the CPU and bandwidth | |
442 | cost of monitoring an idle tunnel. This feature may be disabled by | |
443 | setting a value of 0. This feature is reset whenever | |
444 | <ref column="bfd_params" key="decay_min_rx"/> or | |
445 | <ref column="bfd_params" key="min_rx"/> changes. | |
c8f4eed5 AS |
446 | </column> |
447 | ||
448 | <column name="bfd_params" key="forwarding_if_rx" type='{"type": "boolean"}'> | |
19289787 AT |
449 | When <code>true</code>, traffic received on the <ref table="Tunnel"/> |
450 | is used to indicate the capability of packet I/O. | |
451 | BFD control packets are still transmitted and received. At least one | |
452 | BFD control packet must be received every | |
453 | 100 * <ref column="bfd_params" key="min_rx"/> amount of time. | |
454 | Otherwise, even if traffic is received, the | |
455 | <ref column="bfd_params" key="forwarding"/> will be <code>false</code>. | |
c8f4eed5 AS |
456 | </column> |
457 | ||
458 | <column name="bfd_params" key="cpath_down" type='{"type": "boolean"}'> | |
459 | Set to true to notify the remote endpoint that traffic should not be | |
07bb41a9 | 460 | forwarded to this system for some reason other than a connectivity |
c8f4eed5 AS |
461 | failure on the interface being monitored. The typical underlying |
462 | reason is ``concatenated path down,'' that is, that connectivity | |
463 | beyond the local system is down. Defaults to false. | |
464 | </column> | |
465 | ||
466 | <column name="bfd_params" key="check_tnl_key" type='{"type": "boolean"}'> | |
467 | Set to true to make BFD accept only control messages with a tunnel | |
468 | key of zero. By default, BFD accepts control messages with any | |
469 | tunnel key. | |
470 | </column> | |
471 | ||
472 | </group> | |
473 | ||
19289787 AT |
474 | <group title="BFD Status"> |
475 | <p> | |
476 | The VTEP sets key-value pairs in the <ref column="bfd_status"/> | |
477 | column to report the status of BFD on this tunnel. When BFD is | |
478 | not enabled, with <ref column="bfd_params" key="enable"/>, the | |
479 | HSC clears all key-value pairs from <ref column="bfd_status"/>. | |
480 | </p> | |
c8f4eed5 | 481 | |
19289787 AT |
482 | <column name="bfd_status" key="enabled" type='{"type": "boolean"}'> |
483 | Set to true if the BFD session has been successfully enabled. | |
484 | Set to false if the VTEP cannot support BFD or has insufficient | |
485 | resources to enable BFD on this tunnel. The NVC will disable | |
486 | the BFD monitoring on the other side of the tunnel once this | |
487 | value is set to false. | |
488 | </column> | |
16ee1400 | 489 | |
19289787 AT |
490 | <column name="bfd_status" key="state" |
491 | type='{"type": "string", | |
c8f4eed5 | 492 | "enum": ["set", ["admin_down", "down", "init", "up"]]}'> |
19289787 AT |
493 | Reports the state of the BFD session. The BFD session is fully |
494 | healthy and negotiated if <code>UP</code>. | |
495 | </column> | |
c8f4eed5 | 496 | |
19289787 AT |
497 | <column name="bfd_status" key="forwarding" type='{"type": "boolean"}'> |
498 | Reports whether the BFD session believes this <ref table="Tunnel"/> | |
499 | may be used to forward traffic. Typically this means the local session | |
500 | is signaling <code>UP</code>, and the remote system isn't signaling a | |
501 | problem such as concatenated path down. | |
502 | </column> | |
c8f4eed5 | 503 | |
19289787 AT |
504 | <column name="bfd_status" key="diagnostic"> |
505 | A diagnostic code specifying the local system's reason for the | |
506 | last change in session state. The error messages are defined in | |
507 | section 4.1 of [RFC 5880]. | |
508 | </column> | |
c8f4eed5 | 509 | |
19289787 AT |
510 | <column name="bfd_status" key="remote_state" |
511 | type='{"type": "string", | |
c8f4eed5 | 512 | "enum": ["set", ["admin_down", "down", "init", "up"]]}'> |
19289787 AT |
513 | Reports the state of the remote endpoint's BFD session. |
514 | </column> | |
c8f4eed5 | 515 | |
19289787 AT |
516 | <column name="bfd_status" key="remote_diagnostic"> |
517 | A diagnostic code specifying the remote system's reason for the | |
518 | last change in session state. The error messages are defined in | |
519 | section 4.1 of [RFC 5880]. | |
520 | </column> | |
16ee1400 | 521 | |
19289787 AT |
522 | <column name="bfd_status" key="info"> |
523 | A short message providing further information about the BFD status | |
524 | (possibly including reasons why BFD could not be enabled). | |
525 | </column> | |
c8f4eed5 AS |
526 | </group> |
527 | </group> | |
528 | </table> | |
529 | ||
add17b69 BD |
530 | <table name="Physical_Port" title="A port within a physical switch."> |
531 | A port within a <ref table="Physical_Switch"/>. | |
532 | ||
533 | <column name="vlan_bindings"> | |
534 | Identifies how VLANs on the physical port are bound to logical switches. | |
535 | If, for example, the map contains a (VLAN, logical switch) pair, a packet | |
536 | that arrives on the port in the VLAN is considered to belong to the | |
b49f5f7a BD |
537 | paired logical switch. A value of zero in the VLAN field means |
538 | that untagged traffic on the physical port is mapped to the | |
539 | logical switch. | |
add17b69 BD |
540 | </column> |
541 | ||
c0c1dccb BD |
542 | <column name="acl_bindings"> |
543 | <p> | |
544 | Attach Access Control Lists (ACLs) to the physical port. The | |
545 | column consists of a map of VLAN tags to <ref table="ACL"/>s. If the value of | |
546 | the VLAN tag in the map is 0, this means that the ACL is | |
547 | associated with the entire physical port. Non-zero values mean | |
548 | that the ACL is to be applied only on packets carrying that VLAN | |
549 | tag value. Switches will not necessarily support matching on the | |
550 | VLAN tag for all ACLs, and unsupported ACL bindings will cause | |
551 | errors to be reported. The binding of an ACL to a specific | |
552 | VLAN and the binding of an ACL to the entire physical port | |
553 | should not be combined on a single physical port. That is, a | |
554 | mix of zero and non-zero keys in the map is not recommended. | |
555 | </p> | |
556 | </column> | |
557 | ||
add17b69 BD |
558 | <column name="vlan_stats"> |
559 | Statistics for VLANs bound to logical switches on the physical port. An | |
560 | implementation that fully supports such statistics would populate this | |
561 | column with a mapping for every VLAN that is bound in <ref | |
562 | column="vlan_bindings"/>. An implementation that does not support such | |
563 | statistics or only partially supports them would not populate this column | |
b49f5f7a BD |
564 | or partially populate it, respectively. A value of zero in the |
565 | VLAN field refers to untagged traffic on the physical port. | |
add17b69 BD |
566 | </column> |
567 | ||
568 | <group title="Identification"> | |
569 | <column name="name"> | |
fdf059ff BD |
570 | Symbolic name for the port. The name ought to be unique within a given |
571 | <ref table="Physical_Switch"/>, but the database is not capable of | |
572 | enforcing this. | |
add17b69 BD |
573 | </column> |
574 | ||
575 | <column name="description"> | |
fdf059ff | 576 | An extended description for the port. |
add17b69 BD |
577 | </column> |
578 | </group> | |
255842d9 BD |
579 | <group title="Error Notification"> |
580 | <p> | |
fdf059ff | 581 | An entry in this column indicates to the NVC that the physical port has |
07bb41a9 | 582 | encountered a fault. The switch must clear this column when the error |
fdf059ff | 583 | has been cleared. |
255842d9 BD |
584 | </p> |
585 | <column name="port_fault_status" key="invalid_vlan_map"> | |
fdf059ff BD |
586 | <p> |
587 | Indicates that a VLAN-to-logical-switch mapping requested by | |
588 | the controller could not be instantiated by the switch | |
589 | because of a conflict with local configuration. | |
590 | </p> | |
255842d9 | 591 | </column> |
c0c1dccb BD |
592 | <column name="port_fault_status" key="invalid_ACL_binding"> |
593 | <p> | |
594 | Indicates that an error has occurred in associating an ACL | |
595 | with a port. | |
596 | </p> | |
597 | </column> | |
255842d9 | 598 | <column name="port_fault_status" key="unspecified_fault"> |
fdf059ff BD |
599 | <p> |
600 | Indicates that an error has occurred on the port but that no | |
601 | more specific information is available. | |
602 | </p> | |
255842d9 BD |
603 | </column> |
604 | </group> | |
605 | ||
add17b69 BD |
606 | </table> |
607 | ||
608 | <table name="Logical_Binding_Stats" title="Statistics for a VLAN on a physical port bound to a logical network."> | |
609 | Reports statistics for the <ref table="Logical_Switch"/> with which a VLAN | |
610 | on a <ref table="Physical_Port"/> is associated. | |
611 | ||
612 | <group title="Statistics"> | |
613 | These statistics count only packets to which the binding applies. | |
614 | ||
615 | <column name="packets_from_local"> | |
616 | Number of packets sent by the <ref table="Physical_Switch"/>. | |
617 | </column> | |
618 | ||
619 | <column name="bytes_from_local"> | |
620 | Number of bytes in packets sent by the <ref table="Physical_Switch"/>. | |
621 | </column> | |
622 | ||
623 | <column name="packets_to_local"> | |
624 | Number of packets received by the <ref table="Physical_Switch"/>. | |
625 | </column> | |
626 | ||
627 | <column name="bytes_to_local"> | |
628 | Number of bytes in packets received by the <ref | |
629 | table="Physical_Switch"/>. | |
630 | </column> | |
631 | </group> | |
632 | </table> | |
633 | ||
634 | <table name="Logical_Switch" title="A layer-2 domain."> | |
635 | A logical Ethernet switch, whose implementation may span physical and | |
636 | virtual media, possibly crossing L3 domains via tunnels; a logical layer-2 | |
637 | domain; an Ethernet broadcast domain. | |
638 | ||
639 | ||
640 | ||
641 | <group title="Per Logical-Switch Tunnel Key"> | |
642 | <p> | |
643 | Tunnel protocols tend to have a field that allows the tunnel | |
644 | to be partitioned into sub-tunnels: VXLAN has a VNI, GRE and | |
645 | STT have a key, CAPWAP has a WSI, and so on. We call these | |
646 | generically ``tunnel keys.'' Given that one needs to use a | |
647 | tunnel key at all, there are at least two reasonable ways to | |
648 | assign their values: | |
649 | </p> | |
650 | ||
651 | <ul> | |
652 | <li> | |
653 | <p> | |
654 | Per <ref table="Logical_Switch"/>+<ref table="Physical_Locator"/> | |
655 | pair. That is, each logical switch may be assigned a different | |
656 | tunnel key on every <ref table="Physical_Locator"/>. This model is | |
657 | especially flexible. | |
658 | </p> | |
659 | ||
660 | <p> | |
661 | In this model, <ref table="Physical_Locator"/> carries the tunnel | |
662 | key. Therefore, one <ref table="Physical_Locator"/> record will | |
663 | exist for each logical switch carried at a given IP destination. | |
664 | </p> | |
665 | </li> | |
666 | ||
667 | <li> | |
668 | <p> | |
669 | Per <ref table="Logical_Switch"/>. That is, every tunnel | |
670 | associated with a particular logical switch carries the same tunnel | |
671 | key, regardless of the <ref table="Physical_Locator"/> to which the | |
672 | tunnel is addressed. This model may ease switch implementation | |
673 | because it imposes fewer requirements on the hardware datapath. | |
674 | </p> | |
675 | ||
676 | <p> | |
677 | In this model, <ref table="Logical_Switch"/> carries the tunnel | |
678 | key. Therefore, one <ref table="Physical_Locator"/> record will | |
679 | exist for each IP destination. | |
680 | </p> | |
681 | </li> | |
682 | </ul> | |
683 | ||
684 | <column name="tunnel_key"> | |
685 | <p> | |
686 | This column is used only in the tunnel key per <ref | |
687 | table="Logical_Switch"/> model (see above), because only in that | |
688 | model is there a tunnel key associated with a logical switch. | |
689 | </p> | |
690 | ||
691 | <p> | |
692 | For <code>vxlan_over_ipv4</code> encapsulation, this column | |
693 | is the VXLAN VNI that identifies a logical switch. It must | |
694 | be in the range 0 to 16,777,215. | |
695 | </p> | |
696 | </column> | |
697 | </group> | |
698 | ||
699 | <group title="Identification"> | |
700 | <column name="name"> | |
fdf059ff | 701 | Symbolic name for the logical switch. |
add17b69 | 702 | </column> |
f86f54a9 | 703 | |
add17b69 | 704 | <column name="description"> |
fdf059ff BD |
705 | An extended description for the logical switch, such as its switch |
706 | login banner. | |
add17b69 BD |
707 | </column> |
708 | </group> | |
709 | </table> | |
710 | ||
711 | <table name="Ucast_Macs_Local" title="Unicast MACs (local)"> | |
712 | <p> | |
713 | Mapping of unicast MAC addresses to tunnels (physical | |
714 | locators). This table is written by the HSC, so it contains the | |
715 | MAC addresses that have been learned on physical ports by a | |
716 | VTEP. | |
717 | </p> | |
718 | ||
719 | <column name="MAC"> | |
720 | A MAC address that has been learned by the VTEP. | |
721 | </column> | |
722 | ||
723 | <column name="logical_switch"> | |
724 | The Logical switch to which this mapping applies. | |
725 | </column> | |
726 | ||
727 | <column name="locator"> | |
728 | The physical locator to be used to reach this MAC address. In | |
729 | this table, the physical locator will be one of the tunnel IP | |
730 | addresses of the appropriate VTEP. | |
731 | </column> | |
732 | ||
733 | <column name="ipaddr"> | |
734 | The IP address to which this MAC corresponds. Optional field for | |
735 | the purpose of ARP supression. | |
736 | </column> | |
737 | ||
738 | </table> | |
739 | ||
f86f54a9 | 740 | <table name="Ucast_Macs_Remote" title="Unicast MACs (remote)"> |
add17b69 BD |
741 | <p> |
742 | Mapping of unicast MAC addresses to tunnels (physical | |
743 | locators). This table is written by the NVC, so it contains the | |
744 | MAC addresses that the NVC has learned. These include VM MAC | |
745 | addresses, in which case the physical locators will be | |
746 | hypervisor IP addresses. The NVC will also report MACs that it | |
747 | has learned from other HSCs in the network, in which case the | |
748 | physical locators will be tunnel IP addresses of the | |
749 | corresponding VTEPs. | |
750 | </p> | |
751 | ||
752 | <column name="MAC"> | |
255842d9 | 753 | A MAC address that has been learned by the NVC. |
add17b69 BD |
754 | </column> |
755 | ||
756 | <column name="logical_switch"> | |
757 | The Logical switch to which this mapping applies. | |
758 | </column> | |
759 | ||
760 | <column name="locator"> | |
761 | The physical locator to be used to reach this MAC address. In | |
762 | this table, the physical locator will be either a hypervisor IP | |
763 | address or a tunnel IP addresses of another VTEP. | |
764 | </column> | |
765 | ||
766 | <column name="ipaddr"> | |
767 | The IP address to which this MAC corresponds. Optional field for | |
768 | the purpose of ARP supression. | |
769 | </column> | |
770 | ||
771 | </table> | |
772 | ||
773 | <table name="Mcast_Macs_Local" title="Multicast MACs (local)"> | |
774 | <p> | |
775 | Mapping of multicast MAC addresses to tunnels (physical | |
776 | locators). This table is written by the HSC, so it contains the | |
777 | MAC addresses that have been learned on physical ports by a | |
778 | VTEP. These may be learned by IGMP snooping, for example. This | |
779 | table also specifies how to handle unknown unicast and broadcast packets. | |
780 | </p> | |
781 | ||
782 | <column name="MAC"> | |
783 | <p> | |
f86f54a9 | 784 | A MAC address that has been learned by the VTEP. |
add17b69 BD |
785 | </p> |
786 | <p> | |
fdf059ff BD |
787 | The keyword <code>unknown-dst</code> is used as a special |
788 | ``Ethernet address'' that indicates the locations to which | |
789 | packets in a logical switch whose destination addresses do not | |
790 | otherwise appear in <ref table="Ucast_Macs_Local"/> (for | |
791 | unicast addresses) or <ref table="Mcast_Macs_Local"/> (for | |
792 | multicast addresses) should be sent. | |
add17b69 BD |
793 | </p> |
794 | </column> | |
795 | ||
796 | <column name="logical_switch"> | |
797 | The Logical switch to which this mapping applies. | |
798 | </column> | |
799 | ||
800 | <column name="locator_set"> | |
801 | The physical locator set to be used to reach this MAC address. In | |
802 | this table, the physical locator set will be contain one or more tunnel IP | |
803 | addresses of the appropriate VTEP(s). | |
804 | </column> | |
805 | ||
19368978 BP |
806 | <column name="ipaddr"> |
807 | The IP address to which this MAC corresponds. Optional field for | |
808 | the purpose of ARP supression. | |
809 | </column> | |
add17b69 BD |
810 | </table> |
811 | ||
812 | <table name="Mcast_Macs_Remote" title="Multicast MACs (remote)"> | |
813 | <p> | |
814 | Mapping of multicast MAC addresses to tunnels (physical | |
815 | locators). This table is written by the NVC, so it contains the | |
816 | MAC addresses that the NVC has learned. This | |
817 | table also specifies how to handle unknown unicast and broadcast | |
818 | packets. | |
819 | </p> | |
820 | <p> | |
821 | Multicast packet replication may be handled by a service node, | |
822 | in which case the physical locators will be IP addresses of | |
823 | service nodes. If the VTEP supports replication onto multiple | |
824 | tunnels, then this may be used to replicate directly onto | |
07bb41a9 | 825 | VTEP-hypervisor tunnels. |
add17b69 BD |
826 | </p> |
827 | ||
828 | <column name="MAC"> | |
829 | <p> | |
fdf059ff | 830 | A MAC address that has been learned by the NVC. |
add17b69 BD |
831 | </p> |
832 | <p> | |
fdf059ff BD |
833 | The keyword <code>unknown-dst</code> is used as a special |
834 | ``Ethernet address'' that indicates the locations to which | |
835 | packets in a logical switch whose destination addresses do not | |
836 | otherwise appear in <ref table="Ucast_Macs_Remote"/> (for | |
837 | unicast addresses) or <ref table="Mcast_Macs_Remote"/> (for | |
838 | multicast addresses) should be sent. | |
add17b69 BD |
839 | </p> |
840 | </column> | |
841 | ||
842 | <column name="logical_switch"> | |
843 | The Logical switch to which this mapping applies. | |
844 | </column> | |
845 | ||
846 | <column name="locator_set"> | |
847 | The physical locator set to be used to reach this MAC address. In | |
848 | this table, the physical locator set will be either a service node IP | |
849 | address or a set of tunnel IP addresses of hypervisors (and | |
850 | potentially other VTEPs). | |
851 | </column> | |
852 | ||
853 | <column name="ipaddr"> | |
854 | The IP address to which this MAC corresponds. Optional field for | |
855 | the purpose of ARP supression. | |
856 | </column> | |
857 | ||
858 | </table> | |
859 | ||
860 | <table name="Logical_Router" title="A logical L3 router."> | |
861 | <p> | |
862 | A logical router, or VRF. A logical router may be connected to one or more | |
f86f54a9 | 863 | logical switches. Subnet addresses and interface addresses may be configured on the |
add17b69 BD |
864 | interfaces. |
865 | </p> | |
f86f54a9 | 866 | |
add17b69 BD |
867 | <column name="switch_binding"> |
868 | Maps from an IPv4 or IPv6 address prefix in CIDR notation to a | |
869 | logical switch. Multiple prefixes may map to the same switch. By | |
870 | writing a 32-bit (or 128-bit for v6) address with a /N prefix | |
871 | length, both the router's interface address and the subnet | |
872 | prefix can be configured. For example, 192.68.1.1/24 creates a | |
873 | /24 subnet for the logical switch attached to the interface and | |
874 | assigns the address 192.68.1.1 to the router interface. | |
875 | </column> | |
876 | ||
877 | <column name="static_routes"> | |
878 | One or more static routes, mapping IP prefixes to next hop IP addresses. | |
879 | </column> | |
880 | ||
c0c1dccb BD |
881 | <column name="acl_binding"> |
882 | Maps ACLs to logical router interfaces. The router interfaces | |
883 | are indicated using IP address notation, and must be the same | |
884 | interfaces created in the <ref column="switch_binding"/> | |
885 | column. For example, an ACL could be associated with the logical | |
886 | router interface with an address of 192.68.1.1 as defined in the | |
887 | example above. | |
888 | </column> | |
889 | ||
add17b69 BD |
890 | <group title="Identification"> |
891 | <column name="name"> | |
fdf059ff | 892 | Symbolic name for the logical router. |
add17b69 BD |
893 | </column> |
894 | ||
895 | <column name="description"> | |
fdf059ff | 896 | An extended description for the logical router. |
add17b69 BD |
897 | </column> |
898 | </group> | |
c0c1dccb BD |
899 | |
900 | <group title="Error Notification"> | |
901 | <p> | |
902 | An entry in this column indicates to the NVC that the HSC has | |
903 | encountered a fault in configuring state related to the | |
904 | logical router. | |
905 | </p> | |
906 | <column name="LR_fault_status" key="invalid_ACL_binding"> | |
907 | <p> | |
908 | Indicates that an error has occurred in associating an ACL | |
909 | with a logical router port. | |
910 | </p> | |
911 | </column> | |
912 | <column name="LR_fault_status" key="unspecified_fault"> | |
913 | <p> | |
914 | Indicates that an error has occurred in configuring the | |
915 | logical router but that no | |
916 | more specific information is available. | |
917 | </p> | |
918 | </column> | |
919 | </group> | |
920 | ||
add17b69 BD |
921 | </table> |
922 | ||
7ae92590 BD |
923 | <table name="Arp_Sources_Local" title="ARP source addresses for logical routers"> |
924 | <p> | |
925 | MAC address to be used when a VTEP issues ARP requests on behalf | |
926 | of a logical router. | |
927 | </p> | |
928 | ||
929 | <p> | |
930 | A distributed logical router is implemented by a set of VTEPs | |
931 | (both hardware VTEPs and vswitches). In order for a given VTEP | |
932 | to populate the local ARP cache for a logical router, it issues | |
933 | ARP requests with a source MAC address that is unique to the VTEP. A | |
934 | single per-VTEP MAC can be re-used across all logical | |
935 | networks. This table contains the MACs that are used by the | |
936 | VTEPs of a given HSC. The table provides the mapping from MAC to | |
937 | physical locator for each VTEP so that replies to the ARP | |
938 | requests can be sent back to the correct VTEP using the | |
939 | appropriate physical locator. | |
940 | </p> | |
941 | ||
942 | <column name="src_mac"> | |
943 | The source MAC to be used by a given VTEP. | |
944 | </column> | |
945 | ||
946 | <column name="locator"> | |
947 | The <ref table="Physical_Locator"/> to use for replies to ARP | |
948 | requests from this MAC address. | |
949 | </column> | |
950 | </table> | |
951 | ||
952 | <table name="Arp_Sources_Remote" title="ARP source addresses for logical routers"> | |
953 | <p> | |
954 | MAC address to be used when a remote VTEP issues ARP requests on behalf | |
955 | of a logical router. | |
956 | </p> | |
957 | ||
958 | <p> | |
959 | This table is the remote counterpart of <ref | |
960 | table="Arp_sources_local"/>. The NVC writes this table to notify | |
961 | the HSC of the MACs that will be used by remote VTEPs when they | |
962 | issue ARP requests on behalf of a distributed logical router. | |
963 | </p> | |
964 | ||
965 | <column name="src_mac"> | |
966 | The source MAC to be used by a given VTEP. | |
967 | </column> | |
968 | ||
969 | <column name="locator"> | |
970 | The <ref table="Physical_Locator"/> to use for replies to ARP | |
971 | requests from this MAC address. | |
972 | </column> | |
973 | </table> | |
974 | ||
add17b69 BD |
975 | <table name="Physical_Locator_Set"> |
976 | <p> | |
977 | A set of one or more <ref table="Physical_Locator"/>s. | |
978 | </p> | |
979 | ||
980 | <p> | |
981 | This table exists only because OVSDB does not have a way to | |
982 | express the type ``map from string to one or more <ref | |
983 | table="Physical_Locator"/> records.'' | |
984 | </p> | |
985 | ||
f86f54a9 | 986 | <column name="locators"/> |
add17b69 BD |
987 | </table> |
988 | ||
989 | <table name="Physical_Locator"> | |
990 | <p> | |
991 | Identifies an endpoint to which logical switch traffic may be | |
992 | encapsulated and forwarded. | |
993 | </p> | |
994 | ||
995 | <p> | |
996 | For the <code>vxlan_over_ipv4</code> encapsulation, the only | |
997 | encapsulation defined so far, all endpoints associated with a given <ref | |
998 | table="Logical_Switch"/> must use a common tunnel key, which is carried | |
999 | in the <ref table="Logical_Switch" column="tunnel_key"/> column of <ref | |
1000 | table="Logical_Switch"/>. | |
1001 | </p> | |
1002 | ||
1003 | <p> | |
1004 | For some encapsulations yet to be defined, we expect <ref | |
1005 | table="Physical_Locator"/> to identify both an endpoint and a tunnel key. | |
1006 | When the first such encapsulation is defined, we expect to add a | |
1007 | ``tunnel_key'' column to <ref table="Physical_Locator"/> to allow the | |
1008 | tunnel key to be defined. | |
1009 | </p> | |
1010 | ||
1011 | <p> | |
1012 | See the ``Per Logical-Switch Tunnel Key'' section in the <ref | |
1013 | table="Logical_Switch"/> table for further discussion of the model. | |
1014 | </p> | |
1015 | ||
1016 | <column name="encapsulation_type"> | |
1017 | The type of tunneling encapsulation. | |
1018 | </column> | |
1019 | ||
1020 | <column name="dst_ip"> | |
1021 | <p> | |
1022 | For <code>vxlan_over_ipv4</code> encapsulation, the IPv4 address of the | |
1023 | VXLAN tunnel endpoint. | |
1024 | </p> | |
1025 | ||
1026 | <p> | |
1027 | We expect that this column could be used for IPv4 or IPv6 addresses in | |
1028 | encapsulations to be introduced later. | |
1029 | </p> | |
1030 | </column> | |
23f781e4 | 1031 | |
add17b69 | 1032 | </table> |
c0c1dccb BD |
1033 | <table name="ACL_entry"> |
1034 | <p> | |
1035 | Describes the individual entries that comprise an Access Control List. | |
1036 | </p> | |
1037 | <p> | |
1038 | Each entry in the table is a single rule to match on certain | |
1039 | header fields. While there are a large number of fields that can | |
1040 | be matched on, most hardware cannot match on arbitrary | |
1041 | combinations of fields. It is common to match on either L2 | |
1042 | fields (described below in the L2 group of columns) or L3/L4 fields | |
1043 | (the L3/L4 group of columns) but not both. The hardware switch | |
1044 | controller may log an error if an ACL entry requires it to match | |
1045 | on an incompatible mixture of fields. | |
1046 | </p> | |
1047 | <column name="sequence"> | |
1048 | <p> | |
1049 | The sequence number for the ACL entry for the purpose of | |
1050 | ordering entries in an ACL. Lower numbered entries are matched | |
1051 | before higher numbered entries. | |
1052 | </p> | |
1053 | </column> | |
1054 | <group title="L2 fields"> | |
1055 | <column name="source_mac"> | |
1056 | <p> | |
1057 | Source MAC address, in the form | |
1058 | <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> | |
1059 | </p> | |
1060 | </column> | |
1061 | <column name="dest_mac"> | |
1062 | <p> | |
1063 | Destination MAC address, in the form | |
1064 | <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> | |
1065 | </p> | |
1066 | </column> | |
f86f54a9 | 1067 | <column name="ethertype"> |
c0c1dccb BD |
1068 | <p> |
1069 | Ethertype in hexadecimal, in the form | |
1070 | <var>0xAAAA</var> | |
1071 | </p> | |
1072 | </column> | |
1073 | </group> | |
1074 | <group title="L3/L4 fields"> | |
1075 | <column name="source_ip"> | |
1076 | <p> | |
1077 | Source IP address, in the form | |
1078 | <var>xx.xx.xx.xx</var> for IPv4 or appropriate | |
1079 | colon-separated hexadecimal notation for IPv6. | |
1080 | </p> | |
1081 | </column> | |
1082 | <column name="source_mask"> | |
1083 | <p> | |
1084 | Mask that determines which bits of source_ip to match on, in the form | |
1085 | <var>xx.xx.xx.xx</var> for IPv4 or appropriate | |
1086 | colon-separated hexadecimal notation for IPv6. | |
1087 | </p> | |
1088 | </column> | |
1089 | <column name="dest_ip"> | |
1090 | <p> | |
1091 | Destination IP address, in the form | |
1092 | <var>xx.xx.xx.xx</var> for IPv4 or appropriate | |
1093 | colon-separated hexadecimal notation for IPv6. | |
1094 | </p> | |
1095 | </column> | |
1096 | <column name="dest_mask"> | |
1097 | <p> | |
1098 | Mask that determines which bits of dest_ip to match on, in the form | |
1099 | <var>xx.xx.xx.xx</var> for IPv4 or appropriate | |
1100 | colon-separated hexadecimal notation for IPv6. | |
1101 | </p> | |
1102 | </column> | |
1103 | <column name="protocol"> | |
1104 | <p> | |
1105 | Protocol number in the IPv4 header, or value of the "next | |
1106 | header" field in the IPv6 header. | |
1107 | </p> | |
1108 | </column> | |
1109 | <column name="source_port_min"> | |
1110 | <p> | |
1111 | Lower end of the range of source port values. The value | |
1112 | specified is included in the range. | |
1113 | </p> | |
1114 | </column> | |
1115 | <column name="source_port_max"> | |
1116 | <p> | |
1117 | Upper end of the range of source port values. The value | |
1118 | specified is included in the range. | |
1119 | </p> | |
1120 | </column> | |
1121 | <column name="dest_port_min"> | |
1122 | <p> | |
1123 | Lower end of the range of destination port values. The value | |
1124 | specified is included in the range. | |
1125 | </p> | |
1126 | </column> | |
1127 | <column name="dest_port_max"> | |
1128 | <p> | |
1129 | Upper end of the range of destination port values. The value | |
1130 | specified is included in the range. | |
1131 | </p> | |
1132 | </column> | |
1133 | <column name="tcp_flags"> | |
1134 | <p> | |
1135 | Integer representing the value of TCP flags to match. For | |
1136 | example, the SYN flag is the second least significant bit in | |
1137 | the TCP flags. Hence a value of 2 would indicate that the "SYN" | |
1138 | flag should be set (assuming an appropriate mask). | |
1139 | </p> | |
1140 | </column> | |
1141 | <column name="tcp_flags_mask"> | |
1142 | <p> | |
1143 | Integer representing the mask to apply when matching TCP | |
1144 | flags. For example, a value of 2 would imply that the "SYN" | |
1145 | flag should be matched and all other flags ignored. | |
1146 | </p> | |
1147 | </column> | |
1148 | <column name="icmp_type"> | |
1149 | <p> | |
1150 | ICMP type to be matched. | |
1151 | </p> | |
1152 | </column> | |
1153 | <column name="icmp_code"> | |
1154 | <p> | |
1155 | ICMP code to be matched. | |
1156 | </p> | |
1157 | </column> | |
1158 | </group> | |
1159 | <column name="direction"> | |
1160 | <p> | |
1161 | Direction of traffic to match on the specified port, either | |
1162 | "ingress" (toward the logical switch or router) or "egress" | |
1163 | (leaving the logical switch or router). | |
1164 | </p> | |
1165 | </column> | |
1166 | <column name="action"> | |
1167 | <p> | |
1168 | Action to take for this rule, either "permit" or "deny". | |
1169 | </p> | |
1170 | </column> | |
1171 | <group title="Error Notification"> | |
1172 | <p> | |
1173 | An entry in this column indicates to the NVC that the ACL | |
1174 | could not be configured as requested. The switch must clear this column when the error | |
1175 | has been cleared. | |
1176 | </p> | |
1177 | <column name="acle_fault_status" key="invalid_acl_entry"> | |
1178 | <p> | |
1179 | Indicates that an ACL entry requested by | |
1180 | the controller could not be instantiated by the switch, | |
1181 | e.g. because it requires an unsupported combination of | |
1182 | fields to be matched. | |
1183 | </p> | |
1184 | </column> | |
1185 | <column name="acle_fault_status" key="unspecified_fault"> | |
1186 | <p> | |
1187 | Indicates that an error has occurred in configuring the ACL | |
1188 | entry but no | |
1189 | more specific information is available. | |
1190 | </p> | |
1191 | </column> | |
1192 | </group> | |
1193 | </table> | |
1194 | <table name="ACL"> | |
1195 | <p> | |
1196 | Access Control List table. Each ACL is constructed as a set of | |
1197 | entries from the <ref table="ACL_entry"/> table. Packets that | |
1198 | are not matched by any entry in the ACL are allowed by default. | |
1199 | </p> | |
1200 | <column name="acl_entries"> | |
1201 | <p> | |
1202 | A set of references to entries in the <ref table="ACL_entry"/> table. | |
1203 | </p> | |
1204 | </column> | |
1205 | <column name="acl_name"> | |
1206 | <p> | |
1207 | A human readable name for the ACL, which may (for example) be displayed on | |
1208 | the switch CLI. | |
1209 | </p> | |
1210 | </column> | |
1211 | <group title="Error Notification"> | |
1212 | <p> | |
1213 | An entry in this column indicates to the NVC that the ACL | |
1214 | could not be configured as requested. The switch must clear this column when the error | |
1215 | has been cleared. | |
1216 | </p> | |
1217 | <column name="acl_fault_status" key="invalid_acl"> | |
1218 | <p> | |
1219 | Indicates that an ACL requested by | |
1220 | the controller could not be instantiated by the switch, | |
1221 | e.g., because it requires an unsupported combination of | |
1222 | fields to be matched. | |
1223 | </p> | |
1224 | </column> | |
1225 | <column name="acl_fault_status" key="resource_shortage"> | |
1226 | <p> | |
1227 | Indicates that an ACL requested by | |
1228 | the controller could not be instantiated by the switch due | |
1229 | to a shortage of resources (e.g. TCAM space). | |
1230 | </p> | |
1231 | </column> | |
1232 | <column name="acl_fault_status" key="unspecified_fault"> | |
1233 | <p> | |
1234 | Indicates that an error has occurred in configuring the ACL | |
1235 | but no | |
1236 | more specific information is available. | |
1237 | </p> | |
1238 | </column> | |
1239 | </group> | |
1240 | </table> | |
add17b69 | 1241 | </database> |