Opendaylight Helium release

Opendaylight Helium is the second release after Hydrogen and it was released late September 2014. Earlier, I was using Opendaylight Hydrogen release and recently, I tried out Opendaylight Helium release. In this blog, I have shared some of my experiences with Helium.

Following are some important additions to Helium compared to Hydrogen. For more details, please refer Opendaylight webpage.

  • Hardening of the controller, Clustering capability, Security options like AAA.
  • Better integration with Openstack which has features like Group based policy, service function chaining.
  • Use of Apache karaf container format so that individual features can be installed.
  • Better Dlux gui.

Continue reading Opendaylight Helium release →

How to define SDN?

Someone recently asked me what SDN is? Even though I have written multiple blogs related to SDN, I was not able to give a crisp answer which I was satisfied with. Since its fashionable to associate any new development in Networking to SDN, the definition becomes complex. In this blog, I will mention the different definitions I found for SDN in the Internet along with my definition in the end.

From Wikipedia:

Approach to computer networking that allows network administrators to manage network services through abstraction of lower-level functionality. This is done by decoupling the system that makes decisions about where traffic is sent (the control plane) from the underlying systems that forward traffic to the selected destination (the data plane). 

Continue reading How to define SDN? →

Mininet Internals and Network Namespaces

Mininet is a very powerful virtual network emulation system that’s generally used in SDN development environments. With Mininet, a complex network with hundreds of switches can be simulated in a laptop and this opens up testing real-life network usecases. I have covered Mininet usage in 1 of my earlier blogs on tools used with Opendaylight. I have always wondered about how Mininet works under the hood. Recently, i went through a Stanford webinar which shed details on the Mininet internals. In this blog, I will cover Mininet internals along with a sample network that I tried out. 1 of the key concepts used in Mininet is Network namespaces which is also the basis for Linux containers. I will also cover briefly about Network namespaces in this blog.

Network Namespaces:

Network namespaces allows for creation of virtual networking domain with its own set of interfaces, ip addresses, routing table etc. This is similar to VRF in Cisco terminology. Network namespaces connect to outside world using virtual ethernet links. Virtual ethernet link is a wire with 2 endpoints, typically 1 end point is located in local namespace and another in global namespace. Network namespaces are also used in Docker and Openstack Neutron. With Openstack neutron, Network namespaces allows for isolating tenants as well as to have overlapping IP addresses.

Mininet internals:

Mininet uses the following Linux concepts:

  • Network namespaces are used to implement hosts or endpoints. Each host will have its own set of interfaces, IP and routing table.
  • Openvswitch or Linux switch is used to implement switches. Openvswitch is used by default. Openflow is used to program data path and ovsdb is used for setting up configuration on Openvswitch.
  • Controller could be any Openflow controller like Opendaylight, Floodlight etc.
  • For controlling link characteristics like bandwidth, latency, Linux tc tool is used.
  • For limiting CPU usage of individual namespaces, Linux cpu groups is used.
  • Mininet uses a Python wrapper on top of the above tools as well as other Linux tools like perf to present a high level abstraction.

Hands-on:

To try out the different concepts above, I have the following environment:

  • Ubuntu 12.04
  • Opendaylight controller helium release.
  • Openvswitch 2.1.3
  • Mininet 2.1.0

Continue reading Mininet Internals and Network Namespaces →

Recent Networking Opensource projects – OPNFV, Openconfig, ONOS

I came across few recent Opensource projects which I found them to be interesting. In this blog, I will cover some details on OPNFV, Openconfig, ONOS. There is no relation between the 3 projects, the common thing is all the 3 projects are focussed on Networking and Cloud and all are relatively new.

OPNFV

OPNFV is an Opensource project under Linux foundation. The goal is to create a Opensource reference platform for developing NFV applications. In 1 of my earlier blogs on NFV, I covered overview of NFV and the ETSI NFV model. The goal of the OPNFV project is to create a reference implementation using the model proposed by ETSI. OPNFV’s plan is to leverage the work done in other Opensource projects like Openstack, Opendaylight, Openvswitch, KVM, Linux kernel, DPDK. Even though OPNFV can work with other Cloud OS and SDN controllers, the goal for the first release is to use the most popular Cloud OS, SDN controller and hypervisor mentioned above. Following picture from OPNFV illustrates the blocks that OPNFV will focus on from ETSI NFV reference model.

Continue reading Recent Networking Opensource projects – OPNFV, Openconfig, ONOS →

Vagrant – Overview and Opendaylight Vagrant Image

Recently, I came across this tool called Vagrant that eases the creation and sharing of VM work environment. I played with it and found it very useful. Vagrant integrates with VM hosting providers like Virtualbox, Vmware and AWS. Different devops tools like Chef, Puppet, Ansible are integrated with Vagrant. In this blog, I will cover high level overview and use cases of Vagrant, Vagrant workflow and an application that I created using Vagrant. In the application, I have created a Vagrant Opendaylight(ODL) box using Ubuntu 12.04 as baseline. I will describe the steps that I followed to create the Vagrant ODL box and how it can be used.

Vagrant Use cases:

  • Easier to share VM and this allows for better collaboration. Rather than sharing large OVA files, Vagrant configuration files can be shared.
  • Same VM base can be used for different applications. For example, Vagrant box can be a Ubuntu OS which contains the OS alone. Vagrant box could also be Ubuntu OS plus LAMP stack, this base box can be used for developers wanting to develop applications on top of LAMP stack.
  • VagrantCloud can be used to find base VMs for a lot of different use cases. The same site can be used to host new base VMs. Free VagrantCloud account does not allow hosting.
  • Vagrant integrates well with devops tools like Chef, Puppet and Ansible and this makes the recipe installation easier.

Workflow:

Continue reading Vagrant – Overview and Opendaylight Vagrant Image →

Openstack distribution

In the last few months, following were some acquisitions that happened: Cisco acquiring Metacloud, EMC acquiring Cloudscaling, HP acquiring Eucalyptus. Metacloud and Cloudscaling have Openstack based distributions, Eucalyptus has a cloud OS similar to Openstack. This set of acquisitions prompted me to look little closely at Openstack distributions and following blog is a result of this.

I see a close parallel between Linux and Openstack in terms of how they are evolving. Unix started off with various flavors like FreeBSD, Solaris, Linux etc. Linux is the dominant Unix version used now. There are different companies like Redhat, Ubuntu selling and supporting Linux distributions. There are currently different Cloud OS like Cloudstack, Eucalyptus, Openstack etc. Openstack is emerging as a major Cloud OS. There are different companies selling Openstack distributions currently.

Continue reading Openstack distribution →

Storage Primer

Storage is a very critical component in the current IT domain. Choosing the right Storage platform and software is a critical part of a good Data center whether it is internal or external cloud. Even though I understood some Storage basics, I never ventured deep to understand the different storage technologies available. I tried to brush up my knowledge by doing some reading recently and I have tried to capture some of my reading in this blog.

Storage device(HDD vs RAID vs SSD)

HDD – Hard disk drive consists of a spindle with disks.

RAID(Redundant array of Independent disks) – Combines multiple HDDs to provide more reliability, throughput and capacity.

SSD – Solid state drive is a memory chip and it has no moving parts.

Storage device performance is measured in terms of throughput(data transfer rate), latency(time it takes to start a IO task) and IOPS(IO operations per second).  SSD scores better over HDD on all the performance parameters. RAID provides comparable throughput and IOPS as SSD, but SSD provides better latency. The only disadvantage of SSD is the much higher cost.

Continue reading Storage Primer →

Ansible for Network Automation – Part 2

This blog is part of my series on Devops for Networking. In the previous blog, I covered basics of Ansible and how to get started with it. In this blog, I will cover a sample application that I wrote with Ansible. This Ansible application builds on UCS sdk utility that I covered in a previous blog. The UCS python utility displays the inventory of UCS system. I have made that utility as an Ansible module and extended the application to display the inventory of a list of UCS systems that are defined in the host list. This project is more to illustrate the usecase for Ansible.

The source code for the project can be found here. There are 3 files listed here:

getucs.yml - YAML file that defines the playbook
getucsinfo - New module that is defined. This file needs to be in "usr/share/ansible"
getUcsProp.py - getucsinfo module uses functions in this library. This file needs to be in PYTHONPATH.The library provides utility functions to get UCS inventory.

Continue reading Ansible for Network Automation – Part 2 →

Ansible for Network automation – Part 1

This blog is part of my series on Devops for Networking. Ansible is a very popular Devops tool and serves similar purposes as Puppet, Chef etc. Ansible has the unique feature that there is no need to install agent on the device side and this makes it very popular for Network device configuration since Network devices are still predominantly a closed system which does not allow agent installation in the device. In this blog, I will cover how to get started with Ansible and in the next blog, I will cover a sample application that I have written.

Ansible basics:

Ansible modules can be run locally or remotely. With the local approach, the module runs locally using apis to talk to remote devices. In remote scenario ,modules are pushed to remote devices, executed as python script and results are returned. Even though there is no need to install remote agent, remote device should allow execution of Python script. Ansible can either be run in command-line for simple tasks or can be executed using a playbook.

Continue reading Ansible for Network automation – Part 1 →

Network device configuration using templates with Jinja2 and YAML

This blog is part of my series on Devops for Networking. Typically, Network device configurations for CLI based systems are stored as text files and when its necessary to change parameters like gateway address, vlan, ntp server etc, the script is manually edited and then reapplied to the device. This process is manual and prone to errors. In this blog, I will cover how to automate generation of configuration scripts using Jinja2 and YAML. I will also provide an sample application that I created. For more details, please refer to the references section below.

Tools overview:

Jinja2:

Jinja2 is a Python library for creating configuration based on templates. Jinja2 defines a templating language with which templates are created. The templates can be as simple as a hostname variable that needs to be updated or it can be an array of vlans that needs to be populated. Jinja2 also provides complex templates to cover different scenarios. Following is a very simple example of a template which says ntp_server is a variable that needs to be updated dynamically. We will see later how we can feed in the dynamic values to update.

ntp server {{ ntp_server }}

Continue reading Network device configuration using templates with Jinja2 and YAML →