+1 (669) 231-3838 or +1 (800) 930-5144

Top 10 Things For New OpenDaylight Developers

I recently started contributing upstream to the Open Daylight project (ODL) as a developer. I mostly followed the ODL developer documentation on how to get started and how to use the tools. Through ambiguous documentation or through hubris (every developer always thinks they know what they are doing), I made some mistakes and had to learn some things the hard way. This article is an enumeration of some of those hard knocks, just in case it can help the next person following this path.

First, this list is more than ten items. It is just that “top 10” has a catchy sound to it that just isn’t there for “top 17”.

Gerrit Workflow

Gerrit has a different workflow that you are likely using in downstream coding with other tools. There is a general tutorial and an ODL coding introduction to working with Gerrit that is very helpful.

Coding Conventions

We followed our own coding guidelines and those did not match to the Google coding conventions used upstream. Differences we ran into were:

  • Lower-case method names, even for JUnit test methods
  • Using the most restrictive visibility for access qualifiers (I won’t push back the philosophy of library design)
  • Use Java 8 lambdas everywhere possible

Gerrit Commands

Gerrit (plugin) has some non-obvious controls, namely that you can kick off another build by putting “recheck” as your comment. Others are “rerun”, “verify” as in here.

WIP

Upstream coders usually add the prefix “WIP: ” to their bug report to let other developers know things are not ready for prime time reviews yet. I have been putting the “WIP:” prefix as a new comment right after my new patch set.

Diffs

Mechanically you can review the issues by using “Diff against:” drop list to pick a revision to start at then go into the first file and then use the upper right arrows to move between files.

Broken Master

The master branch on ODL can and does break, causing lots of down time with broken builds (days even). Full builds take 10 hours and verifying-before-pushing is an evolving process. Have patience.

Git Review

If you are using “git review” and you forgot the “- – amend” option on your commit, you will be prompted to squash and will end up with a new branch. You can recover using “git rebase -i HEAD~2” then using the force option and then abandoning the new branch.

Staleness

Along with master breaking, master can also produce stale artifacts, so don’t assume that clearing your m2 cache, creating a subproject repo and building will give you up-to-date code.

Searching Jars

You can search jar files using find . -type f -name ‘*.jar’ -print0 |  xargs -0 -I ‘{}’ sh -c ‘jar tf {} | grep “YourClassHere” &&  echo {}’ for helping verify your m2 has the latest.

Patch Workflow

The patch workflow is not very good at all for having multiple people working on an item; traditional git branches and management are superior in this respect so expect some pain.

Broken Master Again

If your patch won’t build because master is broken, you can rebase it to pick up a fix temporarily. When you do a “git review” to push it, you will be prompted because there are two commits (your new patch revision and the fix). You do not want to merge that fix into your patch.

Skip Tests

There may be a bug here or there in dependencies, so you should always to a full build within a subproject the first time after you create the repo. In my case, I was in netconf and saw a difference between starting off with a “-DskipTests” or not. The former lead to a failed build, while starting with a full build (and then doing any number of skip tests), seemed to work.

Checkstyle

If you are a developer who works with meaningful coding standards, you will find yourself clashing with the pedantic nature of ODL’s use of check style. Although it probably varies from project to project, your code reviewer might decide that your code is the perfect opportunity to enforce check style.

Bug Report

Put the URL to the gerrit issue in “external references” on the bug report and put the bug as the first part of the commit message like “BUG-8118: ….”

Gerrit Patch Set

Any replies that you make to the patch set discussion use the current patch set as an annotation. Be sure to move your “current patch set” by using the upper right drop list “Patch sets 8/8” (for example).

Easy Debug

You can do development on a project like netconf and start a controller with your code: git clone, mvn clean install, go to netconf/karaf/target/assembly/bin, do ./karaf, at console install your feature, like feature:install odl-netconf-callhome-ssh (and maybe odl-mdsal-apidocs). Viola!

Docs

If you work on the docs, then you need to know there are three kinds: contributor (on wiki), developer, and user (both on docs.opendaylight.org).

Getting Started Upstream in ODL

By Allan Clarke and Anil Vishnoi

 

 

Getting started as an upstream contributor to OpenDaylight is not easy. The controller ecosystem is big, there are many projects, and there are millions of lines of code. What is a new ODL developer to do? Here is some pragmatic advice on where to begin to become an active contributor.

Fix Bugs

One of the easiest ways to get to know a code base is to start fixing bugs. Peruse the ODL bugs list on Bugzilla, say with the NETCONF project. You want to find bugs that aren’t likely being worked on and are of limited scope (to match your limited understanding of the project). Ideally bugs will have an owner assigned to indicate that they are actively being worked on, but it is not always a great indicator. In particular, someone may run across a bug, file a report, then jump into fixing it—and forget to assign it to themselves. This is most likely with the project contributors, so figure out who are the project contributors and look at the date of the report. If it was a project contributor and a newish date, then that bug might be being worked on. You should read through the report and try to decide how much domain knowledge is needed—as a newbie, smaller is better.

Once you have selected a bug to work on, click on the “take” link. Also add a comment to the bug. If someone already is working on it, they should get a notice and respond. You can also try the ODL mailing lists and give notice there. You mainly want to avoid duplicate work, of course.

Review Patches

Reviewing patches is a great way to contribute. You can access patches via Gerrit, and we’ll use the NETCONF patches as an example. Doing code reviews is a great way to not only see existing code but also to interact with other developers.

  • If you have some domain expertise and know the code, you can review the functionality that is being pushed.
  • If you have neither of these, you can do the review based on Java best practices and good software engineering practice.

Address Technical Debt

ODL uses Sonar for analytics of the upstream project. Here is an example for the NETCONF issues. Note that the ODL project has coding conventions, and the Sonar Qube has some best practices. This list shows violations that should be addressed. As a newbie, you can work on these with little domain knowledge required. You can also see that the code coverage varies for the NETCONF coverage, so adding NETCONF unit tests to boost the coverage in the weakest areas would be very helpful.

Sonar has a lot of interesting metrics. You can explore some of them starting here including coverage, tech debt, etc. If you look at the Sonar dashboard, it will point out a lot of available work that does not require a large span of time to invest. Doing some of this work is a great step towards getting your first patch submitted.

Follow Best Practices

With well over a million lines of code and many contributors from many companies, the ODL project has quite a girth. To manage the code entropy, ODL has some best practices that you should become familiar with. These cover a diverse set of topics, including coding practices, debugging, project setup and workflow. We strongly recommend that you carefully read these. They will save you a lot of time and will pay back your investment quickly. They will help you skate through code reviews. These practices are really time-tested advice from all the ODL developers, so don’t ignore them.

Support Attribution

Attribution is an important insight into most if not all open source projects. Attribution allows stakeholders to see who is contributing what, from the individual up through sponsoring companies. It allows both a historical and current view of the project. You can see an example of why attribution is illuminating here. You need to sign up for an ODL account, and a part of that process will be to associate yourself with a company (if applicable). You can also see breakdowns by authors on the ODL Spectrometer.

That’s all for now. Happy trails, newbie.

Watch for Allan’s blog next week where he will share his Top 10 learnings as a new developer contributing to ODL.

Service Providers Are Placing Big Bets on Open Source Software Networking – Should You?

The service provider market is undergoing earth-shaking changes. These changes impact the way that applications for consumers and business users are deployed in the network and cloud as well as the way that the underlying data transport networks are built.

At Lumina, we’ve had the chance to work with several large service providers on their software transformation initiatives and get an up-close look at what works and what doesn’t. Three factors are particularly favorable in setting up successful projects for frictionless progress from the lab through prototype and proof of concept and into the production network.

Top-Down Advantage

Our first observation is that top-down initiatives and leadership work better than bottom-up or “grass roots” approaches. The experience of AT&T strongly illustrates the advantage. While a few of the hyperscale cloud providers had already launched open source initiatives and projects, the first big move among the established service providers was AT&T’s Domain 2.0, led by John Donovan in 2013. Domain 2.0 was not a precise description of everything that AT&T wanted to do, but through that initiative, the leadership created an environment where transformative projects are embraced and resistance to change is pushed aside.

While lack of top down support is not a showstopper, it is extremely helpful to get past obstacles and overcome organizational resistance to change. If top-down support in your organization is lacking or weak, it is worth your effort to influence and educate your executives. In engaging executives focus on the business value of open software networking. The advantages of open source in software networks include eliminating lock-in and spurring innovation. As our CEO, Andrew Coward, wrote in his recent blog, Why Lumina Networks? Why Now?: “Those who build their own solutions—using off-the-shelf components married to unique in-house developed functionality—build-in the agility and options for difference that are necessary to stay ahead.”

Although it may create a slower start, from what we have seen, taking the time to do early PoCs to onboard executive support so that they deeply attach to the value is time well worth spent. Sometimes a slow start is just what is needed to move fast.

Collaboration through Open Source

The second observation is that industry collaboration can work. I read an interesting comment by Radhika Venkatraman, senior vice president and CIO of network and technology at Verizon, in her interview with SDxCentral. She said, “We are trying to learn from the Facebooks and Googles about how they did this.” One of the best ways to collaborate with other thought leaders in the industry is to join forces within the developer community at open source projects. The Linux Foundation’s OpenDaylight Project includes strong participation from both the vendor community and global service providers including AT&T, Alibaba Group, Baidu, China Mobile, Comcast and Tencent. Tencent, for one, has over 500 million subscribers that utilize their OpenDaylight infrastructure, and they are contributing back to the community as are many others.

A great recent example of industry collaboration is the newly announced ONAP (Open Network Automation Platform) project. Here, the origins of the project have roots in work done by AT&T, China Mobile and others. And now, we have a thriving open source developer community consisting of engineers and innovators who may not have necessarily collaborated in the past.

These participants see benefits of collaboration not only to accelerate innovation but also to build the software run time across many different types of environments and use cases so as to increase reliability. Providers recognize that in their transformation to software networks there’s much they can do together to drive technology, while using how they define and deliver services to stand out from each other in the experiences created for customers.

What about your organization? Do you engage in the OpenDaylight community? Have you explored how ONAP can help you? Do you use OpenStack in your production network? And importantly, do you engage in the discussions and share back what you learn and develop?

Pursuit of Innovation

A third observation is the growing ability for service providers to create and innovate at levels not seen before. A prime example here is the work done by CenturyLink to develop Central Office Re-architected as a Datacenter platform to deliver DSL services running on OpenDaylight. CenturyLink used internal software development teams along with open source and Agile approaches to create and deploy CORD as part of a broad software transformation initiative.

One might have thought that you would only see this level of innovation at Google, Facebook or AWS, but at Lumina we are seeing this as an industry-wide trend. The customer base, business model, and operations of service providers vary widely from one to another based on their historical strengths and legacy investment. All have an opportunity to innovate in a way that advances their particular differences and competitive advantages.

Closing Thoughts

So we encourage you to get on the bandwagon! Don’t stand on the sidelines. A combination of leadership, collaboration and innovation are the ingredients you need to help your organization drive the software transformation needed to stay competitive. There is no other choice.

Stay tuned for my next blog where we will discuss some of the specifics of the advantages, development and innovation using open source.

NetDevEMEA : OpenStack, Opendaylight and VTN Feature

NetDevEMEA : OpenStack, Opendaylight and VTN Feature

  1. Introduction


     

 

 

OpenDaylight Virtual Tenant Network (VTN) is an opendaylig’s feature that provides multi-tenant virtual network. It alows aggregate multiple ports from the many both physical and Virtual to form a single isolated virtual network called Virtual Tenant Network. Each tenant network has the capabilities to function as an individual switch.

The objective of this tutorial is to facilitate a configuration/integration of Openstack Mitaka with Opendalylight that permits explore VTN feature.


 

 

 

Figure  above, shows the logical architecture after this guide.

  1. Virtualbox configuration:

    1. Download and install Virtualbox

      Install VirtualBox (version 5.0 and up), and VirtualBox Extension packs (follow instructions for Extension packs here).

    2. Download a Centos Centos 7.2
      Main download page for CentOS7
    3. Run Virualbox and Create 2 x Host Only Networks

      To create a host-only connection in VirtualBox, start by opening the preferences in VirtualBox. Go to the Network tab, and click on add a new Host-only Network.

      Host-Only networks configuration
      # This will be used for data i.e. vxlan tunnels
      #VirtualBox Host-Only Ethernet Adapter 1
      IPv4 Address 192.168.254.1
      Netmask 255.255.255.0
      DHCP Server Disabled
      # This will be used for mgmt, i.e. I connect from Windows to the VMs, or for VM to VM communication
      #VirtualBox Host-Only Ethernet Adapter 2
      IPv4 Address 192.168.120.1
      Netmask 255.255.255.0
      DHCP Server Disabled
    4. Create 3 x VirtualBox Machines running Centos 7.2 (installed from ISO). Setting up
      openstack-compute
      #System
      RAM 4096
      Processors 2
      #Network
      NIC 1 Bridged Adapter (Provides internet connectivity)  (enp0s3)
      NIC 2 Host-Only VirtualBox Host-Only Ethernet Adapter 1 (statically configured 192.168.254.132 enp0s8)
      NIC 3 Host-Only VirtualBox Host-Only Ethernet Adapter 2 (statically configured 192.168.120.132 enp0s9)
      openstack-controller
      #System
      RAM 4096
      Processors 2
      #Network
      NIC 1 Bridged Adapter (Provides internet connectivity)  (enp0s3)
      NIC 2 Host-Only VirtualBox Host-Only Ethernet Adapter 1 (statically configured 192.168.254.131 enp0s8)
      NIC 3 Host-Only VirtualBox Host-Only Ethernet Adapter 2 (statically configured 192.168.120.131 enp0s9)
      OpenDaylight-Controller
      #System
      RAM 4096
      Processors 2
      #Network
      NIC 1 Bridged Adapter (Provides internet connectivity)  (enp0s3)
      NIC 2 Host-Only VirtualBox Host-Only Ethernet Adapter 1 (statically configured 192.168.254.254 enp0s8)
      NIC 3 Host-Only VirtualBox Host-Only Ethernet Adapter 2 (statically configured 192.168.120.254 enp0s9)
    5. Interface Configuration Files

      First thing to do after run each VM is edit all interface configuration files. In CentOS system they could be found here  /etc/sysconfig/network-scripts/. Here is a sample of how must to look the interface files for the openstack-controller.  Make sure they look similar on all 3 of your machines

      /etc/sysconfig/network-scripts/ifcfg-enp0s3
      TYPE=Ethernet
      BOOTPROTO=dhcp
      DEFROUTE=yes
      IPV4_FAILURE_FATAL=no
      IPV6INIT=no
      IPV6_AUTOCONF=yes
      IPV6_DEFROUTE=yes
      IPV6_PEERDNS=yes
      IPV6_PEERROUTES=yes
      IPV6_FAILURE_FATAL=no
      NAME=enp0s3
      DEVICE=enp0s3
      ONBOOT=yes
      PEERDNS=yes
      PEERROUTES=yes
      /etc/sysconfig/network-scripts/ifcfg-enp0s8
      TYPE=Ethernet
      BOOTPROTO=none
      DEFROUTE=no
      IPV4_FAILURE_FATAL=yes
      IPV6INIT=no
      IPV6_AUTOCONF=yes
      IPV6_DEFROUTE=yes
      IPV6_PEERDNS=yes
      IPV6_PEERROUTES=yes
      IPV6_FAILURE_FATAL=no
      NAME=enp0s8
      DEVICE=enp0s8
      ONBOOT=yes
      IPADDR=192.168.254.131 #Modify this value in case you are configuring openstack-compute or Opendaylight controller
      PREFIX=24
      GATEWAY=192.168.254.1
      /etc/sysconfig/network-scripts/ifcfg-enp0s9
      TYPE=Ethernet
      BOOTPROTO=none
      DEFROUTE=no
      IPV4_FAILURE_FATAL=yes
      IPV6INIT=no
      IPV6_AUTOCONF=yes
      IPV6_DEFROUTE=yes
      IPV6_PEERDNS=yes
      IPV6_PEERROUTES=yes
      IPV6_FAILURE_FATAL=no
      NAME=enp0s9
      DEVICE=enp0s9
      ONBOOT=yes
      IPADDR=192.168.120.131
      PREFIX=24
      GATEWAY=192.168.120.1
  2. Openstack Install

    1. Pre-Configuration

      Edit /etc/hosts on all three VMs so it looks like this:

      /etc/hosts
      192.168.120.131 controller.netdev.brocade.com 192.168.120.132 compute-01.netdev.brocade.com compute
      192.168.120.254 opendaylight.brocade.com opendaylight

      Disable Firewall and NetworkManager

      systemctl disable firewalld systemctl stop firewalld
      systemctl disable NetworkManager 
      systemctl stop NetworkManager
      systemctl enable network 
      systemctl start network

      Disable SE Linux and install Openstack packstack RDO

      setenforce 0 sed -i 's/^SELINUX=.*/SELINUX=disabled/g' /etc/selinux/config
      
      
      yum install -y centos-release-openstack-mitaka.noarch
      yum install -y openstack-packstack
      yum update -y

      Install Openstack Run the following command int openstack-controller (openstack-compute VM must to be running)

      packstack\
      --install-hosts=192.168.120.131,192.168.120.132\
      --novanetwork-pubif=enp0s9\
      --novacompute-privif=enp0s8\
      --provision-demo=n\
      --provision-ovs-bridge=n\
      --os-swift-install=n\
      --nagios-install=n\
      --os-ceilometer-install=n\
      --os-aodh-install=n\
      --os-gnocchi-install=n\
      --os-controller-host=192.168.120.131\
      --os-compute-hosts=192.168.120.132\
      --default-password=helsinki
    2. Test the environemnt

      On the same directory as the previous command was run:

      source keystonerc_admin
      curl -O http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
      glance image-create --file ./cirros-0.3.4-x86_64-disk.img --visibility public --container-format bare --disk-format qcow2 --name cirros

      Login to the UI http://192.168.120.131/dashboard (User: admin, pass: helsinki)

      Create a network, and router.  Create VM and check that it gets an IP

  3. Install OpenDaylight

     

    1. Install Opendaylight Boron SR2 and enable the necessary features:
       odl-ovsdb-openstack
       odl-dlux-core
       odl-ovsdb-ui
      There are two OpenStack plugins.  odl-ovsdb-opesntack and odl-netvirt-openstack.  The ovsdb is the older plugin and will be depreciated shortly, but this is what is used within BSC.   The next release of BSC should switch to the netvirt plugin.
      curl -O --insecure https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/integration/distribution-karaf/0.5.2-Boron-SR2/distribution-karaf-0.5.2-Boron-SR2.tar.gz
      ln -s distribution-karaf-0.5.2-Boron-SR2 odl
      cd odl/bin
      ./start
      ./client -u karaf
      feature:install odl-ovsdb-openstack odl-dlux-core odl-ovsdb-ui

      Verify the install by browsing to the DLUX UI (admin : admin)

      http://192.168.120.254:8181/index.html#/topology

      Also check that the REST API works and is returning an empty set of networks

      curl –u admin:admin http://192.168.120.254:8181/controller/nb/v2/neutron/networks

  4. Openstack Integration

    1. Erase all VMs, networks, routers and ports in the Controller Node

      Start by deleting any VMs,Networks and routers that you have already created during the testing. Before integrating the OpenStack with the OpenDaylight, you must clean up all the unwanted data from the OpenStack database. When using OpenDaylight as the Neutron back-end, ODL expects to be the only source for Open vSwitch configuration. Because of this, it is necessary to remove existing OpenStack and Open vSwitch settings to give OpenDaylight a clean slate.Following steps will guide you through the cleaning process!

      # Delete instances
      $ nova list
      $ nova delete <instance names>
      # Remove link from subnets to routers
      $ neutron subnet-list
      $ neutron router-list
      $ neutron router-port-list <router name>
      $ neutron router-interface-delete <router name> <subnet ID or name>
      # Delete subnets, nets, routers
      $ neutron subnet-delete <subnet name>
      $ neutron net-list
      $ neutron net-delete <net name>
      $ neutron router-delete <router name>
      # Check that all ports have been cleared – at this point, this should be an empty list
      $ neutron port-list
      # Stop the neutron service
      $ service neutron-server stop
      

      While Neutron is managing the OVS instances on compute and control nodes, OpenDaylight and Neutron can be in conflict. To prevent issues, we turn off Neutron server on the network controller and Neutron’s OpenvSwitch agents on all hosts.

    2. Add an external bridge port

      Create  a new interface configuration file  /etc/sysconfig/network-scripts/ifcfg-br-ex

      It should look something like this (change the IPs to match your system – this should be the IP previously assigned to enp0s3)

      /etc/sysconfig/network-scripts/ifcfg-br-ex
      DEVICE=br-ex
      DEVICETYPE=ovs
      TYPE=OVSBridge
      BOOTPROTO=static
      IPADDR=172.168.0.78 # Previous IP associate to your enp0s3
      NETMASK=255.255.255.0
      # Previous IP mask
      GATEWAY=172.168.0.1 # Previous gateway
      ONBOOT=yes
      PEERDNS=yes
      PEERROUTES=yes
      

      Update enp0s3 – you can comment out the original settings, and add the new lines below

       vi /etc/sysconfig/network-scripts/ifcfg-enp0s3

      /etc/sysconfig/network-scripts/ifcfg-enp0s3
      #TYPE=Ethernet
      #BOOTPROTO=dhcp
      #DEFROUTE=yes
      #IPV4_FAILURE_FATAL=no
      #IPV6INIT=no
      #IPV6_AUTOCONF=yes
      #IPV6_DEFROUTE=yes
      #IPV6_PEERDNS=yes
      #IPV6_PEERROUTES=yes
      #IPV6_FAILURE_FATAL=no
      #NAME=enp0s3
      #UUID=edcc0443-c780-48a0-bf2f-5de17751db78
      #DEVICE=enp0s3 #ONBOOT=yes
      #PEERDNS=yes
      #PEERROUTES=yes
      DEVICE=enp0s3
      TYPE=OVSPort
      DEVICETYPE=ovs
      OVS_BRIDGE=br-ex
      ONBOOT=yes
  5. Connect Openstack Controller and Compute  OVS to ODL

    Run next commands in both Openstack nodes:

    1. Set ODL Management IP
      export ODL_IP=192.168.120.254
      export OS_DATA_INTERFACE=enp0s8

      Stop Neutron

      systemctl stop neutron-server
      systemctl stop neutron-openvswitch-agent
      systemctl stop neutron-l3-agent.service
      systemctl stop neutron-dhcp-agent.service
      systemctl stop neutron-metadata-agent
      systemctl stop neutron-metering-agent

      Stop Neutron OVS  Processes  You must remove this package otherwise when you restart ovswitch it will get started and trash your  ovsdb

      systemctl stop neutron-openvswitch-agent
      systemctl disable neutron-openvswitch-agent
      yum remove -y openstack-neutron-openvswitch.noarch

      Clean Switches on controller

      systemctl stop openvswitch
      rm -rf /var/log/openvswitch/*
      rm -rf /etc/openvswitch/conf.db
      systemctl start openvswitch
      ovs-vsctl show
      ovs-dpctl del-if ovs-system br-ex
      ovs-dpctl del-if ovs-system br-int
      ovs-dpctl del-if ovs-system br-tun
      ovs-dpctl del-if ovs-system enp0s3
      ovs-dpctl del-if ovs-system vxlan_sys_4789
      ovs-dpctl show
      data_interface=$(facter ipaddress_${OS_DATA_INTERFACE})
      read ovstbl <<< $(ovs-vsctl get Open_vSwitch . _uuid)
      ovs-vsctl set Open_vSwitch $ovstbl other_config:local_ip=${data_interface}
      ovs-vsctl set-manager tcp:${ODL_IP}:6640
      ovs-vsctl list Manager echo
      ovs-vsctl list Open_vSwitch

      Bring br-ex and associated interface up and down

      ifdown br-ex
      ifdown enp0s3
      ifup enp0s3
      ifup br-ex
    2. Checking

      OVS configuration. 

      [user@openstackController ~]$ sudo ovs-vsctl show
      72e6274a-7071-4419-9f86-614e28b74d69
          Manager "tcp:192.168.120.254:6640"
          Bridge br-int
              Controller "tcp:192.168.120.254:6653"
              fail_mode: secure
              Port br-int
                  Interface br-int
                      type: internal
            Bridge br-ex
              Port br-ex
                  Interface br-ex
                      type: internal
              Port "enp0s3"
                  Interface "enp0s3"
          ovs_version: "2.5.0"

       

    3. External Connectivity still works

      ping 8.8.8.8

      At this point you can now check the dlux UI, to ensure both switches show up

      http://192.168.120.254:8181/index.html#/topology

       

  6. Connect Openstack Neutron to ODL

    1. Install ODL Plugin for Neutron
      yum install -y python-networking-odl.noarch
    2. Configure Neutron ml2 to connect to ODL
      crudini --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 mechanism_drivers opendaylight
      crudini --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 type_drivers vxlan,flat cat <<EOF | tee --append /etc/neutron/plugins/ml2/ml2_conf.ini [ml2_odl] password = admin username = admin url = http://${ODL_IP}:8181/controller/nb/v2/neutron EOF
    3. Clean database

      mysql -e "drop database if exists neutron;"
      mysql -e "create database neutron character set utf8;"
      mysql -e "grant all on neutron.* to 'neutron'@'%';" 
      neutron-db-manage --config-file /usr/share/neutron/neutron-dist.conf --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini upgrade head
      
      systemctl start neutron-server
      systemctl start neutron-l3-agent.service
      systemctl start neutron-dhcp-agent.service
      systemctl start neutron-metadata-agent
      systemctl start neutron-metering-agent
      
  7. Virtual Tenant Network Feature

    From OpenDaylight’s console

    1. Install the required features for VTN.

      feature:install odl–vtn-manager-rest

      feature:install odl–vtn-manager-neutron

    2. Test rest API

      VTN Manager provides REST API for virtual network functions.

      Create a virtual tenant network
      curl --user "admin":"admin" -H "Accept: application/json" -H \
      "Content-type: application/json" -X POST \
      http://192.168.120.254:8181/restconf/operations/vtn:update-vtn \
      -d '{"input":{"tenant-name":"vtn1"}}'

      Check if was created

      Get info
      curl --user "admin":"admin" -H "Accept: application/json" -H \
      "Content-type: application/json" -X GET \
      http://192.168.120.254:8181/restconf/operational/vtn:vtns

      more examples [1]

  8. Mininet

    1. Download Mininet.
    2. Launch the Mininet VM with VirtualBox.
      openstack-compute
      #System
      RAM 1024
      Processors 1
      #Network
      NIC 2 Host-Only VirtualBox Host-Only Ethernet Adapter 1 (statically configured 192.168.254.133 eth0)
      NIC 1 Bridged Adapter (Provides internet connectivity)(eth1)
      
    3. Log on to the Mininet VM with the following credentials:
      • user: mininet
      • password: mininet
    4. Interface configuration file 
      vi /etc/network/interfaces

      This configuration match with actual environment

      /etc/network/interfaces
      # The loopback network interface
      auto lo
      iface lo inet loopback
      
      # The primary network interface
      auto eth0
      iface eth0 inet static
      address 192.168.120.133
      netmask 255.255.255.0
      
      auto eth1
      iface eth1 inet dhcp

       

    5. start a virtual network:

      sudo mn –controller=192.168.120.254

      more info [3]

  9. References

    [1] http://docs.opendaylight.org/en/stable-boron/user-guide/virtual-tenant-network-(vtn).html(Using DevStack and different versions of Openstack)

    [2] http://docs.opendaylight.org/en/stable-boron/opendaylight-with-openstack/openstack-with-vtn.html (Old OpenStack version)
    [3] https://wiki.opendaylight.org/view/OpenDaylight_Controller:Installation#Using_Mininet

Attachments:


vtn_example.JPG (image/jpeg)


Capture.JPG (image/jpeg)

Pin It on Pinterest