4 The OVSDB project implements the OVSDB protocol (RFC 7047), as well as
5 plugins to support OVSDB Schemas, such as the Open\_vSwitch database
6 schema and the hardware\_vtep database schema.
11 Overview and Architecture
12 ~~~~~~~~~~~~~~~~~~~~~~~~~
14 There are currently two OVSDB Southbound plugins:
16 - odl-ovsdb-southbound: Implements the OVSDB Open\_vSwitch database
19 - odl-ovsdb-hwvtepsouthbound: Implements the OVSDB hardware\_vtep
22 These plugins are normally installed and used automatically by higher
23 level applications such as odl-ovsdb-openstack; however, they can also
24 be installed separately and used via their REST APIs as is described in
25 the following sections.
27 OVSDB Southbound Plugin
28 ~~~~~~~~~~~~~~~~~~~~~~~
30 The OVSDB Southbound Plugin provides support for managing OVS hosts via
31 an OVSDB model in the MD-SAL which maps to important tables and
32 attributes present in the Open\_vSwitch schema. The OVSDB Southbound
33 Plugin is able to connect actively or passively to OVS hosts and operate
34 as the OVSDB manager of the OVS host. Using the OVSDB protocol it is
35 able to manage the OVS database (OVSDB) on the OVS host as defined by
36 the Open\_vSwitch schema.
41 The OVSDB Southbound Plugin provides a YANG model which is based on the
42 abstract `network topology
43 model <https://github.com/opendaylight/yangtools/blob/stable/boron/yang/yang-parser-impl/src/test/resources/ietf/network-topology%402013-10-21.yang>`__.
45 The details of the OVSDB YANG model are defined in the
46 `ovsdb.yang <https://github.com/opendaylight/ovsdb/blob/stable/boron/southbound/southbound-api/src/main/yang/ovsdb.yang>`__
49 The OVSDB YANG model defines three augmentations:
51 **ovsdb-node-augmentation**
52 This augments the network-topology node and maps primarily to the
53 Open\_vSwitch table of the OVSDB schema. The ovsdb-node-augmentation
54 is a representation of the OVS host. It contains the following
57 - **connection-info** - holds the local and remote IP address and
58 TCP port numbers for the OpenDaylight to OVSDB node connections
60 - **db-version** - version of the OVSDB database
62 - **ovs-version** - version of OVS
64 - **list managed-node-entry** - a list of references to
65 ovsdb-bridge-augmentation nodes, which are the OVS bridges
66 managed by this OVSDB node
68 - **list datapath-type-entry** - a list of the datapath types
69 supported by the OVSDB node (e.g. *system*, *netdev*) - depends
72 - **list interface-type-entry** - a list of the interface types
73 supported by the OVSDB node (e.g. *internal*, *vxlan*, *gre*,
74 *dpdk*, etc.) - depends on newer OVS verions
76 - **list openvswitch-external-ids** - a list of the key/value pairs
77 in the Open\_vSwitch table external\_ids column
79 - **list openvswitch-other-config** - a list of the key/value pairs
80 in the Open\_vSwitch table other\_config column
82 - **list managery-entry** - list of manager information entries and
85 - **list qos-entries** - list of QoS entries present in the QoS
88 - **list queues** - list of queue entries present in the queue
91 **ovsdb-bridge-augmentation**
92 This augments the network-topology node and maps to an specific
93 bridge in the OVSDB bridge table of the associated OVSDB node. It
94 contains the following attributes.
96 - **bridge-uuid** - UUID of the OVSDB bridge
98 - **bridge-name** - name of the OVSDB bridge
100 - **bridge-openflow-node-ref** - a reference (instance-identifier)
101 of the OpenFlow node associated with this bridge
103 - **list protocol-entry** - the version of OpenFlow protocol to use
104 with the OpenFlow controller
106 - **list controller-entry** - a list of controller-uuid and
107 is-connected status of the OpenFlow controllers associated with
110 - **datapath-id** - the datapath ID associated with this bridge on
113 - **datapath-type** - the datapath type of this bridge
115 - **fail-mode** - the OVSDB fail mode setting of this bridge
117 - **flow-node** - a reference to the flow node corresponding to
120 - **managed-by** - a reference to the ovsdb-node-augmentation
121 (OVSDB node) that is managing this bridge
123 - **list bridge-external-ids** - a list of the key/value pairs in
124 the bridge table external\_ids column for this bridge
126 - **list bridge-other-configs** - a list of the key/value pairs in
127 the bridge table other\_config column for this bridge
129 **ovsdb-termination-point-augmentation**
130 This augments the topology termination point model. The OVSDB
131 Southbound Plugin uses this model to represent both the OVSDB port
132 and OVSDB interface for a given port/interface in the OVSDB schema.
133 It contains the following attributes.
135 - **port-uuid** - UUID of an OVSDB port row
137 - **interface-uuid** - UUID of an OVSDB interface row
139 - **name** - name of the port and interface
141 - **interface-type** - the interface type
143 - **list options** - a list of port options
145 - **ofport** - the OpenFlow port number of the interface
147 - **ofport\_request** - the requested OpenFlow port number for the
150 - **vlan-tag** - the VLAN tag value
152 - **list trunks** - list of VLAN tag values for trunk mode
154 - **vlan-mode** - the VLAN mode (e.g. access, native-tagged,
155 native-untagged, trunk)
157 - **list port-external-ids** - a list of the key/value pairs in the
158 port table external\_ids column for this port
160 - **list interface-external-ids** - a list of the key/value pairs
161 in the interface table external\_ids interface for this interface
163 - **list port-other-configs** - a list of the key/value pairs in
164 the port table other\_config column for this port
166 - **list interface-other-configs** - a list of the key/value pairs
167 in the interface table other\_config column for this interface
169 - **list inteface-lldp** - LLDP Auto Attach configuration for the
172 - **qos** - UUID of the QoS entry in the QoS table assigned to this
178 To install the OVSDB Southbound Plugin, use the following command at the
183 feature:install odl-ovsdb-southbound-impl-ui
185 After installing the OVSDB Southbound Plugin, and before any OVSDB
186 topology nodes have been created, the OVSDB topology will appear as
187 follows in the configuration and operational MD-SAL.
193 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/
195 http://<controller-ip>:8181/restconf/operational/network-topology:network-topology/topology/ovsdb:1/
204 "topology-id": "ovsdb:1"
211 *<controller-ip>* is the IP address of the OpenDaylight controller
213 OpenDaylight as the OVSDB Manager
214 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
216 An OVS host is a system which is running the OVS software and is capable
217 of being managed by an OVSDB manager. The OVSDB Southbound Plugin is
218 capable of connecting to an OVS host and operating as an OVSDB manager.
219 Depending on the configuration of the OVS host, the connection of
220 OpenDaylight to the OVS host will be active or passive.
222 Active Connection to OVS Hosts
223 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
225 An active connection is when the OVSDB Southbound Plugin initiates the
226 connection to an OVS host. This happens when the OVS host is configured
227 to listen for the connection (i.e. the OVSDB Southbound Plugin is active
228 the the OVS host is passive). The OVS host is configured with the
233 sudo ovs-vsctl set-manager ptcp:6640
235 This configures the OVS host to listen on TCP port 6640.
237 The OVSDB Southbound Plugin can be configured via the configuration
238 MD-SAL to actively connect to an OVS host.
244 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:%2F%2FHOST1
251 "network-topology:node": [
253 "node-id": "ovsdb://HOST1",
255 "ovsdb:remote-port": "6640",
256 "ovsdb:remote-ip": "<ovs-host-ip>"
264 *<ovs-host-ip>* is the IP address of the OVS Host
266 Note that the configuration assigns a *node-id* of "ovsdb://HOST1" to
267 the OVSDB node. This *node-id* will be used as the identifier for this
268 OVSDB node in the MD-SAL.
270 Query the configuration MD-SAL for the OVSDB topology.
276 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/
285 "topology-id": "ovsdb:1",
288 "node-id": "ovsdb://HOST1",
289 "ovsdb:connection-info": {
290 "remote-ip": "<ovs-host-ip>",
299 As a result of the OVSDB node configuration being added to the
300 configuration MD-SAL, the OVSDB Southbound Plugin will attempt to
301 connect with the specified OVS host. If the connection is successful,
302 the plugin will connect to the OVS host as an OVSDB manager, query the
303 schemas and databases supported by the OVS host, and register to monitor
304 changes made to the OVSDB tables on the OVS host. It will also set an
305 external id key and value in the external-ids column of the
306 Open\_vSwtich table of the OVS host which identifies the MD-SAL instance
307 identifier of the OVSDB node. This ensures that the OVSDB node will use
308 the same *node-id* in both the configuration and operational MD-SAL.
312 "opendaylight-iid" = "instance identifier of OVSDB node in the MD-SAL"
314 When the OVS host sends the OVSDB Southbound Plugin the first update
315 message after the monitoring has been established, the plugin will
316 populate the operational MD-SAL with the information it receives from
319 Query the operational MD-SAL for the OVSDB topology.
325 http://<controller-ip>:8181/restconf/operational/network-topology:network-topology/topology/ovsdb:1/
334 "topology-id": "ovsdb:1",
337 "node-id": "ovsdb://HOST1",
338 "ovsdb:openvswitch-external-ids": [
340 "external-id-key": "opendaylight-iid",
341 "external-id-value": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb://HOST1']"
344 "ovsdb:connection-info": {
345 "local-ip": "<controller-ip>",
347 "remote-ip": "<ovs-host-ip>",
350 "ovsdb:ovs-version": "2.3.1-git4750c96",
351 "ovsdb:manager-entry": [
353 "target": "ptcp:6640",
355 "number_of_connections": 1
364 To disconnect an active connection, just delete the configuration MD-SAL
371 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:%2F%2FHOST1
373 Note in the above example, that */* characters which are part of the
374 *node-id* are specified in hexadecimal format as "%2F".
376 Passive Connection to OVS Hosts
377 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
379 A passive connection is when the OVS host initiates the connection to
380 the OVSDB Southbound Plugin. This happens when the OVS host is
381 configured to connect to the OVSDB Southbound Plugin. The OVS host is
382 configured with the following command:
386 sudo ovs-vsctl set-manager tcp:<controller-ip>:6640
388 The OVSDB Southbound Plugin is configured to listen for OVSDB
389 connections on TCP port 6640. This value can be changed by editing the
390 "./karaf/target/assembly/etc/custom.properties" file and changing the
391 value of the "ovsdb.listenPort" attribute.
393 When a passive connection is made, the OVSDB node will appear first in
394 the operational MD-SAL. If the Open\_vSwitch table does not contain an
395 external-ids value of *opendaylight-iid*, then the *node-id* of the new
396 OVSDB node will be created in the format:
400 "ovsdb://uuid/<actual UUID value>"
402 If there an *opendaylight-iid* value was already present in the
403 external-ids column, then the instance identifier defined there will be
404 used to create the *node-id* instead.
406 Query the operational MD-SAL for an OVSDB node after a passive
413 http://<controller-ip>:8181/restconf/operational/network-topology:network-topology/topology/ovsdb:1/
422 "topology-id": "ovsdb:1",
425 "node-id": "ovsdb://uuid/163724f4-6a70-428a-a8a0-63b2a21f12dd",
426 "ovsdb:openvswitch-external-ids": [
428 "external-id-key": "system-id",
429 "external-id-value": "ecf160af-e78c-4f6b-a005-83a6baa5c979"
432 "ovsdb:connection-info": {
433 "local-ip": "<controller-ip>",
434 "remote-port": 46731,
435 "remote-ip": "<ovs-host-ip>",
438 "ovsdb:ovs-version": "2.3.1-git4750c96",
439 "ovsdb:manager-entry": [
441 "target": "tcp:10.11.21.7:6640",
443 "number_of_connections": 1
452 Take note of the *node-id* that was created in this case.
457 The OVSDB Southbound Plugin can be used to manage bridges on an OVS
460 This example shows how to add a bridge to the OVSDB node
467 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:%2F%2FHOST1%2Fbridge%2Fbrtest
474 "network-topology:node": [
476 "node-id": "ovsdb://HOST1/bridge/brtest",
477 "ovsdb:bridge-name": "brtest",
478 "ovsdb:protocol-entry": [
480 "protocol": "ovsdb:ovsdb-bridge-protocol-openflow-13"
483 "ovsdb:managed-by": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb://HOST1']"
488 Notice that the *ovsdb:managed-by* attribute is specified in the
489 command. This indicates the association of the new bridge node with its
492 Bridges can be updated. In the following example, OpenDaylight is
493 configured to be the OpenFlow controller for the bridge.
499 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:%2F%2FHOST1%2Fbridge%2Fbrtest
506 "network-topology:node": [
508 "node-id": "ovsdb://HOST1/bridge/brtest",
509 "ovsdb:bridge-name": "brtest",
510 "ovsdb:controller-entry": [
512 "target": "tcp:<controller-ip>:6653"
515 "ovsdb:managed-by": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb://HOST1']"
520 If the OpenDaylight OpenFlow Plugin is installed, then checking on the
521 OVS host will show that OpenDaylight has successfully connected as the
522 controller for the bridge.
526 $ sudo ovs-vsctl show
530 Controller "tcp:<controller-ip>:6653"
535 ovs_version: "2.3.1-git4750c96"
537 Query the operational MD-SAL to see how the bridge appears.
543 http://<controller-ip>:8181/restconf/operational/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:%2F%2FHOST1%2Fbridge%2Fbrtest/
552 "node-id": "ovsdb://HOST1/bridge/brtest",
553 "ovsdb:bridge-name": "brtest",
554 "ovsdb:datapath-type": "ovsdb:datapath-type-system",
555 "ovsdb:datapath-id": "00:00:da:e9:0c:08:2d:45",
556 "ovsdb:managed-by": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb://HOST1']",
557 "ovsdb:bridge-external-ids": [
559 "bridge-external-id-key": "opendaylight-iid",
560 "bridge-external-id-value": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb://HOST1/bridge/brtest']"
563 "ovsdb:protocol-entry": [
565 "protocol": "ovsdb:ovsdb-bridge-protocol-openflow-13"
568 "ovsdb:bridge-uuid": "080ce9da-101e-452d-94cd-ee8bef8a4b69",
569 "ovsdb:controller-entry": [
571 "target": "tcp:10.11.21.7:6653",
572 "is-connected": true,
573 "controller-uuid": "c39b1262-0876-4613-8bfd-c67eec1a991b"
576 "termination-point": [
579 "ovsdb:port-uuid": "c808ae8d-7af2-4323-83c1-e397696dc9c8",
580 "ovsdb:ofport": 65534,
581 "ovsdb:interface-type": "ovsdb:interface-type-internal",
582 "ovsdb:interface-uuid": "49e9417f-4479-4ede-8faf-7c873b8c0413",
583 "ovsdb:name": "brtest"
590 Notice that just like with the OVSDB node, an *opendaylight-iid* has
591 been added to the external-ids column of the bridge since it was created
592 via the configuration MD-SAL.
594 A bridge node may be deleted as well.
600 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:%2F%2FHOST1%2Fbridge%2Fbrtest
605 Similarly, ports may be managed by the OVSDB Southbound Plugin.
607 This example illustrates how a port and various attributes may be
614 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:%2F%2FHOST1%2Fbridge%2Fbrtest/termination-point/testport/
621 "network-topology:termination-point": [
625 "ovsdb:option": "remote_ip",
626 "ovsdb:value" : "10.10.14.11"
629 "ovsdb:name": "testport",
630 "ovsdb:interface-type": "ovsdb:interface-type-vxlan",
643 Ports can be updated - add another VLAN trunk.
649 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:%2F%2FHOST1%2Fbridge%2Fbrtest/termination-point/testport/
656 "network-topology:termination-point": [
658 "ovsdb:name": "testport",
672 Query the operational MD-SAL for the port.
678 http://<controller-ip>:8181/restconf/operational/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:%2F%2FHOST1%2Fbridge%2Fbrtest/termination-point/testport/
685 "termination-point": [
688 "ovsdb:port-uuid": "b1262110-2a4f-4442-b0df-84faf145488d",
691 "option": "remote_ip",
692 "value": "10.10.14.11"
695 "ovsdb:port-external-ids": [
697 "external-id-key": "opendaylight-iid",
698 "external-id-value": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb://HOST1/bridge/brtest']/network-topology:termination-point[network-topology:tp-id='testport']"
701 "ovsdb:interface-type": "ovsdb:interface-type-vxlan",
710 "ovsdb:vlan-mode": "access",
712 "ovsdb:interface-uuid": "7cec653b-f407-45a8-baec-7eb36b6791c9",
713 "ovsdb:name": "testport",
719 Remember that the OVSDB YANG model includes both OVSDB port and
720 interface table attributes in the termination-point augmentation. Both
721 kinds of attributes can be seen in the examples above. Again, note the
722 creation of an *opendaylight-iid* value in the external-ids column of
731 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:%2F%2FHOST1%2Fbridge%2Fbrtest2/termination-point/testport/
733 Overview of QoS and Queue
734 ^^^^^^^^^^^^^^^^^^^^^^^^^
736 The OVSDB Southbound Plugin provides the capability of managing the QoS
737 and Queue tables on an OVS host with OpenDaylight configured as the
740 QoS and Queue Tables in OVSDB
741 '''''''''''''''''''''''''''''
743 The OVSDB includes a QoS and Queue table. Unlike most of the other
744 tables in the OVSDB, except the Open\_vSwitch table, the QoS and Queue
745 tables are "root set" tables, which means that entries, or rows, in
746 these tables are not automatically deleted if they can not be reached
747 directly or indirectly from the Open\_vSwitch table. This means that QoS
748 entries can exist and be managed independently of whether or not they
749 are referenced in a Port entry. Similarly, Queue entries can be managed
750 independently of whether or not they are referenced by a QoS entry.
752 Modelling of QoS and Queue Tables in OpenDaylight MD-SAL
753 ''''''''''''''''''''''''''''''''''''''''''''''''''''''''
755 Since the QoS and Queue tables are "root set" tables, they are modeled
756 in the OpenDaylight MD-SAL as lists which are part of the attributes of
757 the OVSDB node model.
759 The MD-SAL QoS and Queue models have an additonal identifier attribute
760 per entry (e.g. "qos-id" or "queue-id") which is not present in the
761 OVSDB schema. This identifier is used by the MD-SAL as a key for
762 referencing the entry. If the entry is created originally from the
763 configuration MD-SAL, then the value of the identifier is whatever is
764 specified by the configuration. If the entry is created on the OVSDB
765 node and received by OpenDaylight in an operational update, then the id
766 will be created in the following format.
770 "queue-id": "queue://<UUID>"
771 "qos-id": "qos://<UUID>"
773 The UUID in the above identifiers is the actual UUID of the entry in the
776 When the QoS or Queue entry is created by the configuration MD-SAL, the
777 identifier will be configured as part of the external-ids column of the
778 entry. This will ensure that the corresponding entry that is created in
779 the operational MD-SAL uses the same identifier.
783 "queues-external-ids": [
785 "queues-external-id-key": "opendaylight-queue-id",
786 "queues-external-id-value": "QUEUE-1"
790 See more in the examples that follow in this section.
792 The QoS schema in OVSDB currently defines two types of QoS entries.
798 These QoS types are defined in the QoS model. Additional types will need
799 to be added to the model in order to be supported. See the examples that
800 folow for how the QoS type is specified in the model.
802 QoS entries can be configured with addtional attritubes such as
803 "max-rate". These are configured via the *other-config* column of the
804 QoS entry. Refer to OVSDB schema (in the reference section below) for
805 all of the relevant attributes that can be configured. The examples in
806 the rest of this section will demonstrate how the other-config column
809 Similarly, the Queue entries may be configured with additional
810 attributes via the other-config column.
812 Managing QoS and Queues via Configuration MD-SAL
813 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
815 This section will show some examples on how to manage QoS and Queue
816 entries via the configuration MD-SAL. The examples will be illustrated
817 by using RESTCONF (see `QoS and Queue Postman
818 Collection <https://github.com/opendaylight/ovsdb/blob/stable/boron/resources/commons/Qos-and-Queue-Collection.json.postman_collection>`__
821 A pre-requisite for managing QoS and Queue entries is that the OVS host
822 must be present in the configuration MD-SAL.
824 For the following examples, the following OVS host is configured.
830 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/
839 "node-id": "ovsdb:HOST1",
841 "ovsdb:remote-ip": "<ovs-host-ip>",
842 "ovsdb:remote-port": "<ovs-host-ovsdb-port>"
850 - *<controller-ip>* is the IP address of the OpenDaylight controller
852 - *<ovs-host-ip>* is the IP address of the OVS host
854 - *<ovs-host-ovsdb-port>* is the TCP port of the OVSDB server on the
857 This command creates an OVSDB node with the node-id "ovsdb:HOST1". This
858 OVSDB node will be used in the following examples.
860 QoS and Queue entries can be created and managed without a port, but
861 ultimately, QoS entries are associated with a port in order to use them.
862 For the following examples a test bridge and port will be created.
864 Create the test bridge.
870 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:HOST1%2Fbridge%2Fbr-test
877 "network-topology:node": [
879 "node-id": "ovsdb:HOST1/bridge/br-test",
880 "ovsdb:bridge-name": "br-test",
881 "ovsdb:managed-by": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb:HOST1']"
886 Create the test port (which is modeled as a termination point in the
887 OpenDaylight MD-SAL).
893 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:HOST1%2Fbridge%2Fbr-test/termination-point/testport/
900 "network-topology:termination-point": [
902 "ovsdb:name": "testport",
908 If all of the previous steps were successful, a query of the operational
909 MD-SAL should look something like the following results. This indicates
910 that the configuration commands have been successfully instantiated on
917 http://<controller-ip>:8181/restconf/operational/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:HOST1%2Fbridge%2Fbr-test
926 "node-id": "ovsdb:HOST1/bridge/br-test",
927 "ovsdb:bridge-name": "br-test",
928 "ovsdb:datapath-type": "ovsdb:datapath-type-system",
929 "ovsdb:managed-by": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb:HOST1']",
930 "ovsdb:datapath-id": "00:00:8e:5d:22:3d:09:49",
931 "ovsdb:bridge-external-ids": [
933 "bridge-external-id-key": "opendaylight-iid",
934 "bridge-external-id-value": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb:HOST1/bridge/br-test']"
937 "ovsdb:bridge-uuid": "3d225d8d-d060-4909-93ef-6f4db58ef7cc",
938 "termination-point": [
941 "ovsdb:port-uuid": "f85f7aa7-4956-40e4-9c94-e6ca2d5cd254",
942 "ovsdb:ofport": 65534,
943 "ovsdb:interface-type": "ovsdb:interface-type-internal",
944 "ovsdb:interface-uuid": "29ff3692-6ed4-4ad7-a077-1edc277ecb1a",
945 "ovsdb:name": "br-test"
949 "ovsdb:port-uuid": "aa79a8e2-147f-403a-9fa9-6ee5ec276f08",
950 "ovsdb:port-external-ids": [
952 "external-id-key": "opendaylight-iid",
953 "external-id-value": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb:HOST1/bridge/br-test']/network-topology:termination-point[network-topology:tp-id='testport']"
956 "ovsdb:interface-uuid": "e96f282e-882c-41dd-a870-80e6b29136ac",
957 "ovsdb:name": "testport"
967 Create a new Queue in the configuration MD-SAL.
973 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:HOST1/ovsdb:queues/QUEUE-1/
982 "queue-id": "QUEUE-1",
984 "queues-other-config": [
986 "queue-other-config-key": "max-rate",
987 "queue-other-config-value": "3600000"
997 Now query the operational MD-SAL for the Queue entry.
1003 http://<controller-ip>:8181/restconf/operational/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:HOST1/ovsdb:queues/QUEUE-1/
1012 "queue-id": "QUEUE-1",
1013 "queues-other-config": [
1015 "queue-other-config-key": "max-rate",
1016 "queue-other-config-value": "3600000"
1019 "queues-external-ids": [
1021 "queues-external-id-key": "opendaylight-queue-id",
1022 "queues-external-id-value": "QUEUE-1"
1025 "queue-uuid": "83640357-3596-4877-9527-b472aa854d69",
1034 Create a QoS entry. Note that the UUID of the Queue entry, obtained by
1035 querying the operational MD-SAL of the Queue entry, is specified in the
1036 queue-list of the QoS entry. Queue entries may be added to the QoS entry
1037 at the creation of the QoS entry, or by a subsequent update to the QoS
1044 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:HOST1/ovsdb:qos-entries/QOS-1/
1051 "ovsdb:qos-entries": [
1054 "qos-type": "ovsdb:qos-type-linux-htb",
1055 "qos-other-config": [
1057 "other-config-key": "max-rate",
1058 "other-config-value": "4400000"
1063 "queue-number": "0",
1064 "queue-uuid": "83640357-3596-4877-9527-b472aa854d69"
1074 Query the operational MD-SAL for the QoS entry.
1080 http://<controller-ip>:8181/restconf/operational/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:HOST1/ovsdb:qos-entries/QOS-1/
1087 "ovsdb:qos-entries": [
1090 "qos-other-config": [
1092 "other-config-key": "max-rate",
1093 "other-config-value": "4400000"
1099 "queue-uuid": "83640357-3596-4877-9527-b472aa854d69"
1102 "qos-type": "ovsdb:qos-type-linux-htb",
1103 "qos-external-ids": [
1105 "qos-external-id-key": "opendaylight-qos-id",
1106 "qos-external-id-value": "QOS-1"
1109 "qos-uuid": "90ba9c60-3aac-499d-9be7-555f19a6bb31"
1117 Update the termination point entry to include the UUID of the QoS entry,
1118 obtained by querying the operational MD-SAL, to associate a QoS entry
1125 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:HOST1%2Fbridge%2Fbr-test/termination-point/testport/
1132 "network-topology:termination-point": [
1134 "ovsdb:name": "testport",
1135 "tp-id": "testport",
1136 "qos": "90ba9c60-3aac-499d-9be7-555f19a6bb31"
1144 Query the operational MD-SAL to see how the QoS entry appears in the
1145 termination point model.
1151 http://<controller-ip>:8181/restconf/operational/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:HOST1%2Fbridge%2Fbr-test/termination-point/testport/
1158 "termination-point": [
1160 "tp-id": "testport",
1161 "ovsdb:port-uuid": "aa79a8e2-147f-403a-9fa9-6ee5ec276f08",
1162 "ovsdb:port-external-ids": [
1164 "external-id-key": "opendaylight-iid",
1165 "external-id-value": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb:HOST1/bridge/br-test']/network-topology:termination-point[network-topology:tp-id='testport']"
1168 "ovsdb:qos": "90ba9c60-3aac-499d-9be7-555f19a6bb31",
1169 "ovsdb:interface-uuid": "e96f282e-882c-41dd-a870-80e6b29136ac",
1170 "ovsdb:name": "testport"
1175 Query the OVSDB Node
1176 ''''''''''''''''''''
1178 Query the operational MD-SAL for the OVS host to see how the QoS and
1179 Queue entries appear as lists in the OVS node model.
1185 http://<controller-ip>:8181/restconf/operational/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:HOST1/
1187 Result Body (edited to only show information relevant to the QoS and
1195 "node-id": "ovsdb:HOST1",
1196 <content edited out>
1199 "queue-id": "QUEUE-1",
1200 "queues-other-config": [
1202 "queue-other-config-key": "max-rate",
1203 "queue-other-config-value": "3600000"
1206 "queues-external-ids": [
1208 "queues-external-id-key": "opendaylight-queue-id",
1209 "queues-external-id-value": "QUEUE-1"
1212 "queue-uuid": "83640357-3596-4877-9527-b472aa854d69",
1216 "ovsdb:qos-entries": [
1219 "qos-other-config": [
1221 "other-config-key": "max-rate",
1222 "other-config-value": "4400000"
1228 "queue-uuid": "83640357-3596-4877-9527-b472aa854d69"
1231 "qos-type": "ovsdb:qos-type-linux-htb",
1232 "qos-external-ids": [
1234 "qos-external-id-key": "opendaylight-qos-id",
1235 "qos-external-id-value": "QOS-1"
1238 "qos-uuid": "90ba9c60-3aac-499d-9be7-555f19a6bb31"
1241 <content edited out>
1246 Remove QoS from a Port
1247 ''''''''''''''''''''''
1249 This example removes a QoS entry from the termination point and
1250 associated port. Note that this is a PUT command on the termination
1251 point with the QoS attribute absent. Other attributes of the termination
1252 point should be included in the body of the command so that they are not
1253 inadvertantly removed.
1259 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:HOST1%2Fbridge%2Fbr-test/termination-point/testport/
1266 "network-topology:termination-point": [
1268 "ovsdb:name": "testport",
1274 Remove a Queue from QoS
1275 '''''''''''''''''''''''
1277 This example removes the specific Queue entry from the queue list in the
1278 QoS entry. The queue entry is specified by the queue number, which is
1279 "0" in this example.
1285 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:HOST1/ovsdb:qos-entries/QOS-1/queue-list/0/
1290 Once all references to a specific queue entry have been removed from QoS
1291 entries, the Queue itself can be removed.
1297 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:HOST1/ovsdb:queues/QUEUE-1/
1302 The QoS entry may be removed when it is no longer referenced by any
1309 http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:HOST1/ovsdb:qos-entries/QOS-1/
1315 schema <http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf>`__
1317 `OVSDB and Netvirt Postman
1318 Collection <https://github.com/opendaylight/ovsdb/blob/stable/boron/resources/commons>`__
1320 OVSDB Hardware VTEP SouthBound Plugin
1321 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1326 Hwvtepsouthbound plugin is used to configure a hardware VTEP which
1327 implements hardware ovsdb schema. This page will show how to use
1328 RESTConf API of hwvtepsouthbound. There are two ways to connect to ODL:
1330 **switch initiates connection..**
1332 Both will be introduced respectively.
1334 User Initiates Connection
1335 ^^^^^^^^^^^^^^^^^^^^^^^^^
1340 Configure the hwvtep device/node to listen for the tcp connection in
1341 passive mode. In addition, management IP and tunnel source IP are also
1342 configured. After all this configuration is done, a physical switch is
1343 created automatically by the hwvtep node.
1345 Connect to a hwvtep device/node
1346 '''''''''''''''''''''''''''''''
1348 Send below Restconf request if you want to initiate the connection to a
1349 hwvtep node from the controller, where listening IP and port of hwvtep
1350 device/node are provided.
1353 http://odl:8181/restconf/config/network-topology:network-topology/topology/hwvtep:1/
1358 "network-topology:node": [
1360 "node-id": "hwvtep://192.168.1.115:6640",
1361 "hwvtep:connection-info":
1363 "hwvtep:remote-port": 6640,
1364 "hwvtep:remote-ip": "192.168.1.115"
1370 Please replace *odl* in the URL with the IP address of your OpenDaylight
1371 controller and change *192.168.1.115* to your hwvtep node IP.
1373 **NOTE**: The format of node-id is fixed. It will be one of the two:
1375 User initiates connection from ODL:
1381 Switch initiates connection:
1385 hwvtep://uuid/<uuid of switch>
1387 The reason for using UUID is that we can distinguish between multiple
1388 switches if they are behind a NAT.
1390 After this request is completed successfully, we can get the physical
1391 switch from the operational data store.
1394 http://odl:8181/restconf/operational/network-topology:network-topology/topology/hwvtep:1/node/hwvtep:%2F%2F192.168.1.115:6640
1396 There is no body in this request.
1398 The response of the request is:
1405 "node-id": "hwvtep://192.168.1.115:6640",
1406 "hwvtep:switches": [
1408 "switch-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640/physicalswitch/br0']"
1411 "hwvtep:connection-info": {
1412 "local-ip": "192.168.92.145",
1413 "local-port": 47802,
1414 "remote-port": 6640,
1415 "remote-ip": "192.168.1.115"
1419 "node-id": "hwvtep://192.168.1.115:6640/physicalswitch/br0",
1420 "hwvtep:management-ips": [
1422 "management-ips-key": "192.168.1.115"
1425 "hwvtep:physical-switch-uuid": "37eb5abd-a6a3-4aba-9952-a4d301bdf371",
1426 "hwvtep:managed-by": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']",
1427 "hwvtep:hwvtep-node-description": "",
1428 "hwvtep:tunnel-ips": [
1430 "tunnel-ips-key": "192.168.1.115"
1433 "hwvtep:hwvtep-node-name": "br0"
1438 If there is a physical switch which has already been created by manual
1439 configuration, we can get the node-id of the physical switch from this
1440 response, which is presented in “swith-ref”. If the switch does not
1441 exist, we need to create the physical switch. Currently, most hwvtep
1442 devices do not support running multiple switches.
1444 Create a physical switch
1445 ''''''''''''''''''''''''
1448 http://odl:8181/restconf/config/network-topology:network-topology/topology/hwvtep:1/
1455 "network-topology:node": [
1457 "node-id": "hwvtep://192.168.1.115:6640/physicalswitch/br0",
1458 "hwvtep-node-name": "ps0",
1459 "hwvtep-node-description": "",
1462 "management-ips-key": "192.168.1.115"
1467 "tunnel-ips-key": "192.168.1.115"
1470 "managed-by": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']"
1475 Note: "managed-by" must provided by user. We can get its value after the
1476 step *Connect to a hwvtep device/node* since the node-id of hwvtep
1477 device is provided by user. "managed-by" is a reference typed of
1478 instance identifier. Though the instance identifier is a little
1479 complicated for RestConf, the primary user of hwvtepsouthbound plugin
1480 will be provider-type code such as NetVirt and the instance identifier
1481 is much easier to write code for.
1483 Create a logical switch
1484 '''''''''''''''''''''''
1486 Creating a logical switch is effectively creating a logical network. For
1487 VxLAN, it is a tunnel network with the same VNI.
1490 http://odl:8181/restconf/config/network-topology:network-topology/topology/hwvtep:1/node/hwvtep:%2F%2F192.168.1.115:6640
1497 "logical-switches": [
1499 "hwvtep-node-name": "ls0",
1500 "hwvtep-node-description": "",
1501 "tunnel-key": "10000"
1506 Create a physical locator
1507 '''''''''''''''''''''''''
1509 After the VXLAN network is ready, we will add VTEPs to it. A VTEP is
1510 described by a physical locator.
1513 http://odl:8181/restconf/config/network-topology:network-topology/topology/hwvtep:1/node/hwvtep:%2F%2F192.168.1.115:6640
1520 "termination-point": [
1522 "tp-id": "vxlan_over_ipv4:192.168.0.116",
1523 "encapsulation-type": "encapsulation-type-vxlan-over-ipv4",
1524 "dst-ip": "192.168.0.116"
1529 The "tp-id" of locator is "{encapsualation-type}: {dst-ip}".
1531 Note: As far as we know, the OVSDB database does not allow the insertion
1532 of a new locator alone. So, no locator is inserted after this request is
1533 sent. We will trigger off the creation until other entity refer to it,
1534 such as remote-mcast-macs.
1536 Create a remote-mcast-macs entry
1537 ''''''''''''''''''''''''''''''''
1539 After adding a physical locator to a logical switch, we need to create a
1540 remote-mcast-macs entry to handle unknown traffic.
1543 http://odl:8181/restconf/config/network-topology:network-topology/topology/hwvtep:1/node/hwvtep:%2F%2F192.168.1.115:6640
1550 "remote-mcast-macs": [
1552 "mac-entry-key": "00:00:00:00:00:00",
1553 "logical-switch-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']/hwvtep:logical-switches[hwvtep:hwvtep-node-name='ls0']",
1556 "locator-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://219.141.189.115:6640']/network-topology:termination-point[network-topology:tp-id='vxlan_over_ipv4:192.168.0.116']"
1563 The physical locator *vxlan\_over\_ipv4:192.168.0.116* is just created
1564 in "Create a physical locator". It should be noted that list
1565 "locator-set" is immutable, that is, we must provide a set of
1566 "locator-ref" as a whole.
1568 Note: "00:00:00:00:00:00" stands for "unknown-dst" since the type of
1569 mac-entry-key is yang:mac and does not accept "unknown-dst".
1571 Create a physical port
1572 ''''''''''''''''''''''
1574 Now we add a physical port into the physical switch
1575 "hwvtep://192.168.1.115:6640/physicalswitch/br0". The port is attached
1576 with a physical server or an L2 network and with the vlan 100.
1579 http://odl:8181/restconf/config/network-topology:network-topology/topology/hwvtep:1/node/hwvtep:%2F%2F192.168.1.115:6640%2Fphysicalswitch%2Fbr0
1584 "network-topology:termination-point": [
1587 "hwvtep-node-name": "port0",
1588 "hwvtep-node-description": "",
1591 "vlan-id-key": "100",
1592 "logical-switch-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']/hwvtep:logical-switches[hwvtep:hwvtep-node-name='ls0']"
1599 At this point, we have completed the basic configuration.
1601 Typically, hwvtep devices learn local MAC addresses automatically. But
1602 they also support getting MAC address entries from ODL.
1604 Create a local-mcast-macs entry
1605 '''''''''''''''''''''''''''''''
1607 It is similar to *Create a remote-mcast-macs entry*.
1609 Create a remote-ucast-macs
1610 ''''''''''''''''''''''''''
1613 http://odl:8181/restconf/config/network-topology:network-topology/topology/hwvtep:1/node/hwvtep:%2F%2F192.168.1.115:6640
1622 "remote-ucast-macs": [
1624 "mac-entry-key": "11:11:11:11:11:11",
1625 "logical-switch-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']/hwvtep:logical-switches[hwvtep:hwvtep-node-name='ls0']",
1626 "ipaddr": "1.1.1.1",
1627 "locator-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']/network-topology:termination-point[network-topology:tp-id='vxlan_over_ipv4:192.168.0.116']"
1632 Create a local-ucast-macs entry
1633 '''''''''''''''''''''''''''''''
1635 This is similar to *Create a remote-ucast-macs*.
1637 Switch Initiates Connection
1638 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
1640 We do not need to connect to a hwvtep device/node when the switch
1641 initiates the connection. After switches connect to ODL successfully, we
1642 get the node-id’s of switches by reading the operational data store.
1643 Once the node-id of a hwvtep device is received, the remaining steps are
1644 the same as when the user initiates the connection.
1649 https://wiki.opendaylight.org/view/User_talk:Pzhang