1 <?xml version=
"1.0" encoding=
"utf-8"?>
2 <database 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">
39 The physical switches managed by the VTEP.
42 <group title=
"Database Configuration">
44 These columns primarily configure the database server
45 (
<code>ovsdb-server
</code>), not the hardware VTEP itself.
48 <column name=
"managers">
49 Database clients to which the database server should connect or
50 to which it should listen, along with options for how these
51 connection should be configured. See the
<ref table=
"Manager"/>
52 table for more information.
57 <table name=
"Manager" title=
"OVSDB management connection.">
59 Configuration for a database connection to an Open vSwitch Database
64 The database server can initiate and maintain active connections
65 to remote clients. It can also listen for database connections.
68 <group title=
"Core Features">
69 <column name=
"target">
70 <p>Connection method for managers.
</p>
72 The following connection methods are currently supported:
75 <dt><code>ssl:
<var>ip
</var></code>[
<code>:
<var>port
</var></code>]
</dt>
78 The specified SSL
<var>port
</var> (default:
6632) on the host at
79 the given
<var>ip
</var>, which must be expressed as an IP address
83 SSL key and certificate configuration happens outside the
88 <dt><code>tcp:
<var>ip
</var></code>[
<code>:
<var>port
</var></code>]
</dt>
90 The specified TCP
<var>port
</var> (default:
6632) on the host at
91 the given
<var>ip
</var>, which must be expressed as an IP address
94 <dt><code>pssl:
</code>[
<var>port
</var>][
<code>:
<var>ip
</var></code>]
</dt>
97 Listens for SSL connections on the specified TCP
<var>port
</var>
98 (default:
6632). If
<var>ip
</var>, which must be expressed as an
99 IP address (not a DNS name), is specified, then connections are
100 restricted to the specified local IP address.
103 <dt><code>ptcp:
</code>[
<var>port
</var>][
<code>:
<var>ip
</var></code>]
</dt>
105 Listens for connections on the specified TCP
<var>port
</var>
106 (default:
6632). If
<var>ip
</var>, which must be expressed as an
107 IP address (not a DNS name), is specified, then connections are
108 restricted to the specified local IP address.
114 <group title=
"Client Failure Detection and Handling">
115 <column name=
"max_backoff">
116 Maximum number of milliseconds to wait between connection attempts.
117 Default is implementation-specific.
120 <column name=
"inactivity_probe">
121 Maximum number of milliseconds of idle time on connection to the
122 client before sending an inactivity probe message. If the Open
123 vSwitch database does not communicate with the client for the
124 specified number of seconds, it will send a probe. If a
125 response is not received for the same additional amount of time,
126 the database server assumes the connection has been broken
127 and attempts to reconnect. Default is implementation-specific.
128 A value of
0 disables inactivity probes.
132 <group title=
"Status">
133 <column name=
"is_connected">
134 <code>true
</code> if currently connected to this manager,
135 <code>false
</code> otherwise.
138 <column name=
"status" key=
"last_error">
139 A human-readable description of the last error on the connection
140 to the manager; i.e.
<code>strerror(errno)
</code>. This key
141 will exist only if an error has occurred.
144 <column name=
"status" key=
"state"
145 type='{
"type":
"string",
"enum": [
"set", [
"VOID",
"BACKOFF",
"CONNECTING",
"ACTIVE",
"IDLE"]]}'
>
147 The state of the connection to the manager:
150 <dt><code>VOID
</code></dt>
151 <dd>Connection is disabled.
</dd>
153 <dt><code>BACKOFF
</code></dt>
154 <dd>Attempting to reconnect at an increasing period.
</dd>
156 <dt><code>CONNECTING
</code></dt>
157 <dd>Attempting to connect.
</dd>
159 <dt><code>ACTIVE
</code></dt>
160 <dd>Connected, remote host responsive.
</dd>
162 <dt><code>IDLE
</code></dt>
163 <dd>Connection is idle. Waiting for response to keep-alive.
</dd>
166 These values may change in the future. They are provided only for
171 <column name=
"status" key=
"sec_since_connect"
172 type='{
"type":
"integer",
"minInteger":
0}'
>
173 The amount of time since this manager last successfully connected
174 to the database (in seconds). Value is empty if manager has never
175 successfully connected.
178 <column name=
"status" key=
"sec_since_disconnect"
179 type='{
"type":
"integer",
"minInteger":
0}'
>
180 The amount of time since this manager last disconnected from the
181 database (in seconds). Value is empty if manager has never
185 <column name=
"status" key=
"locks_held">
186 Space-separated list of the names of OVSDB locks that the connection
187 holds. Omitted if the connection does not hold any locks.
190 <column name=
"status" key=
"locks_waiting">
191 Space-separated list of the names of OVSDB locks that the connection is
192 currently waiting to acquire. Omitted if the connection is not waiting
196 <column name=
"status" key=
"locks_lost">
197 Space-separated list of the names of OVSDB locks that the connection
198 has had stolen by another OVSDB client. Omitted if no locks have been
199 stolen from this connection.
202 <column name=
"status" key=
"n_connections"
203 type='{
"type":
"integer",
"minInteger":
2}'
>
205 When
<ref column=
"target"/> specifies a connection method that
206 listens for inbound connections (e.g.
<code>ptcp:
</code> or
207 <code>pssl:
</code>) and more than one connection is actually active,
208 the value is the number of active connections. Otherwise, this
209 key-value pair is omitted.
212 When multiple connections are active, status columns and key-value
213 pairs (other than this one) report the status of one arbitrarily
219 <group title=
"Connection Parameters">
221 Additional configuration for a connection between the manager
222 and the database server.
225 <column name=
"other_config" key=
"dscp"
226 type='{
"type":
"integer"}'
>
227 The Differentiated Service Code Point (DSCP) is specified using
6 bits
228 in the Type of Service (TOS) field in the IP header. DSCP provides a
229 mechanism to classify the network traffic and provide Quality of
230 Service (QoS) on IP networks.
232 The DSCP value specified here is used when establishing the
233 connection between the manager and the database server. If no
234 value is specified, a default value of
48 is chosen. Valid DSCP
235 values must be in the range
0 to
63.
240 <table name=
"Physical_Switch" title=
"A physical switch.">
241 A physical switch that implements a VTEP.
243 <column name=
"ports">
244 The physical ports within the switch.
247 <group title=
"Network Status">
248 <column name=
"management_ips">
249 IPv4 or IPv6 addresses at which the switch may be contacted
250 for management purposes.
253 <column name=
"tunnel_ips">
255 IPv4 or IPv6 addresses on which the switch may originate or
260 This column is intended to allow a
<ref table=
"Manager"/> to
261 determine the
<ref table=
"Physical_Switch"/> that terminates
262 the tunnel represented by a
<ref table=
"Physical_Locator"/>.
267 <group title=
"Identification">
269 Symbolic name for the switch, such as its hostname.
272 <column name=
"description">
273 An extended description for the switch, such as its switch login
279 <table name=
"Physical_Port" title=
"A port within a physical switch.">
280 A port within a
<ref table=
"Physical_Switch"/>.
282 <column name=
"vlan_bindings">
283 Identifies how VLANs on the physical port are bound to logical switches.
284 If, for example, the map contains a (VLAN, logical switch) pair, a packet
285 that arrives on the port in the VLAN is considered to belong to the
286 paired logical switch.
289 <column name=
"vlan_stats">
290 Statistics for VLANs bound to logical switches on the physical port. An
291 implementation that fully supports such statistics would populate this
292 column with a mapping for every VLAN that is bound in
<ref
293 column=
"vlan_bindings"/>. An implementation that does not support such
294 statistics or only partially supports them would not populate this column
295 or partially populate it, respectively.
298 <group title=
"Identification">
300 Symbolic name for the port. The name ought to be unique within a given
301 <ref table=
"Physical_Switch"/>, but the database is not capable of
305 <column name=
"description">
306 An extended description for the port.
311 <table name=
"Logical_Binding_Stats" title=
"Statistics for a VLAN on a physical port bound to a logical network.">
312 Reports statistics for the
<ref table=
"Logical_Switch"/> with which a VLAN
313 on a
<ref table=
"Physical_Port"/> is associated.
315 <group title=
"Statistics">
316 These statistics count only packets to which the binding applies.
318 <column name=
"packets_from_local">
319 Number of packets sent by the
<ref table=
"Physical_Switch"/>.
322 <column name=
"bytes_from_local">
323 Number of bytes in packets sent by the
<ref table=
"Physical_Switch"/>.
326 <column name=
"packets_to_local">
327 Number of packets received by the
<ref table=
"Physical_Switch"/>.
330 <column name=
"bytes_to_local">
331 Number of bytes in packets received by the
<ref
332 table=
"Physical_Switch"/>.
337 <table name=
"Logical_Switch" title=
"A layer-2 domain.">
338 A logical Ethernet switch, whose implementation may span physical and
339 virtual media, possibly crossing L3 domains via tunnels; a logical layer-
2
340 domain; an Ethernet broadcast domain.
344 <group title=
"Per Logical-Switch Tunnel Key">
346 Tunnel protocols tend to have a field that allows the tunnel
347 to be partitioned into sub-tunnels: VXLAN has a VNI, GRE and
348 STT have a key, CAPWAP has a WSI, and so on. We call these
349 generically ``tunnel keys.'' Given that one needs to use a
350 tunnel key at all, there are at least two reasonable ways to
357 Per
<ref table=
"Logical_Switch"/>+
<ref table=
"Physical_Locator"/>
358 pair. That is, each logical switch may be assigned a different
359 tunnel key on every
<ref table=
"Physical_Locator"/>. This model is
364 In this model,
<ref table=
"Physical_Locator"/> carries the tunnel
365 key. Therefore, one
<ref table=
"Physical_Locator"/> record will
366 exist for each logical switch carried at a given IP destination.
372 Per
<ref table=
"Logical_Switch"/>. That is, every tunnel
373 associated with a particular logical switch carries the same tunnel
374 key, regardless of the
<ref table=
"Physical_Locator"/> to which the
375 tunnel is addressed. This model may ease switch implementation
376 because it imposes fewer requirements on the hardware datapath.
380 In this model,
<ref table=
"Logical_Switch"/> carries the tunnel
381 key. Therefore, one
<ref table=
"Physical_Locator"/> record will
382 exist for each IP destination.
387 <column name=
"tunnel_key">
389 This column is used only in the tunnel key per
<ref
390 table=
"Logical_Switch"/> model (see above), because only in that
391 model is there a tunnel key associated with a logical switch.
395 For
<code>vxlan_over_ipv4
</code> encapsulation, this column
396 is the VXLAN VNI that identifies a logical switch. It must
397 be in the range
0 to
16,
777,
215.
402 <group title=
"Identification">
404 Symbolic name for the logical switch.
407 <column name=
"description">
408 An extended description for the logical switch, such as its switch
414 <table name=
"Ucast_Macs_Local" title=
"Unicast MACs (local)">
416 Mapping of unicast MAC addresses to tunnels (physical
417 locators). This table is written by the HSC, so it contains the
418 MAC addresses that have been learned on physical ports by a
423 A MAC address that has been learned by the VTEP.
426 <column name=
"logical_switch">
427 The Logical switch to which this mapping applies.
430 <column name=
"locator">
431 The physical locator to be used to reach this MAC address. In
432 this table, the physical locator will be one of the tunnel IP
433 addresses of the appropriate VTEP.
436 <column name=
"ipaddr">
437 The IP address to which this MAC corresponds. Optional field for
438 the purpose of ARP supression.
443 <table name=
"Ucast_Macs_Remote" title=
"Unicast MACs (remote)">
445 Mapping of unicast MAC addresses to tunnels (physical
446 locators). This table is written by the NVC, so it contains the
447 MAC addresses that the NVC has learned. These include VM MAC
448 addresses, in which case the physical locators will be
449 hypervisor IP addresses. The NVC will also report MACs that it
450 has learned from other HSCs in the network, in which case the
451 physical locators will be tunnel IP addresses of the
456 A MAC address that has been learned by the NSC.
459 <column name=
"logical_switch">
460 The Logical switch to which this mapping applies.
463 <column name=
"locator">
464 The physical locator to be used to reach this MAC address. In
465 this table, the physical locator will be either a hypervisor IP
466 address or a tunnel IP addresses of another VTEP.
469 <column name=
"ipaddr">
470 The IP address to which this MAC corresponds. Optional field for
471 the purpose of ARP supression.
476 <table name=
"Mcast_Macs_Local" title=
"Multicast MACs (local)">
478 Mapping of multicast MAC addresses to tunnels (physical
479 locators). This table is written by the HSC, so it contains the
480 MAC addresses that have been learned on physical ports by a
481 VTEP. These may be learned by IGMP snooping, for example. This
482 table also specifies how to handle unknown unicast and broadcast packets.
487 A MAC address that has been learned by the VTEP.
490 The keyword
<code>unknown-dst
</code> is used as a special
491 ``Ethernet address'' that indicates the locations to which
492 packets in a logical switch whose destination addresses do not
493 otherwise appear in
<ref table=
"Ucast_Macs_Local"/> (for
494 unicast addresses) or
<ref table=
"Mcast_Macs_Local"/> (for
495 multicast addresses) should be sent.
499 <column name=
"logical_switch">
500 The Logical switch to which this mapping applies.
503 <column name=
"locator_set">
504 The physical locator set to be used to reach this MAC address. In
505 this table, the physical locator set will be contain one or more tunnel IP
506 addresses of the appropriate VTEP(s).
511 <table name=
"Mcast_Macs_Remote" title=
"Multicast MACs (remote)">
513 Mapping of multicast MAC addresses to tunnels (physical
514 locators). This table is written by the NVC, so it contains the
515 MAC addresses that the NVC has learned. This
516 table also specifies how to handle unknown unicast and broadcast
520 Multicast packet replication may be handled by a service node,
521 in which case the physical locators will be IP addresses of
522 service nodes. If the VTEP supports replication onto multiple
523 tunnels, then this may be used to replicate directly onto
524 VTEP-hyperisor tunnels.
529 A MAC address that has been learned by the NSC.
532 The keyword
<code>unknown-dst
</code> is used as a special
533 ``Ethernet address'' that indicates the locations to which
534 packets in a logical switch whose destination addresses do not
535 otherwise appear in
<ref table=
"Ucast_Macs_Remote"/> (for
536 unicast addresses) or
<ref table=
"Mcast_Macs_Remote"/> (for
537 multicast addresses) should be sent.
541 <column name=
"logical_switch">
542 The Logical switch to which this mapping applies.
545 <column name=
"locator_set">
546 The physical locator set to be used to reach this MAC address. In
547 this table, the physical locator set will be either a service node IP
548 address or a set of tunnel IP addresses of hypervisors (and
549 potentially other VTEPs).
552 <column name=
"ipaddr">
553 The IP address to which this MAC corresponds. Optional field for
554 the purpose of ARP supression.
559 <table name=
"Logical_Router" title=
"A logical L3 router.">
561 A logical router, or VRF. A logical router may be connected to one or more
562 logical switches. Subnet addresses and interface addresses may be configured on the
566 <column name=
"switch_binding">
567 Maps from an IPv4 or IPv6 address prefix in CIDR notation to a
568 logical switch. Multiple prefixes may map to the same switch. By
569 writing a
32-bit (or
128-bit for v6) address with a /N prefix
570 length, both the router's interface address and the subnet
571 prefix can be configured. For example,
192.68.1.1/
24 creates a
572 /
24 subnet for the logical switch attached to the interface and
573 assigns the address
192.68.1.1 to the router interface.
576 <column name=
"static_routes">
577 One or more static routes, mapping IP prefixes to next hop IP addresses.
580 <group title=
"Identification">
582 Symbolic name for the logical router.
585 <column name=
"description">
586 An extended description for the logical router.
591 <table name=
"Physical_Locator_Set">
593 A set of one or more
<ref table=
"Physical_Locator"/>s.
597 This table exists only because OVSDB does not have a way to
598 express the type ``map from string to one or more
<ref
599 table=
"Physical_Locator"/> records.''
602 <column name=
"locators"/>
605 <table name=
"Physical_Locator">
607 Identifies an endpoint to which logical switch traffic may be
608 encapsulated and forwarded.
612 For the
<code>vxlan_over_ipv4
</code> encapsulation, the only
613 encapsulation defined so far, all endpoints associated with a given
<ref
614 table=
"Logical_Switch"/> must use a common tunnel key, which is carried
615 in the
<ref table=
"Logical_Switch" column=
"tunnel_key"/> column of
<ref
616 table=
"Logical_Switch"/>.
620 For some encapsulations yet to be defined, we expect
<ref
621 table=
"Physical_Locator"/> to identify both an endpoint and a tunnel key.
622 When the first such encapsulation is defined, we expect to add a
623 ``tunnel_key'' column to
<ref table=
"Physical_Locator"/> to allow the
624 tunnel key to be defined.
628 See the ``Per Logical-Switch Tunnel Key'' section in the
<ref
629 table=
"Logical_Switch"/> table for further discussion of the model.
632 <column name=
"encapsulation_type">
633 The type of tunneling encapsulation.
636 <column name=
"dst_ip">
638 For
<code>vxlan_over_ipv4
</code> encapsulation, the IPv4 address of the
639 VXLAN tunnel endpoint.
643 We expect that this column could be used for IPv4 or IPv6 addresses in
644 encapsulations to be introduced later.
648 <group title=
"Bidirectional Forwarding Detection (BFD)">
650 BFD, defined in RFC
5880, allows point to point detection of
651 connectivity failures by occasional transmission of BFD control
652 messages. VTEPs are expected to implement BFD.
656 BFD operates by regularly transmitting BFD control messages at a
657 rate negotiated independently in each direction. Each endpoint
658 specifies the rate at which it expects to receive control messages,
659 and the rate at which it's willing to transmit them. An endpoint
660 which fails to receive BFD control messages for a period of three
661 times the expected reception rate will signal a connectivity
662 fault. In the case of a unidirectional connectivity issue, the
663 system not receiving BFD control messages will signal the problem
664 to its peer in the messages it transmits.
668 A hardware VTEP is expected to use BFD to determine reachability of
669 devices at the end of the tunnels with which it exchanges data. This
670 can enable the VTEP to choose a functioning service node among a set of
671 service nodes providing high availability. It also enables the NVC to
672 report the health status of tunnels.
676 In most cases the BFD peer of a hardware VTEP will be an Open vSwitch
677 instance. The Open vSwitch implementation of BFD aims to comply
678 faithfully with the requirements put forth in RFC
5880. Open vSwitch
679 does not implement the optional Authentication or ``Echo Mode''
683 <group title=
"BFD Configuration">
685 A controller sets up key-value pairs in the
<ref column=
"bfd"/>
686 column to enable and configure BFD.
689 <column name=
"bfd" key=
"enable" type='{
"type":
"boolean"}'
>
690 True to enable BFD on this
<ref table=
"Physical_Locator"/>.
693 <column name=
"bfd" key=
"min_rx"
694 type='{
"type":
"integer",
"minInteger":
1}'
>
695 The shortest interval, in milliseconds, at which this BFD session
696 offers to receive BFD control messages. The remote endpoint may
697 choose to send messages at a slower rate. Defaults to
701 <column name=
"bfd" key=
"min_tx"
702 type='{
"type":
"integer",
"minInteger":
1}'
>
703 The shortest interval, in milliseconds, at which this BFD session is
704 willing to transmit BFD control messages. Messages will actually be
705 transmitted at a slower rate if the remote endpoint is not willing to
706 receive as quickly as specified. Defaults to
<code>100</code>.
709 <column name=
"bfd" key=
"decay_min_rx" type='{
"type":
"integer"}'
>
710 An alternate receive interval, in milliseconds, that must be greater
711 than or equal to
<ref column=
"bfd" key=
"min_rx"/>. The
712 implementation switches from
<ref column=
"bfd" key=
"min_rx"/> to
<ref
713 column=
"bfd" key=
"decay_min_rx"/> when there is no obvious incoming
714 data traffic at the interface, to reduce the CPU and bandwidth cost
715 of monitoring an idle interface. This feature may be disabled by
716 setting a value of
0. This feature is reset whenever
<ref
717 column=
"bfd" key=
"decay_min_rx"/> or
<ref column=
"bfd" key=
"min_rx"/>
721 <column name=
"bfd" key=
"forwarding_if_rx" type='{
"type":
"boolean"}'
>
722 True to consider the interface capable of packet I/O as long as it
723 continues to receive any packets (not just BFD packets). This
724 prevents link congestion that causes consecutive BFD control packets
725 to be lost from marking the interface down.
728 <column name=
"bfd" key=
"cpath_down" type='{
"type":
"boolean"}'
>
729 Set to true to notify the remote endpoint that traffic should not be
730 forwarded to this system for some reason other than a connectivty
731 failure on the interface being monitored. The typical underlying
732 reason is ``concatenated path down,'' that is, that connectivity
733 beyond the local system is down. Defaults to false.
736 <column name=
"bfd" key=
"check_tnl_key" type='{
"type":
"boolean"}'
>
737 Set to true to make BFD accept only control messages with a tunnel
738 key of zero. By default, BFD accepts control messages with any
742 <column name=
"bfd" key=
"bfd_dst_mac">
743 Set to an Ethernet address in the form
744 <var>xx
</var>:
<var>xx
</var>:
<var>xx
</var>:
<var>xx
</var>:
<var>xx
</var>:
<var>xx
</var>
745 to set the MAC used as destination for transmitted BFD packets and
746 expected as destination for received BFD packets. The default is
747 <code>00:
23:
20:
00:
00:
01</code>.
751 <group title=
"BFD Status">
753 The VTEP sets key-value pairs in the
<ref column=
"bfd_status"/>
754 column to report the status of BFD on this interface. When BFD is
755 not enabled, with
<ref column=
"bfd" key=
"enable"/>, the switch clears
756 all key-value pairs from
<ref column=
"bfd_status"/>.
759 <column name=
"bfd_status" key=
"state"
760 type='{
"type":
"string",
761 "enum": [
"set", [
"admin_down",
"down",
"init",
"up"]]}'
>
762 Reports the state of the BFD session. The BFD session is fully
763 healthy and negotiated if
<code>UP
</code>.
766 <column name=
"bfd_status" key=
"forwarding" type='{
"type":
"boolean"}'
>
767 Reports whether the BFD session believes this
<ref
768 table=
"Physical_Locator"/> may be used to forward traffic. Typically
769 this means the local session is signaling
<code>UP
</code>, and the
770 remote system isn't signaling a problem such as concatenated path
774 <column name=
"bfd_status" key=
"diagnostic">
775 In case of a problem, set to a short message that reports what the
776 local BFD session thinks is wrong.
779 <column name=
"bfd_status" key=
"remote_state"
780 type='{
"type":
"string",
781 "enum": [
"set", [
"admin_down",
"down",
"init",
"up"]]}'
>
782 Reports the state of the remote endpoint's BFD session.
785 <column name=
"bfd_status" key=
"remote_diagnostic">
786 In case of a problem, set to a short message that reports what the
787 remote endpoint's BFD session thinks is wrong.