1 <?xml version="1.0" encoding="utf-8"?>
2 <database name="vtep" title="Hardware VTEP Database">
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.
14 VXLAN Tunnel End Point, an entity which originates and/or terminates
20 Hardware Switch Controller.
25 Network Virtualization Controller, e.g. NSX.
30 Virtual Routing and Forwarding instance.
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.
38 <column name="switches">
40 The physical switch or switches managed by the VTEP.
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.
57 <group title="Database Configuration">
59 These columns primarily configure the database server
60 (<code>ovsdb-server</code>), not the hardware VTEP itself.
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.
72 <table name="Manager" title="OVSDB management connection.">
74 Configuration for a database connection to an Open vSwitch Database
79 The database server can initiate and maintain active connections
80 to remote clients. It can also listen for database connections.
83 <group title="Core Features">
84 <column name="target">
85 <p>Connection method for managers.</p>
87 The following connection methods are currently supported:
90 <dt><code>ssl:<var>ip</var></code>[<code>:<var>port</var></code>]</dt>
93 The specified SSL <var>port</var> (default: 6640) on the host at
94 the given <var>ip</var>, which must be expressed as an IP address
98 SSL key and certificate configuration happens outside the
103 <dt><code>tcp:<var>ip</var></code>[<code>:<var>port</var></code>]</dt>
105 The specified TCP <var>port</var> (default: 6640) on the host at
106 the given <var>ip</var>, which must be expressed as an IP address
109 <dt><code>pssl:</code>[<var>port</var>][<code>:<var>ip</var></code>]</dt>
112 Listens for SSL connections on the specified TCP <var>port</var>
113 (default: 6640). If <var>ip</var>, which must be expressed as an
114 IP address (not a DNS name), is specified, then connections are
115 restricted to the specified local IP address.
118 <dt><code>ptcp:</code>[<var>port</var>][<code>:<var>ip</var></code>]</dt>
120 Listens for connections on the specified TCP <var>port</var>
121 (default: 6640). If <var>ip</var>, which must be expressed as an
122 IP address (not a DNS name), is specified, then connections are
123 restricted to the specified local IP address.
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.
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.
147 <group title="Status">
148 <column name="is_connected">
149 <code>true</code> if currently connected to this manager,
150 <code>false</code> otherwise.
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.
159 <column name="status" key="state"
160 type='{"type": "string", "enum": ["set", ["VOID", "BACKOFF", "CONNECTING", "ACTIVE", "IDLE"]]}'>
162 The state of the connection to the manager:
165 <dt><code>VOID</code></dt>
166 <dd>Connection is disabled.</dd>
168 <dt><code>BACKOFF</code></dt>
169 <dd>Attempting to reconnect at an increasing period.</dd>
171 <dt><code>CONNECTING</code></dt>
172 <dd>Attempting to connect.</dd>
174 <dt><code>ACTIVE</code></dt>
175 <dd>Connected, remote host responsive.</dd>
177 <dt><code>IDLE</code></dt>
178 <dd>Connection is idle. Waiting for response to keep-alive.</dd>
181 These values may change in the future. They are provided only for
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.
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
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.
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
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.
217 <column name="status" key="n_connections"
218 type='{"type": "integer", "minInteger": 2}'>
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.
227 When multiple connections are active, status columns and key-value
228 pairs (other than this one) report the status of one arbitrarily
234 <group title="Connection Parameters">
236 Additional configuration for a connection between the manager
237 and the database server.
240 <column name="other_config" key="dscp"
241 type='{"type": "integer"}'>
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.
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.
255 <table name="Physical_Switch" title="A physical switch.">
256 A physical switch that implements a VTEP.
258 <column name="ports">
259 The physical ports within the switch.
262 <column name="tunnels">
263 Tunnels created by this switch as instructed by the NVC.
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.
272 <column name="tunnel_ips">
274 IPv4 or IPv6 addresses on which the switch may originate or
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"/>.
286 <group title="Identification">
288 Symbolic name for the switch, such as its hostname.
291 <column name="description">
292 An extended description for the switch, such as its switch login
296 <group title="Error Notification">
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.
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.
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.
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.
321 <table name="Tunnel" title="A tunnel created by a physical switch.">
322 A tunnel created by a <ref table="Physical_Switch"/>.
324 <column name="local">
325 Tunnel end-point local to the physical switch.
328 <column name="remote">
329 Tunnel end-point remote to the physical switch.
332 <group title="Bidirectional Forwarding Detection (BFD)">
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.
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.
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.
360 In many cases the BFD peer of a hardware VTEP will be an Open vSwitch
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''
367 <group title="BFD Local Configuration">
369 The HSC writes the key-value pairs in the
370 <ref column="bfd_config_local"/> column to specify the local
371 configurations to be used for BFD sessions on this tunnel.
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.
378 The default is <code>00:23:20:00:00:01</code>.
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>.
388 <group title="BFD Remote Configuration">
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.
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>.
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>.
409 <group title="BFD Parameters">
411 The NVC sets up key-value pairs in the <ref column="bfd_params"/>
412 column to enable and configure BFD.
415 <column name="bfd_params" key="enable" type='{"type": "boolean"}'>
416 True to enable BFD on this <ref table="Tunnel"/>. If not
417 specified, BFD will not be enabled by default.
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
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>.
436 <column name="bfd_params" key="decay_min_rx" type='{"type": "integer"}'>
437 An alternate receive interval, in milliseconds, that must be greater
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.
448 <column name="bfd_params" key="forwarding_if_rx" type='{"type": "boolean"}'>
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>.
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
460 forwarded to this system for some reason other than a connectivity
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.
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
474 <group title="BFD Status">
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"/>.
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.
490 <column name="bfd_status" key="state"
491 type='{"type": "string",
492 "enum": ["set", ["admin_down", "down", "init", "up"]]}'>
493 Reports the state of the BFD session. The BFD session is fully
494 healthy and negotiated if <code>UP</code>.
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.
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].
510 <column name="bfd_status" key="remote_state"
511 type='{"type": "string",
512 "enum": ["set", ["admin_down", "down", "init", "up"]]}'>
513 Reports the state of the remote endpoint's BFD session.
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].
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).
530 <table name="Physical_Port" title="A port within a physical switch.">
531 A port within a <ref table="Physical_Switch"/>.
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
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
542 <column name="acl_bindings">
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.
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
564 or partially populate it, respectively. A value of zero in the
565 VLAN field refers to untagged traffic on the physical port.
568 <group title="Identification">
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
575 <column name="description">
576 An extended description for the port.
579 <group title="Error Notification">
581 An entry in this column indicates to the NVC that the physical port has
582 encountered a fault. The switch must clear this column when the error
585 <column name="port_fault_status" key="invalid_vlan_map">
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.
592 <column name="port_fault_status" key="invalid_ACL_binding">
594 Indicates that an error has occurred in associating an ACL
598 <column name="port_fault_status" key="unspecified_fault">
600 Indicates that an error has occurred on the port but that no
601 more specific information is available.
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.
612 <group title="Statistics">
613 These statistics count only packets to which the binding applies.
615 <column name="packets_from_local">
616 Number of packets sent by the <ref table="Physical_Switch"/>.
619 <column name="bytes_from_local">
620 Number of bytes in packets sent by the <ref table="Physical_Switch"/>.
623 <column name="packets_to_local">
624 Number of packets received by the <ref table="Physical_Switch"/>.
627 <column name="bytes_to_local">
628 Number of bytes in packets received by the <ref
629 table="Physical_Switch"/>.
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.
641 <group title="Per Logical-Switch Tunnel Key">
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
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
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.
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.
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.
684 <column name="tunnel_key">
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.
692 For <code>vxlan_over_ipv4</code> encapsulation, when the tunnel key
693 per <ref table="Logical_Switch"/> model is in use, this column is the
694 VXLAN VNI that identifies a logical switch. It must be in the range
700 <group title="Identification">
702 Symbolic name for the logical switch.
705 <column name="description">
706 An extended description for the logical switch, such as its switch
712 <table name="Ucast_Macs_Local" title="Unicast MACs (local)">
714 Mapping of unicast MAC addresses to tunnels (physical
715 locators). This table is written by the HSC, so it contains the
716 MAC addresses that have been learned on physical ports by a
721 A MAC address that has been learned by the VTEP.
724 <column name="logical_switch">
725 The Logical switch to which this mapping applies.
728 <column name="locator">
729 The physical locator to be used to reach this MAC address. In
730 this table, the physical locator will be one of the tunnel IP
731 addresses of the appropriate VTEP.
734 <column name="ipaddr">
735 The IP address to which this MAC corresponds. Optional field for
736 the purpose of ARP supression.
741 <table name="Ucast_Macs_Remote" title="Unicast MACs (remote)">
743 Mapping of unicast MAC addresses to tunnels (physical
744 locators). This table is written by the NVC, so it contains the
745 MAC addresses that the NVC has learned. These include VM MAC
746 addresses, in which case the physical locators will be
747 hypervisor IP addresses. The NVC will also report MACs that it
748 has learned from other HSCs in the network, in which case the
749 physical locators will be tunnel IP addresses of the
754 A MAC address that has been learned by the NVC.
757 <column name="logical_switch">
758 The Logical switch to which this mapping applies.
761 <column name="locator">
762 The physical locator to be used to reach this MAC address. In
763 this table, the physical locator will be either a hypervisor IP
764 address or a tunnel IP addresses of another VTEP.
767 <column name="ipaddr">
768 The IP address to which this MAC corresponds. Optional field for
769 the purpose of ARP supression.
774 <table name="Mcast_Macs_Local" title="Multicast MACs (local)">
776 Mapping of multicast MAC addresses to tunnels (physical
777 locators). This table is written by the HSC, so it contains the
778 MAC addresses that have been learned on physical ports by a
779 VTEP. These may be learned by IGMP snooping, for example. This
780 table also specifies how to handle unknown unicast and broadcast packets.
785 A MAC address that has been learned by the VTEP.
788 The keyword <code>unknown-dst</code> is used as a special
789 ``Ethernet address'' that indicates the locations to which
790 packets in a logical switch whose destination addresses do not
791 otherwise appear in <ref table="Ucast_Macs_Local"/> (for
792 unicast addresses) or <ref table="Mcast_Macs_Local"/> (for
793 multicast addresses) should be sent.
797 <column name="logical_switch">
798 The Logical switch to which this mapping applies.
801 <column name="locator_set">
802 The physical locator set to be used to reach this MAC address. In
803 this table, the physical locator set will be contain one or more tunnel IP
804 addresses of the appropriate VTEP(s).
807 <column name="ipaddr">
808 The IP address to which this MAC corresponds. Optional field for
809 the purpose of ARP supression.
813 <table name="Mcast_Macs_Remote" title="Multicast MACs (remote)">
815 Mapping of multicast MAC addresses to tunnels (physical
816 locators). This table is written by the NVC, so it contains the
817 MAC addresses that the NVC has learned. This
818 table also specifies how to handle unknown unicast and broadcast
822 Multicast packet replication may be handled by a service node,
823 in which case the physical locators will be IP addresses of
824 service nodes. If the VTEP supports replication onto multiple
825 tunnels, then this may be used to replicate directly onto
826 VTEP-hypervisor tunnels.
831 A MAC address that has been learned by the NVC.
834 The keyword <code>unknown-dst</code> is used as a special
835 ``Ethernet address'' that indicates the locations to which
836 packets in a logical switch whose destination addresses do not
837 otherwise appear in <ref table="Ucast_Macs_Remote"/> (for
838 unicast addresses) or <ref table="Mcast_Macs_Remote"/> (for
839 multicast addresses) should be sent.
843 <column name="logical_switch">
844 The Logical switch to which this mapping applies.
847 <column name="locator_set">
848 The physical locator set to be used to reach this MAC address. In
849 this table, the physical locator set will be either a service node IP
850 address or a set of tunnel IP addresses of hypervisors (and
851 potentially other VTEPs).
854 <column name="ipaddr">
855 The IP address to which this MAC corresponds. Optional field for
856 the purpose of ARP supression.
861 <table name="Logical_Router" title="A logical L3 router.">
863 A logical router, or VRF. A logical router may be connected to one or more
864 logical switches. Subnet addresses and interface addresses may be configured on the
868 <column name="switch_binding">
869 Maps from an IPv4 or IPv6 address prefix in CIDR notation to a
870 logical switch. Multiple prefixes may map to the same switch. By
871 writing a 32-bit (or 128-bit for v6) address with a /N prefix
872 length, both the router's interface address and the subnet
873 prefix can be configured. For example, 192.68.1.1/24 creates a
874 /24 subnet for the logical switch attached to the interface and
875 assigns the address 192.68.1.1 to the router interface.
878 <column name="static_routes">
879 One or more static routes, mapping IP prefixes to next hop IP addresses.
882 <column name="acl_binding">
883 Maps ACLs to logical router interfaces. The router interfaces
884 are indicated using IP address notation, and must be the same
885 interfaces created in the <ref column="switch_binding"/>
886 column. For example, an ACL could be associated with the logical
887 router interface with an address of 192.68.1.1 as defined in the
891 <group title="Identification">
893 Symbolic name for the logical router.
896 <column name="description">
897 An extended description for the logical router.
901 <group title="Error Notification">
903 An entry in this column indicates to the NVC that the HSC has
904 encountered a fault in configuring state related to the
907 <column name="LR_fault_status" key="invalid_ACL_binding">
909 Indicates that an error has occurred in associating an ACL
910 with a logical router port.
913 <column name="LR_fault_status" key="unspecified_fault">
915 Indicates that an error has occurred in configuring the
916 logical router but that no
917 more specific information is available.
924 <table name="Arp_Sources_Local" title="ARP source addresses for logical routers">
926 MAC address to be used when a VTEP issues ARP requests on behalf
931 A distributed logical router is implemented by a set of VTEPs
932 (both hardware VTEPs and vswitches). In order for a given VTEP
933 to populate the local ARP cache for a logical router, it issues
934 ARP requests with a source MAC address that is unique to the VTEP. A
935 single per-VTEP MAC can be re-used across all logical
936 networks. This table contains the MACs that are used by the
937 VTEPs of a given HSC. The table provides the mapping from MAC to
938 physical locator for each VTEP so that replies to the ARP
939 requests can be sent back to the correct VTEP using the
940 appropriate physical locator.
943 <column name="src_mac">
944 The source MAC to be used by a given VTEP.
947 <column name="locator">
948 The <ref table="Physical_Locator"/> to use for replies to ARP
949 requests from this MAC address.
953 <table name="Arp_Sources_Remote" title="ARP source addresses for logical routers">
955 MAC address to be used when a remote VTEP issues ARP requests on behalf
960 This table is the remote counterpart of <ref
961 table="Arp_sources_local"/>. The NVC writes this table to notify
962 the HSC of the MACs that will be used by remote VTEPs when they
963 issue ARP requests on behalf of a distributed logical router.
966 <column name="src_mac">
967 The source MAC to be used by a given VTEP.
970 <column name="locator">
971 The <ref table="Physical_Locator"/> to use for replies to ARP
972 requests from this MAC address.
976 <table name="Physical_Locator_Set">
978 A set of one or more <ref table="Physical_Locator"/>s.
982 This table exists only because OVSDB does not have a way to
983 express the type ``map from string to one or more <ref
984 table="Physical_Locator"/> records.''
987 <column name="locators"/>
990 <table name="Physical_Locator">
992 Identifies an endpoint to which logical switch traffic may be
993 encapsulated and forwarded.
997 The <code>vxlan_over_ipv4</code> encapsulation, the only encapsulation
998 defined so far, can use either tunnel key model described in the ``Per
999 Logical-Switch Tunnel Key'' section in the <ref table="Logical_Switch"/>
1000 table. When the tunnel key per <ref table="Logical_Switch"/> model is in
1001 use, the <ref table="Logical_Switch" column="tunnel_key"/> column in the
1002 <ref table="Logical_Switch"/> table is filled with a VNI and the <ref
1003 column="tunnel_key"/> column in this table is empty; in the
1004 key-per-tunnel model, the opposite is true. The former model is older,
1005 and thus likely to be more widely supported. See the ``Per
1006 Logical-Switch Tunnel Key'' section in the <ref table="Logical_Switch"/>
1007 table for further discussion of the model.
1010 <column name="encapsulation_type">
1011 The type of tunneling encapsulation.
1014 <column name="dst_ip">
1016 For <code>vxlan_over_ipv4</code> encapsulation, the IPv4 address of the
1017 VXLAN tunnel endpoint.
1021 We expect that this column could be used for IPv4 or IPv6 addresses in
1022 encapsulations to be introduced later.
1026 <column name="tunnel_key">
1028 This column is used only in the tunnel key per <ref
1029 table="Logical_Switch"/>+<ref table="Physical_Locator"/> model (see
1034 For <code>vxlan_over_ipv4</code> encapsulation, when the <ref
1035 table="Logical_Switch"/>+<ref table="Physical_Locator"/> model is in
1036 use, this column is the VXLAN VNI. It must be in the range 0 to
1042 <table name="ACL_entry">
1044 Describes the individual entries that comprise an Access Control List.
1047 Each entry in the table is a single rule to match on certain
1048 header fields. While there are a large number of fields that can
1049 be matched on, most hardware cannot match on arbitrary
1050 combinations of fields. It is common to match on either L2
1051 fields (described below in the L2 group of columns) or L3/L4 fields
1052 (the L3/L4 group of columns) but not both. The hardware switch
1053 controller may log an error if an ACL entry requires it to match
1054 on an incompatible mixture of fields.
1056 <column name="sequence">
1058 The sequence number for the ACL entry for the purpose of
1059 ordering entries in an ACL. Lower numbered entries are matched
1060 before higher numbered entries.
1063 <group title="L2 fields">
1064 <column name="source_mac">
1066 Source MAC address, in the form
1067 <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
1070 <column name="dest_mac">
1072 Destination MAC address, in the form
1073 <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
1076 <column name="ethertype">
1078 Ethertype in hexadecimal, in the form
1083 <group title="L3/L4 fields">
1084 <column name="source_ip">
1086 Source IP address, in the form
1087 <var>xx.xx.xx.xx</var> for IPv4 or appropriate
1088 colon-separated hexadecimal notation for IPv6.
1091 <column name="source_mask">
1093 Mask that determines which bits of source_ip to match on, in the form
1094 <var>xx.xx.xx.xx</var> for IPv4 or appropriate
1095 colon-separated hexadecimal notation for IPv6.
1098 <column name="dest_ip">
1100 Destination IP address, in the form
1101 <var>xx.xx.xx.xx</var> for IPv4 or appropriate
1102 colon-separated hexadecimal notation for IPv6.
1105 <column name="dest_mask">
1107 Mask that determines which bits of dest_ip to match on, in the form
1108 <var>xx.xx.xx.xx</var> for IPv4 or appropriate
1109 colon-separated hexadecimal notation for IPv6.
1112 <column name="protocol">
1114 Protocol number in the IPv4 header, or value of the "next
1115 header" field in the IPv6 header.
1118 <column name="source_port_min">
1120 Lower end of the range of source port values. The value
1121 specified is included in the range.
1124 <column name="source_port_max">
1126 Upper end of the range of source port values. The value
1127 specified is included in the range.
1130 <column name="dest_port_min">
1132 Lower end of the range of destination port values. The value
1133 specified is included in the range.
1136 <column name="dest_port_max">
1138 Upper end of the range of destination port values. The value
1139 specified is included in the range.
1142 <column name="tcp_flags">
1144 Integer representing the value of TCP flags to match. For
1145 example, the SYN flag is the second least significant bit in
1146 the TCP flags. Hence a value of 2 would indicate that the "SYN"
1147 flag should be set (assuming an appropriate mask).
1150 <column name="tcp_flags_mask">
1152 Integer representing the mask to apply when matching TCP
1153 flags. For example, a value of 2 would imply that the "SYN"
1154 flag should be matched and all other flags ignored.
1157 <column name="icmp_type">
1159 ICMP type to be matched.
1162 <column name="icmp_code">
1164 ICMP code to be matched.
1168 <column name="direction">
1170 Direction of traffic to match on the specified port, either
1171 "ingress" (toward the logical switch or router) or "egress"
1172 (leaving the logical switch or router).
1175 <column name="action">
1177 Action to take for this rule, either "permit" or "deny".
1180 <group title="Error Notification">
1182 An entry in this column indicates to the NVC that the ACL
1183 could not be configured as requested. The switch must clear this column when the error
1186 <column name="acle_fault_status" key="invalid_acl_entry">
1188 Indicates that an ACL entry requested by
1189 the controller could not be instantiated by the switch,
1190 e.g. because it requires an unsupported combination of
1191 fields to be matched.
1194 <column name="acle_fault_status" key="unspecified_fault">
1196 Indicates that an error has occurred in configuring the ACL
1198 more specific information is available.
1205 Access Control List table. Each ACL is constructed as a set of
1206 entries from the <ref table="ACL_entry"/> table. Packets that
1207 are not matched by any entry in the ACL are allowed by default.
1209 <column name="acl_entries">
1211 A set of references to entries in the <ref table="ACL_entry"/> table.
1214 <column name="acl_name">
1216 A human readable name for the ACL, which may (for example) be displayed on
1220 <group title="Error Notification">
1222 An entry in this column indicates to the NVC that the ACL
1223 could not be configured as requested. The switch must clear this column when the error
1226 <column name="acl_fault_status" key="invalid_acl">
1228 Indicates that an ACL requested by
1229 the controller could not be instantiated by the switch,
1230 e.g., because it requires an unsupported combination of
1231 fields to be matched.
1234 <column name="acl_fault_status" key="resource_shortage">
1236 Indicates that an ACL requested by
1237 the controller could not be instantiated by the switch due
1238 to a shortage of resources (e.g. TCAM space).
1241 <column name="acl_fault_status" key="unspecified_fault">
1243 Indicates that an error has occurred in configuring the ACL
1245 more specific information is available.