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 1. 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 1. Run the following:
247 vagrant up devstack-compute-1
248 vagrant ssh devstack-compute-1
252 1. 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 1. 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**:https://gist.github.com/anonymous/1543a410d57f491352c8[Gist]
660 Security group rules supported in ODL
661 '''''''''''''''''''''''''''''''''''''
663 The following rules formata 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 1. 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 1. 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 1. 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 1. Start odl, as mentioned in `running Karaf feature
738 section <#ovsdbStartingOdl>`__.
740 2. To see processing of neutron event related to L3, do this from
745 log:set debug org.opendaylight.ovsdb.openstack.netvirt.impl.NeutronL3Adapter
747 1. 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 1. 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
782 rm -f id_rsa_demo* ; ssh-keygen -t rsa -b 2048 -N -f id_rsa_demo
783 nova keypair-add --pub-key id_rsa_demo.pub demo_key
786 1. Create two networks and two subnets.
790 neutron net-create net1 --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
791 --provider:network_type gre --provider:segmentation_id 555
795 neutron subnet-create --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
796 net1 10.0.0.0/16 --name subnet1 --dns-nameserver 8.8.8.8
800 neutron net-create net2 --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
801 --provider:network_type gre --provider:segmentation_id 556
805 neutron subnet-create --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
806 net2 20.0.0.0/16 --name subnet2 --dns-nameserver 8.8.8.8
808 1. Create a router, and add an interface to each of the two subnets.
812 neutron router-create demorouter --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}')
813 neutron router-interface-add demorouter subnet1
814 neutron router-interface-add demorouter subnet2
815 # neutron router-port-list demorouter
817 1. Create two tenant instances.
821 nova boot --poll --flavor m1.nano --image $(nova image-list | grep 'cirros-0.3.2-x86_64-uec\s' | awk '{print $2}') \
822 --nic net-id=$(neutron net-list | grep -w net1 | awk '{print $2}'),v4-fixed-ip=10.0.0.10 \
823 --availability-zone nova:devstack-control \
824 --key-name demo_key host10
828 nova boot --poll --flavor m1.nano --image $(nova image-list | grep 'cirros-0.3.2-x86_64-uec\s' | awk '{print $2}') \
829 --nic net-id=$(neutron net-list | grep -w net2 | awk '{print $2}'),v4-fixed-ip=20.0.0.20 \
830 --availability-zone nova:devstack-compute-1 \
831 --key-name demo_key host20
836 - To use this feature, you need OVS 2.1 or newer version.
838 - Owing to OF limitations, icmp responses due to routing failures, like
839 ttl expired or host unreacheable, are not generated.
841 - The MAC address of the default route is not automatically mapped. In
842 order to route to L3 destinations outside the networks of the tenant,
843 the manual configuration of the default route is necessary. To
844 provide the MAC address of the default route, use ovsdb.l3gateway.mac
845 in file configuration/config.ini ;
847 - This feature is Tech preview, which depends on later versions of
848 OpenStack to be used without the provided neutron-driver.
850 - No IPv6 support is provided.
852 | **More information on L3 forwarding**:
854 - odl-neutron-driver:
855 https://github.com/dave-tucker/odl-neutron-drivers
858 http://dtucker.co.uk/hack/building-a-router-with-openvswitch.html
863 Load-Balancing-as-a-Service (LBaaS) creates an Open vSwitch powered
864 L3-L4 stateless load-balancer in a virtualized network environment so
865 that individual TCP connections destined to a designated virtual IP
866 (VIP) are sent to the appropriate servers (that is to say, serving app
867 VMs). The load-balancer works in a session-preserving, proactive manner
868 without involving the controller during flow setup.
870 A Neutron northbound interface is provided to create a VIP which will
871 map to a pool of servers (that is to say, members) within a subnet. The
872 pools consist of members identified by an IP address. The goal is to
873 closely match the API to the OpenStack LBaaS v2 API:
874 http://docs.openstack.org/api/openstack-network/2.0/content/lbaas_ext.html.
876 Creating an OpenStack workflow
877 ''''''''''''''''''''''''''''''
881 2. Create a floating VIP *A* that maps to a private VIP *B*.
883 3. Create a Loadbalancer pool *X*.
887 neutron lb-pool-create --name http-pool --lb-method ROUND_ROBIN --protocol HTTP --subnet-id XYZ
889 1. Create a Loadbalancer pool member *Y* and associate with pool *X*.
893 neutron lb-member-create --address 10.0.0.10 --protocol-port 80 http-pool
894 neutron lb-member-create --address 10.0.0.11 --protocol-port 80 http-pool
895 neutron lb-member-create --address 10.0.0.12 --protocol-port 80 http-pool
896 neutron lb-member-create --address 10.0.0.13 --protocol-port 80 http-pool
898 1. Create a Loadbalancer instance *Z*, and associate pool *X* and VIP
903 neutron lb-vip-create --name http-vip --protocol-port 80 --protocol HTTP --subnet-id XYZ http-pool
908 The current implementation of the proactive stateless load-balancer was
909 made using "multipath" action in the Open vSwitch. The "multipath"
910 action takes a max\_link parameter value (which is same as the number of
911 pool members) as input, and performs a hash of the fields to get a value
912 between (0, max\_link). The value of the hash is used as an index to
913 select a pool member to handle that session.
918 Assuming that table=20 contains all the rules to forward the traffic
919 destined for a specific destination MAC address, the following are the
920 rules needed to be programmed in the LBaaS service table=10. The
921 programmed rules makes the translation from the VIP to a different pool
922 member for every session.
924 - Proactive forward rules:
928 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)"
929 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
930 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
931 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
932 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
934 - Proactive reverse rules:
938 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
943 The current implementation handles all neutron calls in the
944 net-virt/LBaaSHandler.java code, and makes calls to the
945 net-virt-providers/LoadBalancerService to program appropriate flowmods.
946 The rules are updated whenever there is a change in the Neutron LBaaS
947 settings. There is no cache of state kept in the net-virt or providers.
952 Owing to the inflexibility of the multipath action, the existing LBaaS
953 implementation comes with some limitations:
955 - TCP, HTTP or HTTPS are supported protocols for the pool. (Caution:
956 You can lose access to the members if you assign {Proto:TCP, Port:22}
959 - Member weights are ignored.
961 - The update of an LB instance is done as a delete + add, and not an
964 - The update of an LB member is not supported (because weights are
967 - Deletion of an LB member leads to the reprogramming of the LB on all
968 nodes (because of the way multipath does link hash).
970 - There is only a single LB instance per subnet because the pool-id is
971 not reported in the create load-balancer call.
973 OVSDB Library Developer Guide
974 -----------------------------
979 The OVSDB library manages the Netty connections to network nodes and
980 handles bidirectional JSON-RPC messages. It not only provides OVSDB
981 protocol functionality to OpenDaylight OVSDB plugin but also can be used
982 as standalone JAVA library for OVSDB protocol.
984 The main responsibilities of OVSDB library include:
986 - Manage connections to peers
988 - Marshal and unmarshal JSON Strings to JSON objects.
990 - Marshal and unmarshal JSON Strings from and to the Network Element.
995 The OVSDB library provides connection management through the
996 OvsdbConnection interface. The OvsdbConnection interface provides OVSDB
997 connection management APIs which include both active and passive
998 connections. From the library perspective, active OVSDB connections are
999 initiated from the controller to OVS nodes while passive OVSDB
1000 connections are initiated from OVS nodes to the controller. In the
1001 active connection scenario an application needs to provide the IP
1002 address and listening port of OVS nodes to the library management API.
1003 On the other hand, the library management API only requires the info of
1004 the controller listening port in the passive connection scenario.
1006 For a passive connection scenario, the library also provides a
1007 connection event listener through the OvsdbConnectionListener interface.
1008 The listener interface has connected() and disconnected() methods to
1009 notify an application when a new passive connection is established or an
1010 existing connection is terminated.
1015 In addition to a regular TCP connection, the OvsdbConnection interface
1016 also provides a connection management API for an SSL connection. To
1017 start an OVSDB connection with SSL, an application will need to provide
1018 a Java SSLContext object to the management API. There are different ways
1019 to create a Java SSLContext, but in most cases a Java KeyStore with
1020 certificate and private key provided by the application is required.
1021 Detailed steps about how to create a Java SSLContext is out of the scope
1022 of this document and can be found in the Java documentation for `JAVA
1023 Class SSlContext <http://goo.gl/5svszT>`__.
1025 In the active connection scenario, the library uses the given SSLContext
1026 to create a Java SSLEngine and configures the SSL engine with the client
1027 mode for SSL handshaking. Normally clients are not required to
1028 authenticate themselves.
1030 In the passive connection scenario, the library uses the given
1031 SSLContext to create a Java SSLEngine which will operate in server mode
1032 for SSL handshaking. For security reasons, the SSLv3 protocol and some
1033 cipher suites are disabled. Currently the OVSDB server only supports the
1034 TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA cipher suite and the following
1035 protocols: SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2.
1037 The SSL engine is also configured to operate on two-way authentication
1038 mode for passive connection scenarios, i.e., the OVSDB server
1039 (controller) will authenticate clients (OVS nodes) and clients (OVS
1040 nodes) are also required to authenticate the server (controller). In the
1041 two-way authentication mode, an application should keep a trust manager
1042 to store the certificates of trusted clients and initialize a Java
1043 SSLContext with this trust manager. Thus during the SSL handshaking
1044 process the OVSDB server (controller) can use the trust manager to
1045 verify clients and only accept connection requests from trusted clients.
1046 On the other hand, users should also configure OVS nodes to authenticate
1047 the controller. Open vSwitch already supports this functionality in the
1048 ovsdb-server command with option ``--ca-cert=cacert.pem`` and
1049 ``--bootstrap-ca-cert=cacert.pem``. On the OVS node, a user can use the
1050 option ``--ca-cert=cacert.pem`` to specify a controller certificate
1051 directly and the node will only allow connections to the controller with
1052 the specified certificate. If the OVS node runs ovsdb-server with option
1053 ``--bootstrap-ca-cert=cacert.pem``, it will authenticate the controller
1054 with the specified certificate cacert.pem. If the certificate file
1055 doesn’t exist, it will attempt to obtain a certificate from the peer
1056 (controller) on its first SSL connection and save it to the named PEM
1057 file ``cacert.pem``. Here is an example of ovsdb-server with
1058 ``--bootstrap-ca-cert=cacert.pem`` option:
1060 ``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``
1062 OVSDB protocol transactions
1063 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
1065 The OVSDB protocol defines the RPC transaction methods in RFC 7047. The
1066 following RPC methods are supported in OVSDB protocol:
1078 - Update notification
1080 - Monitor cancellation
1084 - Locked notification
1086 - Stolen notification
1090 According to RFC 7047, an OVSDB server must implement all methods, and
1091 an OVSDB client is only required to implement the "Echo" method and
1092 otherwise free to implement whichever methods suit its needs. However,
1093 the OVSDB library currently doesn’t support all RPC methods. For the
1094 "Echo" method, the library can handle "Echo" messages from a peer and
1095 send a JSON response message back, but the library doesn’t support
1096 actively sending an "Echo" JSON request to a peer. Other unsupported RPC
1097 methods are listed below:
1103 - Locked notification
1105 - Stolen notification
1107 In the OVSDB library the RPC methods are defined in the Java interface
1108 OvsdbRPC. The library also provides a high-level interface OvsdbClient
1109 as the main interface to interact with peers through the OVSDB protocol.
1110 In the passive connection scenario, each connection will have a
1111 corresponding OvsdbClient object, and the application can obtain the
1112 OvsdbClient object through connection listener callback methods. In
1113 other words, if the application implements the OvsdbConnectionListener
1114 interface, it will get notifications of connection status changes with
1115 the corresponding OvsdbClient object of that connection.
1117 OVSDB database operations
1118 ~~~~~~~~~~~~~~~~~~~~~~~~~
1120 RFC 7047 also defines database operations, such as insert, delete, and
1121 update, to be performed as part of a "transact" RPC request. The OVSDB
1122 library defines the data operations in Operations.java and provides the
1123 TransactionBuilder class to help build "transact" RPC requests. To build
1124 a JSON-RPC transact request message, the application can obtain the
1125 TransactionBuilder object through a transactBuilder() method in the
1126 OvsdbClient interface.
1128 The TransactionBuilder class provides the following methods to help
1131 - getOperations(): Get the list of operations in this transaction.
1133 - add(): Add data operation to this transaction.
1135 - build(): Return the list of operations in this transaction. This is
1136 the same as the getOperations() method.
1138 - execute(): Send the JSON RPC transaction to peer.
1140 - getDatabaseSchema(): Get the database schema of this transaction.
1142 If the application wants to build and send a "transact" RPC request to
1143 modify OVSDB tables on a peer, it can take the following steps:
1145 1. Statically import parameter "op" in Operations.java
1147 ``import static org.opendaylight.ovsdb.lib.operations.Operations.op;``
1149 2. Obtain transaction builder through transacBuilder() method in
1152 ``TransactionBuilder transactionBuilder = ovsdbClient.transactionBuilder(dbSchema);``
1154 3. Add operations to transaction builder:
1156 ``transactionBuilder.add(op.insert(schema, row));``
1158 4. Send transaction to peer and get JSON RPC response:
1160 ``operationResults = transactionBuilder.execute().get();``
1164 Although the "select" operation is supported in the OVSDB
1165 library, the library implementation is a little different from
1166 RFC 7047. In RFC 7047, section 5.2.2 describes the "select"
1167 operation as follows:
1169 “The "rows" member of the result is an array of objects. Each object
1170 corresponds to a matching row, with each column specified in
1171 "columns" as a member, the column’s name as the member name, and its
1172 value as the member value. If "columns" is not specified, all the
1173 table’s columns are included (including the internally generated
1174 "\_uuid" and "\_version" columns).”
1176 The OVSDB library implementation always requires the column’s name in
1177 the "columns" field of a JSON message. If the "columns" field is not
1178 specified, none of the table’s columns are included. If the
1179 application wants to get the table entry with all columns, it needs
1180 to specify all the columns’ names in the "columns" field.
1182 Reference Documentation
1183 ~~~~~~~~~~~~~~~~~~~~~~~
1185 RFC 7047 The Open vSwitch Databse Management Protocol
1186 https://tools.ietf.org/html/rfc7047
1188 OVSDB MD-SAL Southbound Plugin Developer Guide
1189 ----------------------------------------------
1194 The Open vSwitch Database (OVSDB) Model Driven Service Abstraction Layer
1195 (MD-SAL) Southbound Plugin provides an MD-SAL based interface to Open
1196 vSwitch systems. This is done by augmenting the MD-SAL topology node
1197 with a YANG model which replicates some (but not all) of the Open
1200 OVSDB MD-SAL Southbound Plugin Architecture and Operation
1201 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1203 The architecture and operation of the OVSDB MD-SAL Southbound plugin is
1204 illustrated in the following set of diagrams.
1206 Connecting to an OVSDB Node
1207 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
1209 An OVSDB node is a system which is running the OVS software and is
1210 capable of being managed by an OVSDB manager. The OVSDB MD-SAL
1211 Southbound plugin in OpenDaylight is capable of operating as an OVSDB
1212 manager. Depending on the configuration of the OVSDB node, the
1213 connection of the OVSDB manager can be active or passive.
1215 Active OVSDB Node Manager Workflow
1216 ''''''''''''''''''''''''''''''''''
1218 An active OVSDB node manager connection is made when OpenDaylight
1219 initiates the connection to the OVSDB node. In order for this to work,
1220 you must configure the OVSDB node to listen on a TCP port for the
1221 connection (i.e. OpenDaylight is active and the OVSDB node is passive).
1222 This option can be configured on the OVSDB node using the following
1227 ovs-vsctl set-manager ptcp:6640
1229 The following diagram illustrates the sequence of events which occur
1230 when OpenDaylight initiates an active OVSDB manager connection to an
1233 .. figure:: ./images/ovsdb-sb-active-connection.jpg
1234 :alt: Active OVSDB Manager Connection
1236 Active OVSDB Manager Connection
1239 Create an OVSDB node by using RESTCONF or an OpenDaylight plugin.
1240 The OVSDB node is listed under the OVSDB topology node.
1243 Add the OVSDB node to the OVSDB MD-SAL southbound configuration
1244 datastore. The OVSDB southbound provider is registered to listen for
1245 data change events on the portion of the MD-SAL topology data store
1246 which contains the OVSDB southbound topology node augmentations. The
1247 addition of an OVSDB node causes an event which is received by the
1248 OVSDB Southbound provider.
1251 The OVSDB Southbound provider initiates a connection to the OVSDB
1252 node using the connection information provided in the configuration
1253 OVSDB node (i.e. IP address and TCP port number).
1256 The OVSDB Southbound provider adds the OVSDB node to the OVSDB
1257 MD-SAL operational data store. The operational data store contains
1258 OVSDB node objects which represent active connections to OVSDB
1262 The OVSDB Southbound provider requests the schema and databases
1263 which are supported by the OVSDB node.
1266 The OVSDB Southbound provider uses the database and schema
1267 information to construct a monitor request which causes the OVSDB
1268 node to send the controller any updates made to the OVSDB databases
1271 Passive OVSDB Node Manager Workflow
1272 '''''''''''''''''''''''''''''''''''
1274 A passive OVSDB node connection to OpenDaylight is made when the OVSDB
1275 node initiates the connection to OpenDaylight. In order for this to
1276 work, you must configure the OVSDB node to connect to the IP address and
1277 OVSDB port on which OpenDaylight is listening. This option can be
1278 configured on the OVSDB node using the following command:
1282 ovs-vsctl set-manager tcp:<IP address>:6640
1284 The following diagram illustrates the sequence of events which occur
1285 when an OVSDB node connects to OpenDaylight.
1287 .. figure:: ./images/ovsdb-sb-passive-connection.jpg
1288 :alt: Passive OVSDB Manager Connection
1290 Passive OVSDB Manager Connection
1293 The OVSDB node initiates a connection to OpenDaylight.
1296 The OVSDB Southbound provider adds the OVSDB node to the OVSDB
1297 MD-SAL operational data store. The operational data store contains
1298 OVSDB node objects which represent active connections to OVSDB
1302 The OVSDB Southbound provider requests the schema and databases
1303 which are supported by the OVSDB node.
1306 The OVSDB Southbound provider uses the database and schema
1307 information to construct a monitor request which causes the OVSDB
1308 node to send back any updates which have been made to the OVSDB
1309 databases on the OVSDB node.
1311 OVSDB Node ID in the Southbound Operational MD-SAL
1312 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1314 When OpenDaylight initiates an active connection to an OVSDB node, it
1315 writes an external-id to the Open\_vSwitch table on the OVSDB node. The
1316 external-id is an OpenDaylight instance identifier which identifies the
1317 OVSDB topology node which has just been created. Here is an example
1318 showing the value of the *opendaylight-iid* entry in the external-ids
1319 column of the Open\_vSwitch table where the node-id of the OVSDB node is
1324 $ ovs-vsctl list open_vswitch
1326 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']"}
1329 The *opendaylight-iid* entry in the external-ids column of the
1330 Open\_vSwitch table causes the OVSDB node to have same node-id in the
1331 operational MD-SAL datastore as in the configuration MD-SAL datastore.
1332 This holds true if the OVSDB node manager settings are subsequently
1333 changed so that a passive OVSDB manager connection is made.
1335 If there is no *opendaylight-iid* entry in the external-ids column and a
1336 passive OVSDB manager connection is made, then the node-id of the OVSDB
1337 node in the operational MD-SAL datastore will be constructed using the
1338 UUID of the Open\_vSwitch table as follows.
1342 "node-id": "ovsdb://uuid/b8dc0bfb-d22b-4938-a2e8-b0084d7bd8c1"
1344 The *opendaylight-iid* entry can be removed from the Open\_vSwitch table
1345 using the following command.
1349 $ sudo ovs-vsctl remove open_vswitch . external-id "opendaylight-iid"
1351 OVSDB Changes by using OVSDB Southbound Config MD-SAL
1352 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1354 After the connection has been made to an OVSDB node, you can make
1355 changes to the OVSDB node by using the OVSDB Southbound Config MD-SAL.
1356 You can make CRUD operations by using the RESTCONF interface or by a
1357 plugin using the MD-SAL APIs. The following diagram illustrates the
1358 high-level flow of events.
1360 .. figure:: ./images/ovsdb-sb-config-crud.jpg
1361 :alt: OVSDB Changes by using the Southbound Config MD-SAL
1363 OVSDB Changes by using the Southbound Config MD-SAL
1366 A change to the OVSDB Southbound Config MD-SAL is made. Changes
1367 include adding or deleting bridges and ports, or setting attributes
1368 of OVSDB nodes, bridges or ports.
1371 The OVSDB Southbound provider receives notification of the changes
1372 made to the OVSDB Southbound Config MD-SAL data store.
1375 As appropriate, OVSDB transactions are constructed and transmitted
1376 to the OVSDB node to update the OVSDB database on the OVSDB node.
1379 The OVSDB node sends update messages to the OVSDB Southbound
1380 provider to indicate the changes made to the OVSDB nodes database.
1383 The OVSDB Southbound provider maps the changes received from the
1384 OVSDB node into corresponding changes made to the OVSDB Southbound
1385 Operational MD-SAL data store.
1387 Detecting changes in OVSDB coming from outside OpenDaylight
1388 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1390 Changes to the OVSDB nodes database may also occur independently of
1391 OpenDaylight. OpenDaylight also receives notifications for these events
1392 and updates the Southbound operational MD-SAL. The following diagram
1393 illustrates the sequence of events.
1395 .. figure:: ./images/ovsdb-sb-oper-crud.jpg
1396 :alt: OVSDB Changes made directly on the OVSDB node
1398 OVSDB Changes made directly on the OVSDB node
1401 Changes are made to the OVSDB node outside of OpenDaylight (e.g.
1405 The OVSDB node constructs update messages to inform OpenDaylight of
1406 the changes made to its databases.
1409 The OVSDB Southbound provider maps the OVSDB database changes to
1410 corresponding changes in the OVSDB Southbound operational MD-SAL
1416 The OVSDB Southbound MD-SAL operates using a YANG model which is based
1417 on the abstract topology node model found in the `network topology
1418 model <https://github.com/opendaylight/yangtools/blob/stable/lithium/model/ietf/ietf-topology/src/main/yang/network-topology%402013-10-21.yang>`__.
1420 The augmentations for the OVSDB Southbound MD-SAL are defined in the
1421 `ovsdb.yang <https://github.com/opendaylight/ovsdb/blob/stable/lithium/southbound/southbound-api/src/main/yang/ovsdb.yang>`__
1424 There are three augmentations:
1426 **ovsdb-node-augmentation**
1427 This augments the topology node and maps primarily to the
1428 Open\_vSwitch table of the OVSDB schema. It contains the following
1431 - **connection-info** - holds the local and remote IP address and
1432 TCP port numbers for the OpenDaylight to OVSDB node connections
1434 - **db-version** - version of the OVSDB database
1436 - **ovs-version** - version of OVS
1438 - **list managed-node-entry** - a list of references to
1439 ovsdb-bridge-augmentation nodes, which are the OVS bridges
1440 managed by this OVSDB node
1442 - **list datapath-type-entry** - a list of the datapath types
1443 supported by the OVSDB node (e.g. *system*, *netdev*) - depends
1444 on newer OVS versions
1446 - **list interface-type-entry** - a list of the interface types
1447 supported by the OVSDB node (e.g. *internal*, *vxlan*, *gre*,
1448 *dpdk*, etc.) - depends on newer OVS verions
1450 - **list openvswitch-external-ids** - a list of the key/value pairs
1451 in the Open\_vSwitch table external\_ids column
1453 - **list openvswitch-other-config** - a list of the key/value pairs
1454 in the Open\_vSwitch table other\_config column
1456 **ovsdb-bridge-augmentation**
1457 This augments the topology node and maps to an specific bridge in
1458 the OVSDB bridge table of the associated OVSDB node. It contains the
1459 following attributes.
1461 - **bridge-uuid** - UUID of the OVSDB bridge
1463 - **bridge-name** - name of the OVSDB bridge
1465 - **bridge-openflow-node-ref** - a reference (instance-identifier)
1466 of the OpenFlow node associated with this bridge
1468 - **list protocol-entry** - the version of OpenFlow protocol to use
1469 with the OpenFlow controller
1471 - **list controller-entry** - a list of controller-uuid and
1472 is-connected status of the OpenFlow controllers associated with
1475 - **datapath-id** - the datapath ID associated with this bridge on
1478 - **datapath-type** - the datapath type of this bridge
1480 - **fail-mode** - the OVSDB fail mode setting of this bridge
1482 - **flow-node** - a reference to the flow node corresponding to
1485 - **managed-by** - a reference to the ovsdb-node-augmentation
1486 (OVSDB node) that is managing this bridge
1488 - **list bridge-external-ids** - a list of the key/value pairs in
1489 the bridge table external\_ids column for this bridge
1491 - **list bridge-other-configs** - a list of the key/value pairs in
1492 the bridge table other\_config column for this bridge
1494 **ovsdb-termination-point-augmentation**
1495 This augments the topology termination point model. The OVSDB
1496 Southbound MD-SAL uses this model to represent both the OVSDB port
1497 and OVSDB interface for a given port/interface in the OVSDB schema.
1498 It contains the following attributes.
1500 - **port-uuid** - UUID of an OVSDB port row
1502 - **interface-uuid** - UUID of an OVSDB interface row
1504 - **name** - name of the port
1506 - **interface-type** - the interface type
1508 - **list options** - a list of port options
1510 - **ofport** - the OpenFlow port number of the interface
1512 - **ofport\_request** - the requested OpenFlow port number for the
1515 - **vlan-tag** - the VLAN tag value
1517 - **list trunks** - list of VLAN tag values for trunk mode
1519 - **vlan-mode** - the VLAN mode (e.g. access, native-tagged,
1520 native-untagged, trunk)
1522 - **list port-external-ids** - a list of the key/value pairs in the
1523 port table external\_ids column for this port
1525 - **list interface-external-ids** - a list of the key/value pairs
1526 in the interface table external\_ids interface for this interface
1528 - **list port-other-configs** - a list of the key/value pairs in
1529 the port table other\_config column for this port
1531 - **list interface-other-configs** - a list of the key/value pairs
1532 in the interface table other\_config column for this interface
1534 Examples of OVSDB Southbound MD-SAL API
1535 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1537 Connect to an OVSDB Node
1538 ^^^^^^^^^^^^^^^^^^^^^^^^
1540 This example RESTCONF command adds an OVSDB node object to the OVSDB
1541 Southbound configuration data store and attempts to connect to the OVSDB
1542 host located at the IP address 10.11.12.1 on TCP port 6640.
1546 POST http://<host>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/
1547 Content-Type: application/json
1551 "node-id": "ovsdb:HOST1",
1552 "connection-info": {
1553 "ovsdb:remote-ip": "10.11.12.1",
1554 "ovsdb:remote-port": 6640
1560 Query the OVSDB Southbound Configuration MD-SAL
1561 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1563 Following on from the previous example, if the OVSDB Southbound
1564 configuration MD-SAL is queried, the RESTCONF command and the resulting
1565 reply is similar to the following example.
1569 GET http://<host>:8080/restconf/config/network-topology:network-topology/topology/ovsdb:1/
1570 Application/json data in the reply
1574 "topology-id": "ovsdb:1",
1577 "node-id": "ovsdb:HOST1",
1578 "ovsdb:connection-info": {
1579 "remote-port": 6640,
1580 "remote-ip": "10.11.12.1"
1588 Reference Documentation
1589 ~~~~~~~~~~~~~~~~~~~~~~~
1592 schema <http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf>`__
1594 OVSDB Openstack Developer Guide
1595 -------------------------------
1600 The Open vSwitch database (OVSDB) Southbound Plugin component for
1601 OpenDaylight implements the OVSDB `RFC
1602 7047 <https://tools.ietf.org/html/rfc7047>`__ management protocol that
1603 allows the southbound configuration of switches that support OVSDB. The
1604 component comprises a library and a plugin. The OVSDB protocol uses
1605 JSON-RPC calls to manipulate a physical or virtual switch that supports
1606 OVSDB. Many vendors support OVSDB on various hardware platforms. The
1607 OpenDaylight controller uses the library project to interact with an OVS
1610 `OpenStack <http://www.openstack.org>`__ is a popular open source
1611 Infrastructure as a Service (IaaS) project, covering compute, storage
1612 and network management. OpenStack can use OpenDaylight as its network
1613 management provider through the Neutron API, which acts as a northbound
1614 for OpenStack. the OVSDB NetVirt piece of the OVSDB project is a
1615 provider for the Neutron API in OpenDaylight. OpenDaylight manages the
1616 network flows for the OpenStack compute nodes via the OVSDB project,
1617 with the south-bound plugin. This section describes how to set that up,
1618 and how to tell when everything is working.
1620 OVSDB Openstack Architecture
1621 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1623 The OpenStack integration architecture uses the following technologies:
1625 - `RFC 7047 <https://tools.ietf.org/html/rfc7047>`__ - The Open vSwitch
1626 Database Management Protocol
1629 v1.3 <http://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.3.4.pdf>`__
1631 - `OpenStack Neutron ML2
1632 Plugin <https://wiki.openstack.org/wiki/Neutron/ML2>`__
1634 |Openstack Integration|
1636 OVSDB Service Function Chaining Developer Guide
1637 -----------------------------------------------
1642 The OVSDB NetVirtSfc provides a classification and traffic steering
1643 component when integrated with OpenStack. Please refer to the Service
1644 Function Chaining project for the theory and programming of service
1647 Installing the NetVirt SFC Feature
1648 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1650 Install the odl-ovsdb-sfc feature. The feature will also ensure that the
1651 odl-ovsdb-openstack feature as well as the openflowplugin, neutron and
1652 sfc features are installed.
1654 feature:install odl-ovsdb-sfc-ui ---
1656 Verify the required features are installed:
1658 opendaylight-user@root>feature:list -i \| grep ovsdb
1660 odl-ovsdb-southbound-api \| 1.2.1-SNAPSHOT \| x \|
1661 odl-ovsdb-southbound-1.2.1-SNAPSHOT \| OpenDaylight
1664 odl-ovsdb-southbound-impl \| 1.2.1-SNAPSHOT \| x \|
1665 odl-ovsdb-southbound-1.2.1-SNAPSHOT \| OpenDaylight :: southbound
1668 odl-ovsdb-southbound-impl-rest \| 1.2.1-SNAPSHOT \| x \|
1669 odl-ovsdb-southbound-1.2.1-SNAPSHOT \| OpenDaylight :: southbound ::
1673 odl-ovsdb-southbound-impl-ui \| 1.2.1-SNAPSHOT \| x \|
1674 odl-ovsdb-southbound-1.2.1-SNAPSHOT \| OpenDaylight :: southbound ::
1678 odl-ovsdb-library \| 1.2.1-SNAPSHOT \| x \|
1679 odl-ovsdb-library-1.2.1-SNAPSHOT \| OpenDaylight
1682 odl-ovsdb-openstack \| 1.2.1-SNAPSHOT \| x \| ovsdb-1.2.1-SNAPSHOT \|
1683 OpenDaylight :: OVSDB
1684 OpenStack Network Virtual
1686 odl-ovsdb-sfc-api \| 1.2.1-SNAPSHOT \| x \| odl-ovsdb-sfc-1.2.1-SNAPSHOT
1687 \| OpenDaylight :: ovsdb-sfc
1690 odl-ovsdb-sfc \| 1.2.1-SNAPSHOT \| x \| odl-ovsdb-sfc-1.2.1-SNAPSHOT \|
1694 odl-ovsdb-sfc-rest \| 1.2.1-SNAPSHOT \| x \|
1695 odl-ovsdb-sfc-1.2.1-SNAPSHOT \| OpenDaylight :: ovsdb-sfc
1698 odl-ovsdb-sfc-ui \| 1.2.1-SNAPSHOT \| x \| odl-ovsdb-sfc-1.2.1-SNAPSHOT
1699 \| OpenDaylight :: ovsdb-sfc
1702 opendaylight-user@root>feature:list -i \| grep sfc odl-sfc-model \|
1703 0.2.0-SNAPSHOT \| x \| odl-sfc-0.2.0-SNAPSHOT \| OpenDaylight :: sfc ::
1704 Model odl-sfc-provider \| 0.2.0-SNAPSHOT \| x \| odl-sfc-0.2.0-SNAPSHOT
1705 \| OpenDaylight :: sfc :: Provider odl-sfc-provider-rest \|
1706 0.2.0-SNAPSHOT \| x \| odl-sfc-0.2.0-SNAPSHOT \| OpenDaylight :: sfc ::
1707 Provider odl-sfc-ovs \| 0.2.0-SNAPSHOT \| x \| odl-sfc-0.2.0-SNAPSHOT \|
1708 OpenDaylight :: OpenvSwitch odl-sfcofl2 \| 0.2.0-SNAPSHOT \| x \|
1709 odl-sfc-0.2.0-SNAPSHOT \| OpenDaylight :: sfcofl2 odl-ovsdb-sfc-test \|
1710 1.2.1-SNAPSHOT \| x \| odl-ovsdb-sfc-test1.2.1-SNAPSHOT \| OpenDaylight
1711 :: ovsdb-sfc-test odl-ovsdb-sfc-api \| 1.2.1-SNAPSHOT \| x \|
1712 odl-ovsdb-sfc-1.2.1-SNAPSHOT \| OpenDaylight :: ovsdb-sfc :: api
1713 odl-ovsdb-sfc \| 1.2.1-SNAPSHOT \| x \| odl-ovsdb-sfc-1.2.1-SNAPSHOT \|
1714 OpenDaylight :: ovsdb-sfc odl-ovsdb-sfc-rest \| 1.2.1-SNAPSHOT \| x \|
1715 odl-ovsdb-sfc-1.2.1-SNAPSHOT \| OpenDaylight :: ovsdb-sfc :: REST
1716 odl-ovsdb-sfc-ui \| 1.2.1-SNAPSHOT \| x \| odl-ovsdb-sfc-1.2.1-SNAPSHOT
1717 \| OpenDaylight :: ovsdb-sfc :: UI
1719 opendaylight-user@root>feature:list -i \| grep neutron
1720 odl-neutron-service \| 0.6.0-SNAPSHOT \| x \| odl-neutron-0.6.0-SNAPSHOT
1721 \| OpenDaylight :: Neutron :: API odl-neutron-northbound-api \|
1722 0.6.0-SNAPSHOT \| x \| odl-neutron-0.6.0-SNAPSHOT \| OpenDaylight ::
1723 Neutron :: Northbound odl-neutron-spi \| 0.6.0-SNAPSHOT \| x \|
1724 odl-neutron-0.6.0-SNAPSHOT \| OpenDaylight :: Neutron :: API
1725 odl-neutron-transcriber \| 0.6.0-SNAPSHOT \| x \|
1726 odl-neutron-0.6.0-SNAPSHOT \| OpenDaylight :: Neutron :: Implementation
1729 OVSDB NetVirt Service Function Chaining Example
1730 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1732 The architecture within OpenDaylight can be seen in the following
1735 .. figure:: ./images/ovsdb/ODL_SFC_Architecture.png
1736 :alt: OpenDaylight OVSDB NetVirt SFC Architecture
1738 OpenDaylight OVSDB NetVirt SFC Architecture
1740 Tacker is a Virtual Network Functions Manager that is responsible for
1741 orchestrating the Service Function Chaining. Tacker is responsible for
1742 generating templates for Virtual Network Functions for OpenStack to
1743 instantiate the Service Functions. Tacker also uses the RESTCONF
1744 interfaces of OpenDaylight to create the Service Function Chains.
1749 OVSDB NetVirt SFC implements the classification for the chains. The
1750 classification steers traffic from the tenant overlay to the chain
1751 overlay and back to the tenant overlay.
1753 An Access Control List used by NetVirtSFC to create the classifier is
1754 shown below. This is an example of classifying HTTP traffic using the
1755 tcp port 80. In this example the user would have created a Service
1756 Function Chain with the name "http-sfc" as well as all the associated
1757 Service Functions and Service Function Forwarders for the chain.
1759 http://localhost:8181/restconf/config/ietf-access-control-list:access-lists
1761 { "access-lists": { "acl": [ { "acl-name": "http-acl",
1762 "access-list-entries": { "ace": [ { "rule-name": "http-rule", "matches":
1763 { "source-port-range": { "lower-port": 0, "upper-port": 0 }, "protocol":
1764 6, "destination-port-range": { "lower-port": 80, "upper-port": 80 } },
1765 "actions": { "netvirt-sfc-acl:sfc-name": "http-sfc" } } ] } } ] } } ---
1767 When the chain is rendered using the Rendered Service Path RPC,
1768 NetvirtSfc will add the classification flows. The classification flows
1769 are shown below. The list shown has been modified to remove the NetVirt
1770 tenant overlay flows. The classification flow is identified with the
1771 cookie: 0x1110010000040255. The 6th digit of the cookie identifies the
1772 flow type as the classifier. The last 8 digits identify the chain with
1773 the first four digits indicating the NSH NSP and the last four digits
1774 identifying the NSH NSI. In this case the chain is identified with an
1775 NSP of 4 and the NSI is 255 to indicate the beginning of the chain.
1777 sudo ovs-ofctl --protocol=OpenFlow13 dump-flows br-int OFPST\_FLOW reply
1778 (OF1.3) (xid=0x2): cookie=0x0, duration=17.157s, table=0, n\_packets=0,
1779 n\_bytes=0, priority=6 actions=goto\_table:1 cookie=0x14,
1780 duration=10.692s, table=0, n\_packets=0, n\_bytes=0,
1781 priority=400,udp,in\_port=4,tp\_dst=6633 actions=LOCAL cookie=0x0,
1782 duration=17.134s, table=0, n\_packets=0, n\_bytes=0, dl\_type=0x88cc
1783 actions=CONTROLLER:65535 cookie=0x14, duration=10.717s, table=0,
1784 n\_packets=0, n\_bytes=0, priority=350,nsp=4 actions=goto\_table:152
1785 cookie=0x14, duration=10.688s, table=0, n\_packets=0, n\_bytes=0,
1786 priority=400,udp,nw\_dst=10.2.1.1,tp\_dst=6633 actions=output:4
1787 cookie=0x0, duration=17.157s, table=1, n\_packets=0, n\_bytes=0,
1788 priority=0 actions=goto\_table:11 cookie=0x1110070000040254,
1789 duration=10.608s, table=1, n\_packets=0, n\_bytes=0,
1790 priority=40000,reg0=0x1,nsp=4,nsi=254,in\_port=1 actions=goto\_table:21
1791 cookie=0x0, duration=17.157s, table=11, n\_packets=0, n\_bytes=0,
1792 priority=0 actions=goto\_table:21 cookie=0x1110060000040254,
1793 duration=10.625s, table=11, n\_packets=0, n\_bytes=0,
1794 nsp=4,nsi=254,in\_port=4
1795 actions=load:0x1→NXM\_NX\_REG0[],move:NXM\_NX\_NSH\_C2[]→NXM\_NX\_TUN\_ID[0..31],resubmit(1,1)
1796 cookie=0x1110010000040255, duration=10.615s, table=11, n\_packets=0,
1797 n\_bytes=0, tcp,reg0=0x1,tp\_dst=80
1798 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)
1799 cookie=0x0, duration=17.157s, table=21, n\_packets=0, n\_bytes=0,
1800 priority=0 actions=goto\_table:31 cookie=0x1110040000000000,
1801 duration=10.765s, table=21, n\_packets=0, n\_bytes=0,
1802 priority=1024,arp,in\_port=LOCAL,arp\_tpa=10.2.1.1,arp\_op=1
1803 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
1804 cookie=0x0, duration=17.157s, table=31, n\_packets=0, n\_bytes=0,
1805 priority=0 actions=goto\_table:41 cookie=0x0, duration=17.157s,
1806 table=41, n\_packets=0, n\_bytes=0, priority=0 actions=goto\_table:51
1807 cookie=0x0, duration=17.157s, table=51, n\_packets=0, n\_bytes=0,
1808 priority=0 actions=goto\_table:61 cookie=0x0, duration=17.142s,
1809 table=61, n\_packets=0, n\_bytes=0, priority=0 actions=goto\_table:71
1810 cookie=0x0, duration=17.140s, table=71, n\_packets=0, n\_bytes=0,
1811 priority=0 actions=goto\_table:81 cookie=0x0, duration=17.116s,
1812 table=81, n\_packets=0, n\_bytes=0, priority=0 actions=goto\_table:91
1813 cookie=0x0, duration=17.116s, table=91, n\_packets=0, n\_bytes=0,
1814 priority=0 actions=goto\_table:101 cookie=0x0, duration=17.107s,
1815 table=101, n\_packets=0, n\_bytes=0, priority=0 actions=goto\_table:111
1816 cookie=0x0, duration=17.083s, table=111, n\_packets=0, n\_bytes=0,
1817 priority=0 actions=drop cookie=0x14, duration=11.042s, table=150,
1818 n\_packets=0, n\_bytes=0, priority=5 actions=goto\_table:151
1819 cookie=0x14, duration=11.027s, table=151, n\_packets=0, n\_bytes=0,
1820 priority=5 actions=goto\_table:152 cookie=0x14, duration=11.010s,
1821 table=152, n\_packets=0, n\_bytes=0, priority=5 actions=goto\_table:158
1822 cookie=0x14, duration=10.668s, table=152, n\_packets=0, n\_bytes=0,
1823 priority=650,nsp=4,nsi=255
1824 actions=load:0xa020101→NXM\_NX\_TUN\_IPV4\_DST[],goto\_table:158
1825 cookie=0x14, duration=10.995s, table=158, n\_packets=0, n\_bytes=0,
1826 priority=5 actions=drop cookie=0xba5eba11ba5eba11, duration=10.645s,
1827 table=158, n\_packets=0, n\_bytes=0,
1828 priority=751,nsp=4,nsi=255,in\_port=4
1829 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
1830 cookie=0xba5eba11ba5eba11, duration=10.590s, table=158, n\_packets=0,
1831 n\_bytes=0, priority=751,nsp=4,nsi=254,in\_port=4
1832 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
1833 cookie=0xba5eba11ba5eba11, duration=10.640s, table=158, n\_packets=0,
1834 n\_bytes=0, priority=750,nsp=4,nsi=255
1835 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
1836 cookie=0xba5eba11ba5eba11, duration=10.571s, table=158, n\_packets=0,
1837 n\_bytes=0, priority=761,nsp=4,nsi=254,nshc1=3232248390,in\_port=4
1838 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)
1844 Some configuration is required due to application coexistence for the
1845 OpenFlow programming. The SFC project programs flows for the SFC overlay
1846 and NetVirt programs flows for the tenant overlay. Coexistence is
1847 achieved by each application owning a unique set of tables and providing
1848 a simple handoff between the tables.
1850 First configure NetVirt to use table 1 as it’s starting table:
1852 http://localhost:8181/restconf/config/netvirt-providers-config:netvirt-providers-config
1854 { "netvirt-providers-config": { "table-offset": 1 } } ---
1856 Next configure SFC to start at table 150 and configure the table
1857 handoff. The configuration starts SFC at table 150 and sets the handoff
1858 to table 11 which is the NetVirt SFC classification table.
1860 http://localhost:8181/restconf/config/sfc-of-renderer:sfc-of-renderer-config
1862 { "sfc-of-renderer-config": { "sfc-of-app-egress-table-offset": 11,
1863 "sfc-of-table-offset": 150 } } ---
1865 OVSDB Hardware VTEP Developer Guide
1866 -----------------------------------
1873 OVSDB Hardware VTEP Architecture
1874 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~