Skip to content

Net Automated Posts

Network Automation vs Software Defined Network – Ansible vs Openflow

Published by castroflaviojr on March 16, 2017

At Verizon, we are moving towards automating network configuration and provisioning. To me the goals for this move can be summarized as:

  • Maintenance cost reduction
  • More agile deployment processes

Coming from an OpenFlow SDN background, where changes to the network can be immediate, and looking at the real world, where changes to the network require human approval and human intervention to be deployed resulting in 1-2 weeks time, it’s really hard to tolerate this acceptance for delay with legacy systems.

I’m much interested in identifying where automation of legacy systems offers a real benefit over OpenFlow networks and vice-versa. My experiences tell me the biggest paradigm shift comes from the users. If the network operator is used to the OpenFlow paradigm, and has the software development skills, pretty much anything can be done. On the other side when the network operator comes from a classical Cisco network engineer background, even incremental changes to the network as advocated by network automation gurus can be challenging.

So far, my only experience with network automation is Ansible. A great positive factor for Ansible is its learning curve. Very easy to try. Right now, I’m intrigued with testing of Ansible code, refactoring variables consists of project-wise find and replace, it’s also not yet intuitive to me how Ansible code can be continuously tested and deployed. Quoting Uncle Ben: “with great power comes great responsibility”, Ansible does give you the opportunity to mess up things really well.

That’s where my bias towards OpenFlow comes in: successful OF projects, like ONOS, have been tested for a couple years now and are quite mature for open source projects. AS mentioned in my last article, to me it all comes down to the skill set companies want to cherish, it’s easy to leverage network engineer expertise plus some python scripting capabilities to work on network automation, but I bet you won’t get great code quality out of that.

Another option is to leverage great software developing skills to make sure you do get the code quality, but then what I would advocate for is to get this great software developer and put him to work to develop a real SDN system with real software challenges in place where the opportunity for gain is incredible.

OpenFlow has an inherent disadvantage which is the requirement for extra hardware support. Successful OF deployment have been performed with new gear, or have used successful hybrid deployment strategies, which can be complex. So, if you want to improve current deployments, OpenFlow won’t be your pick.

I’m still skeptical regarding the value of network automation, other than incremental adoption of new technology, in other words, it’s easy to sell.

1 Comment

What’s going on?

Published by castroflaviojr on March 14, 2017

In January, I’ve started working for Verizon as a DevOps Engineer with focus in network engineering. I’ve been working with SDN for about 2 years and my last experience was at the Open Networking Lab, a research lab, pioneer in terms of SDN research, in collaboration with AT&T.

In this article, instead of describing a technology as I usually do in this blog, I’ll try to summarize my thoughts on where this industry is going.

Every day it’s clearer to me that innovation in service providers is driven by two factors: pressure to reduce acquisition and operational costs; increasing pressure to deliver new services fast, which BTW happens in order to generate new sources of revenue.

Most service providers are trying to leverage open hardware from OCP and open source technology in order to achieve those goals. The “open” alternative of solutions is quite cost-effective compared to current legacy solutions; at the same time it offers the opportunity to be at the edge of technology development, that’s to say open technologies fasten innovation cycles significantly. The disaggregation of network devices has played a tremendous role in enabling innovation as well.

There are challenges in order to achieve those goals. Acquisition costs are definitely the most compelling point of open technologies. The delivery of the open source solutions on the other side is where the risk lies. If you are used to open source, you do know that bugs are just part of your life. There’s a 9 in 10 chance that at least one of your critical features won’t be supported natively by available open source solutions.

To couple with that I believe service providers should invest in acquiring diverse talents, or invest in training its own staff.

The truth is change is inevitable, you either hop on the boat and deliver reduced costs or new services or you will be left behind. We’ve started to see evidence why that has been happening with big vendors, I believe this pattern will repeat with providers.

In the next posts, I’ll try to comment on what is going on with vendors or make a follow-up post with my thoughts on costs, risks and benefits of this search for innovation as well.

Leave a Comment

Troubleshooting Shortest Path and Topology Discovery on RYU

Published by castroflaviojr on November 12, 2016

This post is a follow-up to Shortest Path forwarding with Openflow on RYU.

I originally made this code to show how to use SDN to achieve one of the most basic things you can do in a network: shortest path forwarding. In this post I’m answering common question on getting the code to work.

Quickstart:

Assuming you have all the dependencies, you should be able to run a mininet topology using:

sudo mn --topo=tree,4 --controller remote

After starting mininet start RYU using the following command:

bin/ryu-manager --observe-links ryu/app/sp.py

In my computer this is sufficient to discover the topology.

Now, let’s move on to the questions:

1 – Why do I see an empty or incomplete list of links?

Honestly, I’m not super familiar with the RYU topology app, so I don’t know. What works trying to restart Ryu/Mininet in different orders, so stop both applications and try starting Ryu first, if that doesn’t work do the opposite. Repeat until it works.

2 – Does it still work with a loop in the topology?

As far as my tests go it does work with a loop in the topology.

3 – Does it still work with a Spanning Tree?

To test it I start mininet,  setup spanning tree using ovs-vsctl, then I start RYU. After RYU learns the topology it successfully lets the pings go through.

I had to restart RYU a couple times until it learned the topology

4- Why do I see so many packet-ins?

I did not care to handle floodstorms when I coded this, so if your topology has a loop and spanning-tree isn’t set, ARP and other types of flooded packets may be broadcast forever in your network

5 – Can I use another algorithm or set custom weights?

Yes. To set custom weights you just have to figure out how to add that information to the network graph. I’ll try to give an example for this soon.

1 Comment

VMware ESXI Home Lab

Published by castroflaviojr on August 24, 2016

I recently bought an Intel NUC 6th generation in order to build my own VMware ESXi lab. This is my first home lab and the first PC I ever built so I’m excited.

I’m building this for two reasons, one my laptop has a small SSD preventing me from having a bunch of VMs. Second, I’m attempting to get a CCNP certification and I’d like do setup a virtual lab for that.

Bill of materials

I decided to go for the i5 simply because the i7 design wouldn’t allow me to have a HD, while the one I got has space and a connection for a SATA disk.

I also had to buy a keyboard to complete ESXI installation. I bought the NUC with the 256 SSD included on Ebay for 390. The total price was 616 U$ which makes me pretty glad for an I5 machine with plenty of storage and fast SSD if needed.

Assembly

Assembly was straightforward and I used this video as reference.

Installation

Installation is simple and consists of 4 steps:

  • Downloading ESXi iso
  • Creating bootable ESXi usb drive from image using RUFUS
  • Installing and configuring ESXi
  • Installing GNS3 from OVA

I will come back here and put a link to download the ESXi iso, basically vmware can provide you this.

Rufus is also very straightforward and can be downloaded here.

Configuring ESXi could be tricky, but don’t pay attention to details, simply enable ssh and set a static IP address and you should be fine. Next you can download a Vsphere client from the ESXi machine. And you can also use the web browser.

I couldn’t create a VM from the OVA using the web client, so I recommend you to use the vsphere client.

If you need a step-by-step guide. I recommend you to check this youtube guide on how to install ESXI 6.0

In my next blog, I’ll post my experiences with GNS3.

ps: I wish I had installed ESXi with an SD card, just because I think it’s cool. I also wish you could deploy a VM from an OVA in the ESXi storage because that would make it much faster.

I’m also a little pissed because VIRL requires an 200$ license. I haven’t tested it yet but I have the feeling that for learning purposes INE would be much more cost effective, and I doubt VIRL will provide a seamless experience.

Thanks for reading. 🙂

Leave a Comment

Back to blogging

Published by castroflaviojr on August 24, 2016

For contextualization, I just concluded my internship at ONLab one of the pioneer research labs in SDN. Now, I’m looking to get a little closer to the industry and I’m pursuing a CCNP certification.

My study plan is simple. I will build a home LAB using GNS3 and VIRL to practice the contents of both exams and go through the certification guide trying the configurations on the virtual lab. I aim to quickly acquire the CCNP certification in a month since I believe I already have the necessary skills. That gives me one exam every 10 days…

My first step was to build a ESXI lab on a Intel NUC computer. I’ll post the details in a separate blog post.

Leave a Comment

On the path to deployment of SDN technologies

Published by castroflaviojr on January 9, 2016

At On.lab we are moving fast toward real deployment of SDN technologies.

ONOS aims to be a reliable platform to program networks. In order to unleash the full potential of SDN, developers should be able to develop network programs regardless of the hardware used. This means the operating system should provide an abstraction that is just right, in a way that developers can take full advantage of the existing hardware while still being flexible enough to write software once and have it executed on anything.

That’s not an easy task, in order to achieve such a goal several subsystems and layers of abstractions are constantly being developed on ONOS. Today, I will approach the FlowObjective Service.

The FlowObjective service provides an interface between Openflow devices and ONOS. The need for it arose with OpenFlow 1.3 as vendors were allowed to diversify the implementation of multi-table forwarding pipelines in order to be more efficient. The diversification of pipelines is great for performance matters, but it is not so great for developers who have to either choose one specific vendor to write software for or rewrite the software for each hardware device.

The FlowObjective service abstracts that complexity by means of OpenFlow drivers. Using the Flow Objective forwarding elements, you only have to write code for the application once, and someone only has to implement each driver once as well. Still, someone has to be the first to write the drivers.

The Bgp router app and the Segment Routing app currently use the Flow Objective service. In that manner, the OpenFlow drivers were built to support those applications and still may not be able to support some other applications.

We believe that the development of more applications will enrich the current OpenFlow driver, and the results achieved with those drivers will aggregate innate value to new applications. Wouldn’t it be great to write an app that just works in a well known set of hardware?

Well we are working for that!

Leave a Comment

Easiest way to develop on ONOS

Published by castroflaviojr on July 1, 2015

I just started interning at the ON.LAB. We are developing the ONOS controller and other things.

The learning curve for ONOS is a bit of a challenge compared to its python competitors. But it has several features that a carrier-grade controller need and make the effort worth. To me, the two most important things are:

  • The Flow-objective abstraction
  • High-availability mechanisms

I’ll talk more about them in another posts.

Today I’ll show you the easiest way to setup your development environment.

cd ~   
git clone https://gerrit.onosproject.org/onos   
. ~/onos/tools/dev/bash_profile   
onos-setup-ubuntu-devenv   
cd onos
mci

This will take a while to finish… While you are waiting check this another post with a series of very explicative videos about ONOS.

After it done do.

ok clean

That’s it the controller is on.

For detailed information check the ONOS from Scratch tutorial

I hope this was helpful

Leave a Comment

Introduction to ONOS

Published by castroflaviojr on July 1, 2015

I just put together a few screencast from ONOS.

IMO, they are a great way to get you introduced to ONOS. Then, if you think it sounds good, go ahead and look further.

This blog post shows how to setup the ubuntu development environment.

More information can be found in the wiki:
https://wiki.onosproject.org/

I hope this is helpful!

Leave a Comment

List of Graduate Networking Readings

Published by castroflaviojr on January 9, 2015

This is a list I want to keep for myself and share with others. Soon I’ll make a compilation of interesting readings on networking on a different post.

Graduate level networking courses don’t usually have textbook, normally come with long reading lists.

Leave a Comment

Easiest way to install OpenVswitch and Mininet on Ubuntu 12.04

Published by castroflaviojr on January 1, 2015

I’ve been struggling trying to set up the OVS 2.0 with Mininet 2.2 on Ubuntu 12.04.

Apparently the installation script from Mininet is not fully working on Ubuntu 12.04.

What did I do to fix it?

The easiest way to install it is to use the Mininet installation script and then do a small fix.

I did this exactly to install:

sudo apt-get update
sudo apt-get install -y git
git clone git://github.com/mininet/mininet
cd mininet
git checkout -b 2.2.0 2.2.0
util/install.sh -nf
util/install.sh -V 2.3.0

After this you will some weird errors. It should look like this:

Setting up openvswitch-switch (2.3.0-1) ...
 * Inserting openvswitch module
 * /etc/openvswitch/conf.db does not exist
 * Creating empty database /etc/openvswitch/conf.db
 * Starting ovsdb-server
2015-01-02T00:57:50Z|00002|stream_unix|WARN|/usr/local/var/run/openvswitch/db.sock: connection failed (No such file or directory)
2015-01-02T00:57:50Z|00003|reconnect|WARN|unix:/usr/local/var/run/openvswitch/db.sock: connection attempt failed (No such file or directory)
2015-01-02T00:57:51Z|00004|stream_unix|WARN|/usr/local/var/run/openvswitch/db.sock: connection failed (No such file or directory)

You should interrupt the script now with ctrl+C. Next do this:

cd ~/openvswitch/openvswitch-2.3.0/
sudo -s
ovsdb-tool create /usr/local/etc/openvswitch/conf.db vswitchd/vswitch.ovsschema
ovsdb-server -v --remote=punix:/usr/local/var/run/openvswitch/db.sock \
--remote=db:Open_vSwitch,Open_vSwitch,manager_options \
--private-key=db:Open_vSwitch,SSL,private_key \
--certificate=db:Open_vSwitch,SSL,certificate \
--pidfile --detach --log-file
ovs-vsctl --no-wait init
ovs-vswitchd --pidfile --detach
ovs-vsctl show

This partially solves the problem. Let’s go ahead and test it: sudo mn --test pingall.

If you reboot you are going to have the same error. What you can do is to run this everytime you reboot: 

cd ~/openvswitch/openvswitch-2.3.0/
sudo -s
ovsdb-tool convert /usr/local/etc/openvswitch/conf.db vswitchd/vswitch.ovsschema
ovsdb-server -v --remote=punix:/usr/local/var/run/openvswitch/db.sock \
--remote=db:Open_vSwitch,Open_vSwitch,manager_options \
--private-key=db:Open_vSwitch,SSL,private_key \
--certificate=db:Open_vSwitch,SSL,certificate \
--pidfile --detach --log-file
ovs-vsctl --no-wait init
ovs-vswitchd --pidfile --detach
ovs-vsctl show

If you find a best solution or this does not work for you, please report me your issue. I will do my best to help you!

Regards,

Leave a Comment