7 The Open vSwitch database (OVSDB) Southbound Plugin component for
8 OpenDaylight implements the OVSDB `RFC
9 7047 <https://tools.ietf.org/html/rfc7047>`__ management protocol that
10 allows the southbound configuration of switches that support OVSDB. The
11 component comprises a library and a plugin. The OVSDB protocol uses
12 JSON-RPC calls to manipulate a physical or virtual switch that supports
13 OVSDB. Many vendors support OVSDB on various hardware platforms. The
14 OpenDaylight controller uses the library project to interact with an OVS
19 Read the OVSDB User Guide before you begin development.
21 OpenDaylight OVSDB integration
22 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
24 The OpenStack integration architecture uses the following technologies:
26 - `RFC 7047 <https://tools.ietf.org/html/rfc7047>`__ - The Open vSwitch
27 Database Management Protocol
30 v1.3 <http://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.3.4.pdf>`__
32 - `OpenStack Neutron ML2
33 Plugin <https://wiki.openstack.org/wiki/Neutron/ML2>`__
35 OpenDaylight Mechanism Driver for Openstack Neutron ML2
36 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
38 This code is a part of OpenStack and is available at:
39 https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mechanism_odl.py
41 The ODL neutron driver implementation can be found at:
42 https://github.com/openstack/networking-odl
44 To make changes to this code, please read about `Neutron
45 Development <https://wiki.openstack.org/wiki/NeutronDevelopment>`__.
47 Before submitting the code, run the following tests:
54 Importing the code in to Eclipse or IntelliJ
55 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
57 To import code, look at either of the following pages:
59 - `Getting started with
60 Eclipse <https://wiki.opendaylight.org/view/Eclipse_Setup>`__
63 Intellij <https://wiki.opendaylight.org/view/OpenDaylight_Controller:Developing_With_Intellij>`__
65 .. figure:: ./images/OVSDB_Eclipse.png
66 :alt: Avoid conflicting project names
68 Avoid conflicting project names
70 - To ensure that a project in Eclipse does not have a conflicting name
71 in the workspace, select Advanced > Name Template >
72 [groupId].[artifactId] when importing the project.
77 The code is mirrored to
78 `GitHub <https://github.com/opendaylight/ovsdb>`__ to make reading code
81 Source code organization
82 ^^^^^^^^^^^^^^^^^^^^^^^^
84 The OVSDB project generates the following Karaf modules:
86 - ovsdb.karaf — all openstack netvirt related artifacts
88 - ovsdb.library-karaf — the OVSDB library reference implementation
90 - ovsdb.openstack.net-virt-sfc-karaf — OpenFlow service function
93 - ovsdb.hwvtepsouthbound-karaf — the hw\_vtep schema southbound plugin
95 - ovsdb.southbound-karaf - the Open\_vSwitch schema plugin
97 Following are a brief descriptions on directories you will find a the
98 root ovsdb/ directory:
100 - *commons* contains the parent POM file for Maven project which is
101 used to get consistency of settings across the project.
103 - *features* contains all the Karaf related feature files.
105 - *hwvtepsouthbound* contains the hw\_vtep southbound plugin.
107 - *karaf* contains the ovsdb library and southbound and OpenStack
108 bundles for the OpenStack integration.
110 - *library* contains a schema-independent library that is a reference
111 implementation for RFC 7047.
113 - *openstack* contains the northbound handlers for Neutron used by
114 OVSDB, as well as their providers. The NetVirt SFC implementation is
117 - *ovsdb-ui* contains the DLUX implementation for displaying network
120 - *resources* contains useful scripts, how-tos, demos and other
123 - *schemas* contains the OVSDB schemas that are implemented in
126 - *southbound* contains the plugin for converting from the OVSDB
127 protocol to MD-SAL and vice-versa.
129 - *utils* contains a collection of utilities for using the OpenFlow
130 plugin, southbound, Neutron and other helper methods.
132 Building and running OVSDB
133 ~~~~~~~~~~~~~~~~~~~~~~~~~~
141 Building a Karaf feature and deploying it in an OpenDaylight Karaf distribution
142 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
144 1. From the root ovsdb/ directory, run **mvn clean install**.
146 2. Unzip the karaf-<VERSION\_NUMBER>-SNAPSHOT.zip file created from step
147 1 in the directory ovsdb/karaf/target/:
151 unzip karaf-<VERSION_NUMBER>-SNAPSHOT.zip
153 Downloading OVSDB’s Karaf distribution
154 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
156 Instead of building, you can download the latest OVSDB distribution from
157 the Nexus server. The link for that is:
161 https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/ovsdb/karaf/1.3.0-SNAPSHOT/
163 Running Karaf feature from OVSDB’s Karaf distribution
164 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
166 1. Start ODL, from the unzipped directory
172 2. Once karaf has started, and you see the OpenDaylight ascii art in the
173 console, the last step is to start the OVSDB plugin framework with
174 the following command in the karaf console:
178 feature:install odl-ovsdb-openstack
180 Sample output from the Karaf console
181 ''''''''''''''''''''''''''''''''''''
185 opendaylight-user@root>feature:list | grep -i ovsdb
186 opendaylight-user@root>feature:list -i | grep ovsdb
187 odl-ovsdb-southbound-api | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound :: api
188 odl-ovsdb-southbound-impl | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound :: impl
189 odl-ovsdb-southbound-impl-rest | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound :: impl :: REST
190 odl-ovsdb-southbound-impl-ui | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound :: impl :: UI
191 odl-ovsdb-library | 1.2.1-SNAPSHOT | x | odl-ovsdb-library-1.2.1-SNAPSHOT | OpenDaylight :: library
192 odl-ovsdb-openstack | 1.2.1-SNAPSHOT | x | ovsdb-1.2.1-SNAPSHOT | OpenDaylight :: OVSDB :: OpenStack Network Virtual
197 It is recommended that you test your patches locally before submission.
202 To test patches to the Neutron integration, you need a `Multi-Node
203 Devstack Setup <http://devstack.org/guides/multinode-lab.html>`__. The
204 \`\`resources\`\` folder contains sample \`\`local.conf\`\` files.
209 To test patches to the library, you will need a working `Open
210 vSwitch <http://openvswitch.org/>`__. Packages are available for most
211 Linux distributions. If you would like to run multiple versions of Open
212 vSwitch for testing you can use
213 `docker-ovs <https://github.com/dave-tucker/docker-ovs>`__ to run Open
214 vSwitch in `Docker <https://www.docker.com/>`__ containers.
219 `Mininet <http://mininet.org/>`__ is another useful resource for testing
220 patches. Mininet creates multiple Open vSwitches connected in a
221 configurable topology.
226 The Vagrant file in the root of the OVSDB source code provides an easy
227 way to create VMs for tests.
229 - To install Vagrant on your machine, follow the steps at: `Installing
230 Vagrant <https://docs.vagrantup.com/v2/installation/>`__.
232 **Testing with Devstack**
234 1. Start the controller.
238 vagrant up devstack-control
239 vagrant ssh devstack-control
243 2. Run the following:
247 vagrant up devstack-compute-1
248 vagrant ssh devstack-compute-1
252 3. To start testing, create a new VM.
256 nova boot --flavor m1.tiny --image $(nova image-list | grep 'cirros-0.3.1-x86_64-uec\s' | awk '{print $2}') --nic net-id=$(neutron net-list | grep private | awk '{print $2}') test
258 To create three, use the following:
262 nova boot --flavor m1.tiny --image $(nova image-list | grep 'cirros-0.3.1-x86_64-uec\s' | awk '{print $2}') --nic net-id=$(neutron net-list | grep private | awk '{print $2}') --num-instances 3 test
264 **To get a mininet installation for testing:.**
271 1. Use the following to clean up when finished:
277 OVSDB integration design
278 ~~~~~~~~~~~~~~~~~~~~~~~~
286 Heresy <http://networkheresy.com/2012/09/15/remembering-the-management-plane/>`__
288 | See the OVSDB YouTube Channel for getting started videos and other
292 Channel <http://www.youtube.com/channel/UCMYntfZ255XGgYFrxCNcAzA>`__
295 Tutorial <https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial>`__
298 Started <https://wiki.opendaylight.org/view/OVSDB_Integration:Main#Getting_Started_with_OpenDaylight_OVSDB_Plugin_Network_Virtualization>`__
300 OpenDaylight OVSDB southbound plugin architecture and design
301 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
303 OpenVSwitch (OVS) is generally accepted as the unofficial standard for
304 Virtual Switching in the Open hypervisor based solutions. Every other
305 Virtual Switch implementation, properietery or otherwise, uses OVS in
306 some form. For information on OVS, see `Open
307 vSwitch <http://openvswitch.org/>`__.
309 In Software Defined Networking (SDN), controllers and applications
310 interact using two channels: OpenFlow and OVSDB. OpenFlow addresses the
311 forwarding-side of the OVS functionality. OVSDB, on the other hand,
312 addresses the management-plane. A simple and concise overview of Open
313 Virtual Switch Database(OVSDB) is available at:
314 http://networkstatic.net/getting-started-ovsdb/
316 Overview of OpenDaylight Controller architecture
317 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
319 The OpenDaylight controller platform is designed as a highly modular and
320 plugin based middleware that serves various network applications in a
321 variety of use-cases. The modularity is achieved through the Java OSGi
322 framework. The controller consists of many Java OSGi bundles that work
323 together to provide the required controller functionalities.
325 | The bundles can be placed in the following broad categories:
327 - Network Service Functional Modules (Examples: Topology Manager,
328 Inventory Manager, Forwarding Rules Manager,and others)
330 - NorthBound API Modules (Examples: Topology APIs, Bridge Domain APIs,
331 Neutron APIs, Connection Manager APIs, and others)
333 - Service Abstraction Layer(SAL)- (Inventory Services, DataPath
334 Services, Topology Services, Network Config, and others)
336 - SouthBound Plugins (OpenFlow Plugin, OVSDB Plugin, OpenDove Plugin,
339 - Application Modules (Simple Forwarding, Load Balancer)
341 Each layer of the Controller architecture performs specified tasks, and
342 hence aids in modularity. While the Northbound API layer addresses all
343 the REST-Based application needs, the SAL layer takes care of
344 abstracting the SouthBound plugin protocol specifics from the Network
347 Each of the SouthBound Plugins serves a different purpose, with some
348 overlapping. For example, the OpenFlow plugin might serve the Data-Plane
349 needs of an OVS element, while the OVSDB plugin can serve the management
350 plane needs of the same OVS element. As the OpenFlow Plugin talks
351 OpenFlow protocol with the OVS element, the OVSDB plugin will use OVSDB
352 schema over JSON-RPC transport.
354 OVSDB southbound plugin
355 ~~~~~~~~~~~~~~~~~~~~~~~
357 | The `Open vSwitch Database Management
358 Protocol-draft-02 <http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02>`__
360 Manual <http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf>`__ provide
361 theoretical information about OVSDB. The OVSDB protocol draft is
362 generic enough to lay the groundwork on Wire Protocol and Database
363 Operations, and the OVS Manual currently covers 13 tables leaving
364 space for future OVS expansion, and vendor expansions on proprietary
365 implementations. The OVSDB Protocol is a database records transport
366 protocol using JSON RPC1.0. For information on the protocol structure,
367 see `Getting Started with
368 OVSDB <http://networkstatic.net/getting-started-ovsdb/>`__. The
369 OpenDaylight OVSDB southbound plugin consists of one or more OSGi
370 bundles addressing the following services or functionalities:
372 - Connection Service - Based on Netty
374 - Network Configuration Service
376 - Bidirectional JSON-RPC Library
378 - OVSDB Schema definitions and Object mappers
380 - Overlay Tunnel management
382 - OVSDB to OpenFlow plugin mapping service
389 | One of the primary services that most southbound plugins provide in
390 OpenDaylight a Connection Service. The service provides protocol
391 specific connectivity to network elements, and supports the
392 connectivity management services as specified by the OpenDaylight
393 Connection Manager. The connectivity services include:
395 - Connection to a specified element given IP-address, L4-port, and
396 other connectivity options (such as authentication,…)
398 - Disconnection from an element
400 - Handling Cluster Mode change notifications to support the
401 OpenDaylight Clustering/High-Availability feature
403 Network Configuration Service
404 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
406 | The goal of the OpenDaylight Network Configuration services is to
407 provide complete management plane solutions needed to successfully
408 install, configure, and deploy the various SDN based network services.
409 These are generic services which can be implemented in part or full by
410 any south-bound protocol plugin. The south-bound plugins can be either
413 - The new network virtualization protocol plugins such as OVSDB
416 - The traditional management protocols such as SNMP or any others in
419 The above definition, and more information on Network Configuration
420 Services, is available at :
421 https://wiki.opendaylight.org/view/OpenDaylight_Controller:NetworkConfigurationServices
423 Bidirectional JSON-RPC library
424 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
426 The OVSDB plugin implements a Bidirectional JSON-RPC library. It is easy
427 to design the library as a module that manages the Netty connection
430 | The main responsibilities of this Library are:
432 - Demarshal and marshal JSON Strings to JSON objects
434 - Demarshal and marshal JSON Strings from and to the Network Element.
436 OVSDB Schema definitions and Object mappers
437 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
439 The OVSDB Schema definitions and Object Mapping layer sits above the
440 JSON-RPC library. It maps the generic JSON objects to OVSDB schema POJOs
441 (Plain Old Java Object) and vice-versa. This layer mostly provides the
442 Java Object definition for the corresponding OVSDB schema (13 of them)
443 and also will provide much more friendly API abstractions on top of
444 these object data. This helps in hiding the JSON semantics from the
445 functional modules such as Configuration Service and Tunnel management.
447 | On the demarshaling side the mapping logic differentiates the Request
448 and Response messages as follows :
450 - Request messages are mapped by its "method"
452 - | Response messages are mapped by their IDs which were originally
453 populated by the Request message. The JSON semantics of these OVSDB
454 schema is quite complex. The following figures summarize two of the
455 end-to-end scenarios:
457 .. figure:: ./images/ConfigurationService-example1.png
458 :alt: End-to-end handling of a Create Bridge request
460 End-to-end handling of a Create Bridge request
462 .. figure:: ./images/MonitorResponse.png
463 :alt: End-to-end handling of a monitor response
465 End-to-end handling of a monitor response
467 Overlay tunnel management
468 ^^^^^^^^^^^^^^^^^^^^^^^^^
470 Network Virtualization using OVS is achieved through Overlay Tunnels.
471 The actual Type of the Tunnel may be GRE, VXLAN, or STT. The differences
472 in the encapsulation and configuration decide the tunnel types.
473 Establishing a tunnel using configuration service requires just the
474 sending of OVSDB messages towards the ovsdb-server. However, the scaling
475 issues that would arise on the state management at the data-plane (using
476 OpenFlow) can get challenging. Also, this module can assist in various
477 optimizations in the presence of Gateways. It can also help in providing
478 Service guarantees for the VMs using these overlays with the help of
479 underlay orchestration.
481 OVSDB to OpenFlow plugin mapping service
482 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
484 | The connect() of the ConnectionService would result in a Node that
485 represents an ovsdb-server. The CreateBridgeDomain() Configuration on
486 the above Node would result in creating an OVS bridge. This OVS Bridge
487 is an OpenFlow Agent for the OpenDaylight OpenFlow plugin with its own
488 Node represented as (example) OF\|xxxx.yyyy.zzzz. Without any help
489 from the OVSDB plugin, the Node Mapping Service of the Controller
490 platform would not be able to map the following:
494 {OVSDB_NODE + BRIDGE_IDENTFIER} <---> {OF_NODE}.
496 Without such mapping, it would be extremely difficult for the
497 applications to manage and maintain such nodes. This Mapping Service
498 provided by the OVSDB plugin would essentially help in providing more
499 value added services to the orchestration layers that sit atop the
500 Northbound APIs (such as OpenStack).
502 OpenDaylight OVSDB Developer Getting Started Video Series
503 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
505 The video series were started to help developers bootstrap into OVSDB
508 - `OpenDaylight OVSDB Developer Getting
509 Started <http://www.youtube.com/watch?v=ieB645oCIPs>`__
511 - `OpenDaylight OVSDB Developer Getting Started - Northbound API
512 Usage <http://www.youtube.com/watch?v=xgevyaQ12cg>`__
514 - `OpenDaylight OVSDB Developer Getting Started - Java
515 APIs <http://www.youtube.com/watch?v=xgevyaQ12cg>`__
517 - `OpenDaylight OVSDB Developer Getting Started - OpenStack Integration
518 OpenFlow v1.0 <http://www.youtube.com/watch?v=NayuY6J-AMA>`__
520 Other developer tutorials
521 ^^^^^^^^^^^^^^^^^^^^^^^^^
524 Tutorial <https://docs.google.com/presentation/d/1KIuNDuUJGGEV37Zk9yzx9OSnWExt4iD2Z7afycFLf_I/edit?usp=sharing>`__
526 - `Youtube of OVSDB NetVirt
527 tutorial <https://www.youtube.com/watch?v=2axNKHvt5MY&list=PL8F5jrwEpGAiJG252ShQudYeodGSsks2l&index=43>`__
529 - `OVSDB OpenFlow v1.3 Neutron ML2
530 Integration <https://wiki.opendaylight.org/view/OVSDB:OVSDB_OpenStack_Guide>`__
532 - `Open vSwitch Database Table Explanations and Simple Jackson
533 Tutorial <http://networkstatic.net/getting-started-ovsdb/>`__
535 OVSDB integration: New features
536 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
538 Schema independent library
539 ^^^^^^^^^^^^^^^^^^^^^^^^^^
541 The OVS connection is a node which can have multiple databases. Each
542 database is represented by a schema. A single connection can have
543 multiple schemas. OSVDB supports multiple schemas. Currently, these are
544 two schemas available in the OVSDB, but there is no restriction on the
545 number of schemas. Owing to the Northbound v3 API, no code changes in
546 ODL are needed for supporting additional schemas.
550 - openvswitch : Schema wrapper that represents
551 http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf
553 - hardwarevtep: Schema wrapper that represents
554 http://openvswitch.org/docs/vtep.5.pdf
559 Based on the fact that security rules can be obtained from a port
560 object, OVSDB can apply Open Flow rules. These rules will match on what
561 types of traffic the Openstack tenant VM is allowed to use.
563 Support for security groups is very experimental. There are limitations
564 in determining the state of flows in the Open vSwitch. See `Open vSwitch
566 Edge <http://%20https//www.youtube.com/watch?v=DSop2uLJZS8>`__ from
567 Justin Petit for a deep dive into the challenges we faced creating a
568 flow based port security implementation. The current set of rules that
569 will be installed only supports filtering of the TCP protocol. This is
570 because via a Nicira TCP\_Flag read we can match on a flows TCP\_SYN
571 flag, and permit or deny the flow based on the Neutron port security
572 rules. If rules are requested for ICMP and UDP, they are ignored until
573 greater visibility from the Linux kernel is available as outlined in the
574 OpenStack presentation mentioned earlier.
576 Using the port security groups of Neutron, one can add rules that
577 restrict the network access of the tenants. The OVSDB Neutron
578 integration checks the port security rules configured, and apply them by
579 means of OpenFlow rules.
581 Through the ML2 interface, Neutron security rules are available in the
582 port object, following this scope: Neutron Port → Security Group →
585 The current rules are applied on the basis of the following attributes:
586 ingress/egress, tcp protocol, port range, and prefix.
593 2. Add the network and subnet.
595 3. Add the Security Group and Rules.
599 This is no different than what users normally do in regular
600 OpenStack deployments.
604 neutron security-group-create group1 --description "Group 1"
605 neutron security-group-list
606 neutron security-group-rule-create --direction ingress --protocol tcp group1
608 4. Start the tenant, specifying the security-group.
612 nova boot --flavor m1.tiny \
613 --image $(nova image-list | grep 'cirros-0.3.1-x86_64-uec\s' | awk '{print $2}') \
614 --nic net-id=$(neutron net-list | grep 'vxlan2' | awk '{print $2}') vxlan2 \
615 --security-groups group1
617 Examples: Rules supported
618 '''''''''''''''''''''''''
622 neutron security-group-create group2 --description "Group 2"
623 neutron security-group-rule-create --direction ingress --protocol tcp --port-range-min 54 group2
624 neutron security-group-rule-create --direction ingress --protocol tcp --port-range-min 80 group2
625 neutron security-group-rule-create --direction ingress --protocol tcp --port-range-min 1633 group2
626 neutron security-group-rule-create --direction ingress --protocol tcp --port-range-min 22 group2
630 neutron security-group-create group3 --description "Group 3"
631 neutron security-group-rule-create --direction ingress --protocol tcp --remote-ip-prefix 10.200.0.0/16 group3
635 neutron security-group-create group4 --description "Group 4"
636 neutron security-group-rule-create --direction ingress --remote-ip-prefix 172.24.0.0/16 group4
640 neutron security-group-create group5 --description "Group 5"
641 neutron security-group-rule-create --direction ingress --protocol tcp group5
642 neutron security-group-rule-create --direction ingress --protocol tcp --port-range-min 54 group5
643 neutron security-group-rule-create --direction ingress --protocol tcp --port-range-min 80 group5
644 neutron security-group-rule-create --direction ingress --protocol tcp --port-range-min 1633 group5
645 neutron security-group-rule-create --direction ingress --protocol tcp --port-range-min 22 group5
649 neutron security-group-create group6 --description "Group 6"
650 neutron security-group-rule-create --direction ingress --protocol tcp --remote-ip-prefix 0.0.0.0/0 group6
654 neutron security-group-create group7 --description "Group 7"
655 neutron security-group-rule-create --direction egress --protocol tcp --port-range-min 443 --remote-ip-prefix 172.16.240.128/25 group7
658 gist**: `Gist <https://gist.github.com/anonymous/1543a410d57f491352c8>`__
660 Security group rules supported in ODL
661 '''''''''''''''''''''''''''''''''''''
663 The following rules formats are supported in the current implementation.
664 The direction (ingress/egress) is always expected. Rules are implemented
665 such that tcp-syn packets that do not satisfy the rules are dropped.
667 +--------------------------+--------------------------+--------------------------+
668 | Proto | Port | IP Prefix |
669 +==========================+==========================+==========================+
671 +--------------------------+--------------------------+--------------------------+
673 +--------------------------+--------------------------+--------------------------+
675 +--------------------------+--------------------------+--------------------------+
677 +--------------------------+--------------------------+--------------------------+
682 - Soon, conntrack will be supported by OVS. Until then, TCP flags are
683 used as way of checking for connection state. Specifically, that is
684 done by matching on the TCP-SYN flag.
686 - The param *--port-range-max* in *security-group-rule-create* is not
687 used until the implementation uses contrack.
689 - No UDP/ICMP specific match support is provided.
691 - No IPv6 support is provided.
696 OVSDB extends support for the usage of an ODL-Neutron-driver so that
697 OVSDB can configure OF 1.3 rules to route IPv4 packets. The driver
698 eliminates the need for the router of the L3 Agent. In order to
699 accomplish that, OVS 2.1 or a newer version is required. OVSDB also
700 supports inbound/outbound NAT, floating IPs.
702 Starting OVSDB and OpenStack
703 ''''''''''''''''''''''''''''
705 1. Build or download OVSDB distribution, as mentioned in `building a
706 Karaf feature section <#ovsdbBuildSteps>`__.
709 Vagrant <http://docs.vagrantup.com/v2/installation/index.html>`__.
711 3. Enable the L3 Forwarding feature:
715 echo 'ovsdb.l3.fwd.enabled=yes' >> ./opendaylight/configuration/config.ini
716 echo 'ovsdb.l3gateway.mac=${GATEWAY_MAC}' >> ./configuration/config.ini
718 4. Run the following commands to get the odl neutron drivers:
722 git clone https://github.com/dave-tucker/odl-neutron-drivers.git
723 cd odl-neutron-drivers
724 vagrant up devstack-control devstack-compute-1
726 5. Use ssh to go to the control node, and clone odl-neutron-drivers
731 vagrant ssh devstack-control
732 git clone https://github.com/dave-tucker/odl-neutron-drivers.git
733 cd odl-neutron-drivers
734 sudo python setup.py install
735 *leave this shell open*
737 6. Start odl, as mentioned in `running Karaf feature
738 section <#ovsdbStartingOdl>`__.
740 7. To see processing of neutron event related to L3, do this from
745 log:set debug org.opendaylight.ovsdb.openstack.netvirt.impl.NeutronL3Adapter
747 8. From shell, do one of the following: open on ssh into control node or
748 vagrant ssh devstack-control.
752 cd ~/devstack && ./stack.sh
754 9. From a new shell in the host system, run the following:
758 cd odl-neutron-drivers
759 vagrant ssh devstack-compute-1
760 cd ~/devstack && ./stack.sh
765 .. figure:: ./images/L3FwdSample.png
766 :alt: Sample workflow
770 Use the following steps to set up a workflow like the one shown in
773 1. Set up authentication. From shell on stack control or vagrant ssh
778 source openrc admin admin
780 rm -f id_rsa_demo* ; ssh-keygen -t rsa -b 2048 -N -f id_rsa_demo
781 nova keypair-add --pub-key id_rsa_demo.pub demo_key
784 2. Create two networks and two subnets.
788 neutron net-create net1 --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
789 --provider:network_type gre --provider:segmentation_id 555
791 neutron subnet-create --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
792 net1 10.0.0.0/16 --name subnet1 --dns-nameserver 8.8.8.8
794 neutron net-create net2 --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
795 --provider:network_type gre --provider:segmentation_id 556
797 neutron subnet-create --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
798 net2 20.0.0.0/16 --name subnet2 --dns-nameserver 8.8.8.8
800 3. Create a router, and add an interface to each of the two subnets.
804 neutron router-create demorouter --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}')
805 neutron router-interface-add demorouter subnet1
806 neutron router-interface-add demorouter subnet2
807 # neutron router-port-list demorouter
809 4. Create two tenant instances.
813 nova boot --poll --flavor m1.nano --image $(nova image-list | grep 'cirros-0.3.2-x86_64-uec\s' | awk '{print $2}') \
814 --nic net-id=$(neutron net-list | grep -w net1 | awk '{print $2}'),v4-fixed-ip=10.0.0.10 \
815 --availability-zone nova:devstack-control \
816 --key-name demo_key host10
818 nova boot --poll --flavor m1.nano --image $(nova image-list | grep 'cirros-0.3.2-x86_64-uec\s' | awk '{print $2}') \
819 --nic net-id=$(neutron net-list | grep -w net2 | awk '{print $2}'),v4-fixed-ip=20.0.0.20 \
820 --availability-zone nova:devstack-compute-1 \
821 --key-name demo_key host20
826 - To use this feature, you need OVS 2.1 or newer version.
828 - Owing to OF limitations, icmp responses due to routing failures, like
829 ttl expired or host unreacheable, are not generated.
831 - The MAC address of the default route is not automatically mapped. In
832 order to route to L3 destinations outside the networks of the tenant,
833 the manual configuration of the default route is necessary. To
834 provide the MAC address of the default route, use ovsdb.l3gateway.mac
835 in file configuration/config.ini ;
837 - This feature is Tech preview, which depends on later versions of
838 OpenStack to be used without the provided neutron-driver.
840 - No IPv6 support is provided.
842 | **More information on L3 forwarding**:
844 - odl-neutron-driver:
845 https://github.com/dave-tucker/odl-neutron-drivers
848 http://dtucker.co.uk/hack/building-a-router-with-openvswitch.html
853 Load-Balancing-as-a-Service (LBaaS) creates an Open vSwitch powered
854 L3-L4 stateless load-balancer in a virtualized network environment so
855 that individual TCP connections destined to a designated virtual IP
856 (VIP) are sent to the appropriate servers (that is to say, serving app
857 VMs). The load-balancer works in a session-preserving, proactive manner
858 without involving the controller during flow setup.
860 A Neutron northbound interface is provided to create a VIP which will
861 map to a pool of servers (that is to say, members) within a subnet. The
862 pools consist of members identified by an IP address. The goal is to
863 closely match the API to the OpenStack LBaaS v2 API:
864 http://docs.openstack.org/api/openstack-network/2.0/content/lbaas_ext.html.
866 Creating an OpenStack workflow
867 ''''''''''''''''''''''''''''''
871 2. Create a floating VIP *A* that maps to a private VIP *B*.
873 3. Create a Loadbalancer pool *X*.
877 neutron lb-pool-create --name http-pool --lb-method ROUND_ROBIN --protocol HTTP --subnet-id XYZ
879 4. Create a Loadbalancer pool member *Y* and associate with pool *X*.
883 neutron lb-member-create --address 10.0.0.10 --protocol-port 80 http-pool
884 neutron lb-member-create --address 10.0.0.11 --protocol-port 80 http-pool
885 neutron lb-member-create --address 10.0.0.12 --protocol-port 80 http-pool
886 neutron lb-member-create --address 10.0.0.13 --protocol-port 80 http-pool
888 5. Create a Loadbalancer instance *Z*, and associate pool *X* and VIP
893 neutron lb-vip-create --name http-vip --protocol-port 80 --protocol HTTP --subnet-id XYZ http-pool
898 The current implementation of the proactive stateless load-balancer was
899 made using "multipath" action in the Open vSwitch. The "multipath"
900 action takes a max\_link parameter value (which is same as the number of
901 pool members) as input, and performs a hash of the fields to get a value
902 between (0, max\_link). The value of the hash is used as an index to
903 select a pool member to handle that session.
908 Assuming that table=20 contains all the rules to forward the traffic
909 destined for a specific destination MAC address, the following are the
910 rules needed to be programmed in the LBaaS service table=10. The
911 programmed rules makes the translation from the VIP to a different pool
912 member for every session.
914 - Proactive forward rules:
918 sudo ovs-ofctl -O OpenFlow13 add-flow s1 "table=10,reg0=0,ip,nw_dst=10.0.0.5,actions=load:0x1->NXM_NX_REG0[[]],multipath(symmetric_l4, 1024, modulo_n, 4, 0, NXM_NX_REG1[0..12]),resubmit(,10)"
919 sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,reg0=1,nw_dst=10.0.0.5,ip,reg1=0,actions=mod_dl_dst:00:00:00:00:00:10,mod_nw_dst:10.0.0.10,goto_table:20
920 sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,reg0=1,nw_dst=10.0.0.5,ip,reg1=1,actions=mod_dl_dst:00:00:00:00:00:11,mod_nw_dst:10.0.0.11,goto_table:20
921 sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,reg0=1,nw_dst=10.0.0.5,ip,reg1=2,actions=mod_dl_dst:00:00:00:00:00:12,mod_nw_dst:10.0.0.12,goto_table:20
922 sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,reg0=1,nw_dst=10.0.0.5,ip,reg1=3,actions=mod_dl_dst:00:00:00:00:00:13,mod_nw_dst:10.0.0.13,goto_table:20
924 - Proactive reverse rules:
928 sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,ip,tcp,tp_src=80,actions=mod_dl_src:00:00:00:00:00:05,mod_nw_src:10.0.0.5,goto_table:20
933 The current implementation handles all neutron calls in the
934 net-virt/LBaaSHandler.java code, and makes calls to the
935 net-virt-providers/LoadBalancerService to program appropriate flowmods.
936 The rules are updated whenever there is a change in the Neutron LBaaS
937 settings. There is no cache of state kept in the net-virt or providers.
942 Owing to the inflexibility of the multipath action, the existing LBaaS
943 implementation comes with some limitations:
945 - TCP, HTTP or HTTPS are supported protocols for the pool. (Caution:
946 You can lose access to the members if you assign {Proto:TCP, Port:22}
949 - Member weights are ignored.
951 - The update of an LB instance is done as a delete + add, and not an
954 - The update of an LB member is not supported (because weights are
957 - Deletion of an LB member leads to the reprogramming of the LB on all
958 nodes (because of the way multipath does link hash).
960 - There is only a single LB instance per subnet because the pool-id is
961 not reported in the create load-balancer call.
963 OVSDB Library Developer Guide
964 -----------------------------
969 The OVSDB library manages the Netty connections to network nodes and
970 handles bidirectional JSON-RPC messages. It not only provides OVSDB
971 protocol functionality to OpenDaylight OVSDB plugin but also can be used
972 as standalone JAVA library for OVSDB protocol.
974 The main responsibilities of OVSDB library include:
976 - Manage connections to peers
978 - Marshal and unmarshal JSON Strings to JSON objects.
980 - Marshal and unmarshal JSON Strings from and to the Network Element.
985 The OVSDB library provides connection management through the
986 OvsdbConnection interface. The OvsdbConnection interface provides OVSDB
987 connection management APIs which include both active and passive
988 connections. From the library perspective, active OVSDB connections are
989 initiated from the controller to OVS nodes while passive OVSDB
990 connections are initiated from OVS nodes to the controller. In the
991 active connection scenario an application needs to provide the IP
992 address and listening port of OVS nodes to the library management API.
993 On the other hand, the library management API only requires the info of
994 the controller listening port in the passive connection scenario.
996 For a passive connection scenario, the library also provides a
997 connection event listener through the OvsdbConnectionListener interface.
998 The listener interface has connected() and disconnected() methods to
999 notify an application when a new passive connection is established or an
1000 existing connection is terminated.
1005 In addition to a regular TCP connection, the OvsdbConnection interface
1006 also provides a connection management API for an SSL connection. To
1007 start an OVSDB connection with SSL, an application will need to provide
1008 a Java SSLContext object to the management API. There are different ways
1009 to create a Java SSLContext, but in most cases a Java KeyStore with
1010 certificate and private key provided by the application is required.
1011 Detailed steps about how to create a Java SSLContext is out of the scope
1012 of this document and can be found in the Java documentation for `JAVA
1013 Class SSlContext <http://goo.gl/5svszT>`__.
1015 In the active connection scenario, the library uses the given SSLContext
1016 to create a Java SSLEngine and configures the SSL engine with the client
1017 mode for SSL handshaking. Normally clients are not required to
1018 authenticate themselves.
1020 In the passive connection scenario, the library uses the given
1021 SSLContext to create a Java SSLEngine which will operate in server mode
1022 for SSL handshaking. For security reasons, the SSLv3 protocol and some
1023 cipher suites are disabled. Currently the OVSDB server only supports the
1024 TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA cipher suite and the following
1025 protocols: SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2.
1027 The SSL engine is also configured to operate on two-way authentication
1028 mode for passive connection scenarios, i.e., the OVSDB server
1029 (controller) will authenticate clients (OVS nodes) and clients (OVS
1030 nodes) are also required to authenticate the server (controller). In the
1031 two-way authentication mode, an application should keep a trust manager
1032 to store the certificates of trusted clients and initialize a Java
1033 SSLContext with this trust manager. Thus during the SSL handshaking
1034 process the OVSDB server (controller) can use the trust manager to
1035 verify clients and only accept connection requests from trusted clients.
1036 On the other hand, users should also configure OVS nodes to authenticate
1037 the controller. Open vSwitch already supports this functionality in the
1038 ovsdb-server command with option ``--ca-cert=cacert.pem`` and
1039 ``--bootstrap-ca-cert=cacert.pem``. On the OVS node, a user can use the
1040 option ``--ca-cert=cacert.pem`` to specify a controller certificate
1041 directly and the node will only allow connections to the controller with
1042 the specified certificate. If the OVS node runs ovsdb-server with option
1043 ``--bootstrap-ca-cert=cacert.pem``, it will authenticate the controller
1044 with the specified certificate cacert.pem. If the certificate file
1045 doesn’t exist, it will attempt to obtain a certificate from the peer
1046 (controller) on its first SSL connection and save it to the named PEM
1047 file ``cacert.pem``. Here is an example of ovsdb-server with
1048 ``--bootstrap-ca-cert=cacert.pem`` option:
1050 ``ovsdb-server --pidfile --detach --log-file --remote punix:/var/run/openvswitch/db.sock --remote=db:hardware_vtep,Global,managers --private-key=/etc/openvswitch/ovsclient-privkey.pem -- certificate=/etc/openvswitch/ovsclient-cert.pem --bootstrap-ca-cert=/etc/openvswitch/vswitchd.cacert``
1052 OVSDB protocol transactions
1053 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
1055 The OVSDB protocol defines the RPC transaction methods in RFC 7047. The
1056 following RPC methods are supported in OVSDB protocol:
1068 - Update notification
1070 - Monitor cancellation
1074 - Locked notification
1076 - Stolen notification
1080 According to RFC 7047, an OVSDB server must implement all methods, and
1081 an OVSDB client is only required to implement the "Echo" method and
1082 otherwise free to implement whichever methods suit its needs. However,
1083 the OVSDB library currently doesn’t support all RPC methods. For the
1084 "Echo" method, the library can handle "Echo" messages from a peer and
1085 send a JSON response message back, but the library doesn’t support
1086 actively sending an "Echo" JSON request to a peer. Other unsupported RPC
1087 methods are listed below:
1093 - Locked notification
1095 - Stolen notification
1097 In the OVSDB library the RPC methods are defined in the Java interface
1098 OvsdbRPC. The library also provides a high-level interface OvsdbClient
1099 as the main interface to interact with peers through the OVSDB protocol.
1100 In the passive connection scenario, each connection will have a
1101 corresponding OvsdbClient object, and the application can obtain the
1102 OvsdbClient object through connection listener callback methods. In
1103 other words, if the application implements the OvsdbConnectionListener
1104 interface, it will get notifications of connection status changes with
1105 the corresponding OvsdbClient object of that connection.
1107 OVSDB database operations
1108 ~~~~~~~~~~~~~~~~~~~~~~~~~
1110 RFC 7047 also defines database operations, such as insert, delete, and
1111 update, to be performed as part of a "transact" RPC request. The OVSDB
1112 library defines the data operations in Operations.java and provides the
1113 TransactionBuilder class to help build "transact" RPC requests. To build
1114 a JSON-RPC transact request message, the application can obtain the
1115 TransactionBuilder object through a transactBuilder() method in the
1116 OvsdbClient interface.
1118 The TransactionBuilder class provides the following methods to help
1121 - getOperations(): Get the list of operations in this transaction.
1123 - add(): Add data operation to this transaction.
1125 - build(): Return the list of operations in this transaction. This is
1126 the same as the getOperations() method.
1128 - execute(): Send the JSON RPC transaction to peer.
1130 - getDatabaseSchema(): Get the database schema of this transaction.
1132 If the application wants to build and send a "transact" RPC request to
1133 modify OVSDB tables on a peer, it can take the following steps:
1135 1. Statically import parameter "op" in Operations.java
1137 ``import static org.opendaylight.ovsdb.lib.operations.Operations.op;``
1139 2. Obtain transaction builder through transacBuilder() method in
1142 ``TransactionBuilder transactionBuilder = ovsdbClient.transactionBuilder(dbSchema);``
1144 3. Add operations to transaction builder:
1146 ``transactionBuilder.add(op.insert(schema, row));``
1148 4. Send transaction to peer and get JSON RPC response:
1150 ``operationResults = transactionBuilder.execute().get();``
1154 Although the "select" operation is supported in the OVSDB
1155 library, the library implementation is a little different from
1156 RFC 7047. In RFC 7047, section 5.2.2 describes the "select"
1157 operation as follows:
1159 “The "rows" member of the result is an array of objects. Each object
1160 corresponds to a matching row, with each column specified in
1161 "columns" as a member, the column’s name as the member name, and its
1162 value as the member value. If "columns" is not specified, all the
1163 table’s columns are included (including the internally generated
1164 "\_uuid" and "\_version" columns).”
1166 The OVSDB library implementation always requires the column’s name in
1167 the "columns" field of a JSON message. If the "columns" field is not
1168 specified, none of the table’s columns are included. If the
1169 application wants to get the table entry with all columns, it needs
1170 to specify all the columns’ names in the "columns" field.
1172 Reference Documentation
1173 ~~~~~~~~~~~~~~~~~~~~~~~
1175 RFC 7047 The Open vSwitch Databse Management Protocol
1176 https://tools.ietf.org/html/rfc7047
1178 OVSDB MD-SAL Southbound Plugin Developer Guide
1179 ----------------------------------------------
1184 The Open vSwitch Database (OVSDB) Model Driven Service Abstraction Layer
1185 (MD-SAL) Southbound Plugin provides an MD-SAL based interface to Open
1186 vSwitch systems. This is done by augmenting the MD-SAL topology node
1187 with a YANG model which replicates some (but not all) of the Open
1190 OVSDB MD-SAL Southbound Plugin Architecture and Operation
1191 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1193 The architecture and operation of the OVSDB MD-SAL Southbound plugin is
1194 illustrated in the following set of diagrams.
1196 Connecting to an OVSDB Node
1197 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
1199 An OVSDB node is a system which is running the OVS software and is
1200 capable of being managed by an OVSDB manager. The OVSDB MD-SAL
1201 Southbound plugin in OpenDaylight is capable of operating as an OVSDB
1202 manager. Depending on the configuration of the OVSDB node, the
1203 connection of the OVSDB manager can be active or passive.
1205 Active OVSDB Node Manager Workflow
1206 ''''''''''''''''''''''''''''''''''
1208 An active OVSDB node manager connection is made when OpenDaylight
1209 initiates the connection to the OVSDB node. In order for this to work,
1210 you must configure the OVSDB node to listen on a TCP port for the
1211 connection (i.e. OpenDaylight is active and the OVSDB node is passive).
1212 This option can be configured on the OVSDB node using the following
1217 ovs-vsctl set-manager ptcp:6640
1219 The following diagram illustrates the sequence of events which occur
1220 when OpenDaylight initiates an active OVSDB manager connection to an
1223 .. figure:: ./images/ovsdb-sb-active-connection.jpg
1224 :alt: Active OVSDB Manager Connection
1226 Active OVSDB Manager Connection
1229 Create an OVSDB node by using RESTCONF or an OpenDaylight plugin.
1230 The OVSDB node is listed under the OVSDB topology node.
1233 Add the OVSDB node to the OVSDB MD-SAL southbound configuration
1234 datastore. The OVSDB southbound provider is registered to listen for
1235 data change events on the portion of the MD-SAL topology data store
1236 which contains the OVSDB southbound topology node augmentations. The
1237 addition of an OVSDB node causes an event which is received by the
1238 OVSDB Southbound provider.
1241 The OVSDB Southbound provider initiates a connection to the OVSDB
1242 node using the connection information provided in the configuration
1243 OVSDB node (i.e. IP address and TCP port number).
1246 The OVSDB Southbound provider adds the OVSDB node to the OVSDB
1247 MD-SAL operational data store. The operational data store contains
1248 OVSDB node objects which represent active connections to OVSDB
1252 The OVSDB Southbound provider requests the schema and databases
1253 which are supported by the OVSDB node.
1256 The OVSDB Southbound provider uses the database and schema
1257 information to construct a monitor request which causes the OVSDB
1258 node to send the controller any updates made to the OVSDB databases
1261 Passive OVSDB Node Manager Workflow
1262 '''''''''''''''''''''''''''''''''''
1264 A passive OVSDB node connection to OpenDaylight is made when the OVSDB
1265 node initiates the connection to OpenDaylight. In order for this to
1266 work, you must configure the OVSDB node to connect to the IP address and
1267 OVSDB port on which OpenDaylight is listening. This option can be
1268 configured on the OVSDB node using the following command:
1272 ovs-vsctl set-manager tcp:<IP address>:6640
1274 The following diagram illustrates the sequence of events which occur
1275 when an OVSDB node connects to OpenDaylight.
1277 .. figure:: ./images/ovsdb-sb-passive-connection.jpg
1278 :alt: Passive OVSDB Manager Connection
1280 Passive OVSDB Manager Connection
1283 The OVSDB node initiates a connection to OpenDaylight.
1286 The OVSDB Southbound provider adds the OVSDB node to the OVSDB
1287 MD-SAL operational data store. The operational data store contains
1288 OVSDB node objects which represent active connections to OVSDB
1292 The OVSDB Southbound provider requests the schema and databases
1293 which are supported by the OVSDB node.
1296 The OVSDB Southbound provider uses the database and schema
1297 information to construct a monitor request which causes the OVSDB
1298 node to send back any updates which have been made to the OVSDB
1299 databases on the OVSDB node.
1301 OVSDB Node ID in the Southbound Operational MD-SAL
1302 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1304 When OpenDaylight initiates an active connection to an OVSDB node, it
1305 writes an external-id to the Open\_vSwitch table on the OVSDB node. The
1306 external-id is an OpenDaylight instance identifier which identifies the
1307 OVSDB topology node which has just been created. Here is an example
1308 showing the value of the *opendaylight-iid* entry in the external-ids
1309 column of the Open\_vSwitch table where the node-id of the OVSDB node is
1314 $ ovs-vsctl list open_vswitch
1316 external_ids : {opendaylight-iid="/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb:HOST1']"}
1319 The *opendaylight-iid* entry in the external-ids column of the
1320 Open\_vSwitch table causes the OVSDB node to have same node-id in the
1321 operational MD-SAL datastore as in the configuration MD-SAL datastore.
1322 This holds true if the OVSDB node manager settings are subsequently
1323 changed so that a passive OVSDB manager connection is made.
1325 If there is no *opendaylight-iid* entry in the external-ids column and a
1326 passive OVSDB manager connection is made, then the node-id of the OVSDB
1327 node in the operational MD-SAL datastore will be constructed using the
1328 UUID of the Open\_vSwitch table as follows.
1332 "node-id": "ovsdb://uuid/b8dc0bfb-d22b-4938-a2e8-b0084d7bd8c1"
1334 The *opendaylight-iid* entry can be removed from the Open\_vSwitch table
1335 using the following command.
1339 $ sudo ovs-vsctl remove open_vswitch . external-id "opendaylight-iid"
1341 OVSDB Changes by using OVSDB Southbound Config MD-SAL
1342 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1344 After the connection has been made to an OVSDB node, you can make
1345 changes to the OVSDB node by using the OVSDB Southbound Config MD-SAL.
1346 You can make CRUD operations by using the RESTCONF interface or by a
1347 plugin using the MD-SAL APIs. The following diagram illustrates the
1348 high-level flow of events.
1350 .. figure:: ./images/ovsdb-sb-config-crud.jpg
1351 :alt: OVSDB Changes by using the Southbound Config MD-SAL
1353 OVSDB Changes by using the Southbound Config MD-SAL
1356 A change to the OVSDB Southbound Config MD-SAL is made. Changes
1357 include adding or deleting bridges and ports, or setting attributes
1358 of OVSDB nodes, bridges or ports.
1361 The OVSDB Southbound provider receives notification of the changes
1362 made to the OVSDB Southbound Config MD-SAL data store.
1365 As appropriate, OVSDB transactions are constructed and transmitted
1366 to the OVSDB node to update the OVSDB database on the OVSDB node.
1369 The OVSDB node sends update messages to the OVSDB Southbound
1370 provider to indicate the changes made to the OVSDB nodes database.
1373 The OVSDB Southbound provider maps the changes received from the
1374 OVSDB node into corresponding changes made to the OVSDB Southbound
1375 Operational MD-SAL data store.
1377 Detecting changes in OVSDB coming from outside OpenDaylight
1378 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1380 Changes to the OVSDB nodes database may also occur independently of
1381 OpenDaylight. OpenDaylight also receives notifications for these events
1382 and updates the Southbound operational MD-SAL. The following diagram
1383 illustrates the sequence of events.
1385 .. figure:: ./images/ovsdb-sb-oper-crud.jpg
1386 :alt: OVSDB Changes made directly on the OVSDB node
1388 OVSDB Changes made directly on the OVSDB node
1391 Changes are made to the OVSDB node outside of OpenDaylight (e.g.
1395 The OVSDB node constructs update messages to inform OpenDaylight of
1396 the changes made to its databases.
1399 The OVSDB Southbound provider maps the OVSDB database changes to
1400 corresponding changes in the OVSDB Southbound operational MD-SAL
1406 The OVSDB Southbound MD-SAL operates using a YANG model which is based
1407 on the abstract topology node model found in the `network topology
1408 model <https://github.com/opendaylight/yangtools/blob/stable/boron/model/ietf/ietf-topology/src/main/yang/network-topology%402013-10-21.yang>`__.
1410 The augmentations for the OVSDB Southbound MD-SAL are defined in the
1411 `ovsdb.yang <https://github.com/opendaylight/ovsdb/blob/stable/boron/southbound/southbound-api/src/main/yang/ovsdb.yang>`__
1414 There are three augmentations:
1416 **ovsdb-node-augmentation**
1417 This augments the topology node and maps primarily to the
1418 Open\_vSwitch table of the OVSDB schema. It contains the following
1421 - **connection-info** - holds the local and remote IP address and
1422 TCP port numbers for the OpenDaylight to OVSDB node connections
1424 - **db-version** - version of the OVSDB database
1426 - **ovs-version** - version of OVS
1428 - **list managed-node-entry** - a list of references to
1429 ovsdb-bridge-augmentation nodes, which are the OVS bridges
1430 managed by this OVSDB node
1432 - **list datapath-type-entry** - a list of the datapath types
1433 supported by the OVSDB node (e.g. *system*, *netdev*) - depends
1434 on newer OVS versions
1436 - **list interface-type-entry** - a list of the interface types
1437 supported by the OVSDB node (e.g. *internal*, *vxlan*, *gre*,
1438 *dpdk*, etc.) - depends on newer OVS verions
1440 - **list openvswitch-external-ids** - a list of the key/value pairs
1441 in the Open\_vSwitch table external\_ids column
1443 - **list openvswitch-other-config** - a list of the key/value pairs
1444 in the Open\_vSwitch table other\_config column
1446 **ovsdb-bridge-augmentation**
1447 This augments the topology node and maps to an specific bridge in
1448 the OVSDB bridge table of the associated OVSDB node. It contains the
1449 following attributes.
1451 - **bridge-uuid** - UUID of the OVSDB bridge
1453 - **bridge-name** - name of the OVSDB bridge
1455 - **bridge-openflow-node-ref** - a reference (instance-identifier)
1456 of the OpenFlow node associated with this bridge
1458 - **list protocol-entry** - the version of OpenFlow protocol to use
1459 with the OpenFlow controller
1461 - **list controller-entry** - a list of controller-uuid and
1462 is-connected status of the OpenFlow controllers associated with
1465 - **datapath-id** - the datapath ID associated with this bridge on
1468 - **datapath-type** - the datapath type of this bridge
1470 - **fail-mode** - the OVSDB fail mode setting of this bridge
1472 - **flow-node** - a reference to the flow node corresponding to
1475 - **managed-by** - a reference to the ovsdb-node-augmentation
1476 (OVSDB node) that is managing this bridge
1478 - **list bridge-external-ids** - a list of the key/value pairs in
1479 the bridge table external\_ids column for this bridge
1481 - **list bridge-other-configs** - a list of the key/value pairs in
1482 the bridge table other\_config column for this bridge
1484 **ovsdb-termination-point-augmentation**
1485 This augments the topology termination point model. The OVSDB
1486 Southbound MD-SAL uses this model to represent both the OVSDB port
1487 and OVSDB interface for a given port/interface in the OVSDB schema.
1488 It contains the following attributes.
1490 - **port-uuid** - UUID of an OVSDB port row
1492 - **interface-uuid** - UUID of an OVSDB interface row
1494 - **name** - name of the port
1496 - **interface-type** - the interface type
1498 - **list options** - a list of port options
1500 - **ofport** - the OpenFlow port number of the interface
1502 - **ofport\_request** - the requested OpenFlow port number for the
1505 - **vlan-tag** - the VLAN tag value
1507 - **list trunks** - list of VLAN tag values for trunk mode
1509 - **vlan-mode** - the VLAN mode (e.g. access, native-tagged,
1510 native-untagged, trunk)
1512 - **list port-external-ids** - a list of the key/value pairs in the
1513 port table external\_ids column for this port
1515 - **list interface-external-ids** - a list of the key/value pairs
1516 in the interface table external\_ids interface for this interface
1518 - **list port-other-configs** - a list of the key/value pairs in
1519 the port table other\_config column for this port
1521 - **list interface-other-configs** - a list of the key/value pairs
1522 in the interface table other\_config column for this interface
1524 Examples of OVSDB Southbound MD-SAL API
1525 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1527 Connect to an OVSDB Node
1528 ^^^^^^^^^^^^^^^^^^^^^^^^
1530 This example RESTCONF command adds an OVSDB node object to the OVSDB
1531 Southbound configuration data store and attempts to connect to the OVSDB
1532 host located at the IP address 10.11.12.1 on TCP port 6640.
1536 POST http://<host>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/
1537 Content-Type: application/json
1541 "node-id": "ovsdb:HOST1",
1542 "connection-info": {
1543 "ovsdb:remote-ip": "10.11.12.1",
1544 "ovsdb:remote-port": 6640
1550 Query the OVSDB Southbound Configuration MD-SAL
1551 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1553 Following on from the previous example, if the OVSDB Southbound
1554 configuration MD-SAL is queried, the RESTCONF command and the resulting
1555 reply is similar to the following example.
1559 GET http://<host>:8080/restconf/config/network-topology:network-topology/topology/ovsdb:1/
1560 Application/json data in the reply
1564 "topology-id": "ovsdb:1",
1567 "node-id": "ovsdb:HOST1",
1568 "ovsdb:connection-info": {
1569 "remote-port": 6640,
1570 "remote-ip": "10.11.12.1"
1578 Reference Documentation
1579 ~~~~~~~~~~~~~~~~~~~~~~~
1582 schema <http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf>`__
1584 OVSDB Openstack Developer Guide
1585 -------------------------------
1590 The Open vSwitch database (OVSDB) Southbound Plugin component for
1591 OpenDaylight implements the OVSDB `RFC
1592 7047 <https://tools.ietf.org/html/rfc7047>`__ management protocol that
1593 allows the southbound configuration of switches that support OVSDB. The
1594 component comprises a library and a plugin. The OVSDB protocol uses
1595 JSON-RPC calls to manipulate a physical or virtual switch that supports
1596 OVSDB. Many vendors support OVSDB on various hardware platforms. The
1597 OpenDaylight controller uses the library project to interact with an OVS
1600 `OpenStack <http://www.openstack.org>`__ is a popular open source
1601 Infrastructure as a Service (IaaS) project, covering compute, storage
1602 and network management. OpenStack can use OpenDaylight as its network
1603 management provider through the Neutron API, which acts as a northbound
1604 for OpenStack. the OVSDB NetVirt piece of the OVSDB project is a
1605 provider for the Neutron API in OpenDaylight. OpenDaylight manages the
1606 network flows for the OpenStack compute nodes via the OVSDB project,
1607 with the south-bound plugin. This section describes how to set that up,
1608 and how to tell when everything is working.
1610 OVSDB Openstack Architecture
1611 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1613 The OpenStack integration architecture uses the following technologies:
1615 - `RFC 7047 <https://tools.ietf.org/html/rfc7047>`__ - The Open vSwitch
1616 Database Management Protocol
1619 v1.3 <http://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.3.4.pdf>`__
1621 - `OpenStack Neutron ML2
1622 Plugin <https://wiki.openstack.org/wiki/Neutron/ML2>`__
1624 .. figure:: images/openstack_integration.png
1626 OpenStack Integration
1628 OVSDB Service Function Chaining Developer Guide
1629 -----------------------------------------------
1634 The OVSDB NetVirtSfc provides a classification and traffic steering
1635 component when integrated with OpenStack. Please refer to the Service
1636 Function Chaining project for the theory and programming of service
1639 Installing the NetVirt SFC Feature
1640 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1642 Install the odl-ovsdb-sfc feature. The feature will also ensure that the
1643 odl-ovsdb-openstack feature as well as the openflowplugin, neutron and
1644 sfc features are installed.
1646 ``feature:install odl-ovsdb-sfc-ui``
1648 Verify the required features are installed:
1652 opendaylight-user@root>feature:list -i | grep ovsdb
1653 odl-ovsdb-southbound-api | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight southbound :: api
1654 odl-ovsdb-southbound-impl | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound impl
1655 odl-ovsdb-southbound-impl-rest | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound :: impl REST
1656 odl-ovsdb-southbound-impl-ui | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound :: impl UI
1657 odl-ovsdb-library | 1.2.1-SNAPSHOT | x | odl-ovsdb-library-1.2.1-SNAPSHOT | OpenDaylight library
1658 odl-ovsdb-openstack | 1.2.1-SNAPSHOT | x | ovsdb-1.2.1-SNAPSHOT | OpenDaylight :: OVSDB OpenStack Network Virtual
1659 odl-ovsdb-sfc-api | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc api
1660 odl-ovsdb-sfc | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight ovsdb-sfc
1661 odl-ovsdb-sfc-rest | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc REST
1662 odl-ovsdb-sfc-ui | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc UI
1664 opendaylight-user@root>feature:list -i | grep sfc
1665 odl-sfc-model | 0.2.0-SNAPSHOT | x | odl-sfc-0.2.0-SNAPSHOT | OpenDaylight :: sfc :: Model
1666 odl-sfc-provider | 0.2.0-SNAPSHOT | x | odl-sfc-0.2.0-SNAPSHOT | OpenDaylight :: sfc :: Provider
1667 odl-sfc-provider-rest | 0.2.0-SNAPSHOT | x | odl-sfc-0.2.0-SNAPSHOT | OpenDaylight :: sfc :: Provider
1668 odl-sfc-ovs | 0.2.0-SNAPSHOT | x | odl-sfc-0.2.0-SNAPSHOT | OpenDaylight :: OpenvSwitch
1669 odl-sfcofl2 | 0.2.0-SNAPSHOT | x | odl-sfc-0.2.0-SNAPSHOT | OpenDaylight :: sfcofl2
1670 odl-ovsdb-sfc-test | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-test1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc-test
1671 odl-ovsdb-sfc-api | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc :: api
1672 odl-ovsdb-sfc | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc
1673 odl-ovsdb-sfc-rest | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc :: REST
1674 odl-ovsdb-sfc-ui | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc :: UI
1676 opendaylight-user@root>feature:list -i | grep neutron
1677 odl-neutron-service | 0.6.0-SNAPSHOT | x | odl-neutron-0.6.0-SNAPSHOT | OpenDaylight :: Neutron :: API
1678 odl-neutron-northbound-api | 0.6.0-SNAPSHOT | x | odl-neutron-0.6.0-SNAPSHOT | OpenDaylight :: Neutron :: Northbound
1679 odl-neutron-spi | 0.6.0-SNAPSHOT | x | odl-neutron-0.6.0-SNAPSHOT | OpenDaylight :: Neutron :: API
1680 odl-neutron-transcriber | 0.6.0-SNAPSHOT | x | odl-neutron-0.6.0-SNAPSHOT | OpenDaylight :: Neutron :: Implementation
1682 OVSDB NetVirt Service Function Chaining Example
1683 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1685 The architecture within OpenDaylight can be seen in the following
1688 .. figure:: ./images/ovsdb/ODL_SFC_Architecture.png
1689 :alt: OpenDaylight OVSDB NetVirt SFC Architecture
1691 OpenDaylight OVSDB NetVirt SFC Architecture
1693 Tacker is a Virtual Network Functions Manager that is responsible for
1694 orchestrating the Service Function Chaining. Tacker is responsible for
1695 generating templates for Virtual Network Functions for OpenStack to
1696 instantiate the Service Functions. Tacker also uses the RESTCONF
1697 interfaces of OpenDaylight to create the Service Function Chains.
1702 OVSDB NetVirt SFC implements the classification for the chains. The
1703 classification steers traffic from the tenant overlay to the chain
1704 overlay and back to the tenant overlay.
1706 An Access Control List used by NetVirtSFC to create the classifier is
1707 shown below. This is an example of classifying HTTP traffic using the
1708 tcp port 80. In this example the user would have created a Service
1709 Function Chain with the name "http-sfc" as well as all the associated
1710 Service Functions and Service Function Forwarders for the chain.
1712 http://localhost:8181/restconf/config/ietf-access-control-list:access-lists
1720 "acl-name": "http-acl",
1721 "access-list-entries": {
1724 "rule-name": "http-rule",
1726 "source-port-range": {
1731 "destination-port-range": {
1737 "netvirt-sfc-acl:sfc-name": "http-sfc"
1747 When the chain is rendered using the Rendered Service Path RPC,
1748 NetvirtSfc will add the classification flows. The classification flows
1749 are shown below. The list shown has been modified to remove the NetVirt
1750 tenant overlay flows. The classification flow is identified with the
1751 cookie: 0x1110010000040255. The 6th digit of the cookie identifies the
1752 flow type as the classifier. The last 8 digits identify the chain with
1753 the first four digits indicating the NSH NSP and the last four digits
1754 identifying the NSH NSI. In this case the chain is identified with an
1755 NSP of 4 and the NSI is 255 to indicate the beginning of the chain.
1759 sudo ovs-ofctl --protocol=OpenFlow13 dump-flows br-int
1760 OFPST_FLOW reply (OF1.3) (xid=0x2):
1761 cookie=0x0, duration=17.157s, table=0, n_packets=0, n_bytes=0, priority=6 actions=goto_table:1
1762 cookie=0x14, duration=10.692s, table=0, n_packets=0, n_bytes=0, priority=400,udp,in_port=4,tp_dst=6633 actions=LOCAL
1763 cookie=0x0, duration=17.134s, table=0, n_packets=0, n_bytes=0, dl_type=0x88cc actions=CONTROLLER:65535
1764 cookie=0x14, duration=10.717s, table=0, n_packets=0, n_bytes=0, priority=350,nsp=4 actions=goto_table:152
1765 cookie=0x14, duration=10.688s, table=0, n_packets=0, n_bytes=0, priority=400,udp,nw_dst=10.2.1.1,tp_dst=6633 actions=output:4
1766 cookie=0x0, duration=17.157s, table=1, n_packets=0, n_bytes=0, priority=0 actions=goto_table:11
1767 cookie=0x1110070000040254, duration=10.608s, table=1, n_packets=0, n_bytes=0, priority=40000,reg0=0x1,nsp=4,nsi=254,in_port=1 actions=goto_table:21
1768 cookie=0x0, duration=17.157s, table=11, n_packets=0, n_bytes=0, priority=0 actions=goto_table:21
1769 cookie=0x1110060000040254, duration=10.625s, table=11, n_packets=0, n_bytes=0, nsp=4,nsi=254,in_port=4 actions=load:0x1->NXM_NX_REG0[],move:NXM_NX_NSH_C2[]->NXM_NX_TUN_ID[0..31],resubmit(1,1)
1770 cookie=0x1110010000040255, duration=10.615s, table=11, n_packets=0, n_bytes=0, tcp,reg0=0x1,tp_dst=80 actions=move:NXM_NX_TUN_ID[0..31]->NXM_NX_NSH_C2[],set_nshc1:0xc0a83246,set_nsp:0x4,set_nsi:255,load:0xa020101->NXM_NX_TUN_IPV4_DST[],load:0x4->NXM_NX_TUN_ID[0..31],resubmit(,0)
1771 cookie=0x0, duration=17.157s, table=21, n_packets=0, n_bytes=0, priority=0 actions=goto_table:31
1772 cookie=0x1110040000000000, duration=10.765s, table=21, n_packets=0, n_bytes=0, priority=1024,arp,in_port=LOCAL,arp_tpa=10.2.1.1,arp_op=1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:f6:00:00:0f:00:01->eth_src,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xf600000f0001->NXM_NX_ARP_SHA[],load:0xa020101->NXM_OF_ARP_SPA[],IN_PORT
1773 cookie=0x0, duration=17.157s, table=31, n_packets=0, n_bytes=0, priority=0 actions=goto_table:41
1774 cookie=0x0, duration=17.157s, table=41, n_packets=0, n_bytes=0, priority=0 actions=goto_table:51
1775 cookie=0x0, duration=17.157s, table=51, n_packets=0, n_bytes=0, priority=0 actions=goto_table:61
1776 cookie=0x0, duration=17.142s, table=61, n_packets=0, n_bytes=0, priority=0 actions=goto_table:71
1777 cookie=0x0, duration=17.140s, table=71, n_packets=0, n_bytes=0, priority=0 actions=goto_table:81
1778 cookie=0x0, duration=17.116s, table=81, n_packets=0, n_bytes=0, priority=0 actions=goto_table:91
1779 cookie=0x0, duration=17.116s, table=91, n_packets=0, n_bytes=0, priority=0 actions=goto_table:101
1780 cookie=0x0, duration=17.107s, table=101, n_packets=0, n_bytes=0, priority=0 actions=goto_table:111
1781 cookie=0x0, duration=17.083s, table=111, n_packets=0, n_bytes=0, priority=0 actions=drop
1782 cookie=0x14, duration=11.042s, table=150, n_packets=0, n_bytes=0, priority=5 actions=goto_table:151
1783 cookie=0x14, duration=11.027s, table=151, n_packets=0, n_bytes=0, priority=5 actions=goto_table:152
1784 cookie=0x14, duration=11.010s, table=152, n_packets=0, n_bytes=0, priority=5 actions=goto_table:158
1785 cookie=0x14, duration=10.668s, table=152, n_packets=0, n_bytes=0, priority=650,nsp=4,nsi=255 actions=load:0xa020101->NXM_NX_TUN_IPV4_DST[],goto_table:158
1786 cookie=0x14, duration=10.995s, table=158, n_packets=0, n_bytes=0, priority=5 actions=drop
1787 cookie=0xba5eba11ba5eba11, duration=10.645s, table=158, n_packets=0, n_bytes=0, priority=751,nsp=4,nsi=255,in_port=4 actions=move:NXM_NX_NSH_C1[]->NXM_NX_NSH_C1[],move:NXM_NX_NSH_C2[]->NXM_NX_NSH_C2[],move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31],IN_PORT
1788 cookie=0xba5eba11ba5eba11, duration=10.590s, table=158, n_packets=0, n_bytes=0, priority=751,nsp=4,nsi=254,in_port=4 actions=move:NXM_NX_NSI[]->NXM_NX_NSI[],move:NXM_NX_NSP[]->NXM_NX_NSP[],move:NXM_NX_NSH_C1[]->NXM_NX_TUN_IPV4_DST[],move:NXM_NX_NSH_C2[]->NXM_NX_TUN_ID[0..31],IN_PORT
1789 cookie=0xba5eba11ba5eba11, duration=10.640s, table=158, n_packets=0, n_bytes=0, priority=750,nsp=4,nsi=255 actions=move:NXM_NX_NSH_C1[]->NXM_NX_NSH_C1[],move:NXM_NX_NSH_C2[]->NXM_NX_NSH_C2[],move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31],output:4
1790 cookie=0xba5eba11ba5eba11, duration=10.571s, table=158, n_packets=0, n_bytes=0, priority=761,nsp=4,nsi=254,nshc1=3232248390,in_port=4 actions=move:NXM_NX_NSI[]->NXM_NX_NSI[],move:NXM_NX_NSP[]->NXM_NX_NSP[],move:NXM_NX_NSH_C1[]->NXM_NX_TUN_IPV4_DST[],move:NXM_NX_NSH_C2[]->NXM_NX_TUN_ID[0..31],set_nshc1:0,resubmit(,11)
1796 Some configuration is required due to application coexistence for the
1797 OpenFlow programming. The SFC project programs flows for the SFC overlay
1798 and NetVirt programs flows for the tenant overlay. Coexistence is
1799 achieved by each application owning a unique set of tables and providing
1800 a simple handoff between the tables.
1802 First configure NetVirt to use table 1 as it’s starting table:
1804 http://localhost:8181/restconf/config/netvirt-providers-config:netvirt-providers-config
1806 ``{ "netvirt-providers-config": { "table-offset": 1 } }``
1808 Next configure SFC to start at table 150 and configure the table
1809 handoff. The configuration starts SFC at table 150 and sets the handoff
1810 to table 11 which is the NetVirt SFC classification table.
1812 http://localhost:8181/restconf/config/sfc-of-renderer:sfc-of-renderer-config
1814 ``{ "sfc-of-renderer-config": { "sfc-of-app-egress-table-offset": 11, "sfc-of-table-offset": 150 } }``
1816 OVSDB Hardware VTEP Developer Guide
1817 -----------------------------------
1824 OVSDB Hardware VTEP Architecture
1825 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~