Today, we will be discussing the Open vSwitch Database Management Protocol, commonly (and herein) referred to as OVSDB. This is a network configuration protocol that has been the subject of a lot of conversations pertaining to SDN. My goal in this post is to present the facts about OVSDB as they stand. If you want to know what OVSDB does, as well as does NOT do, read on.
I would like to call out a very important section, titled “OVSDB Myths”.
It’s not often I get to write about concepts rooted in database technology, but I’d like to illuminate a situation that software developers deal with quite often, and one that those entering this space from the network infrastructure side may want to consider.
Software will often communicate with other software using APIs - an interface built so that otherwise independent software processes can send and receive data between each other, or with other systems.
In the last post, I introduced you to the concept of control plane abstraction, specifically the OpenFlow implementation. I talked about how OpenFlow allows us to specify the flows that we want to be programmed into the forwarding plane, from outside the forwarding device itself. We can also match on fields we typically don’t have access to in traditional networking, since current hardware is optimized for destination-based forwarding.
In this post, I plan to cover quite a few bases.
A few weeks ago, I was working with the NX-API currently found on Cisco’s Nexus 9000 series switches, and ran into some peculiar behavior.
NX-API returns all information in terms of Tables and Rows. For a specific example, let’s look at what NX-API returns when I ask the switch for running OSPF processes:
There’s actually a lot more information in this snippet that pertains to the OSPF process itself, but I have omitted it for brevity.
Let’s get into our first topic. And what better place to start than with the protocol that arguably started the SDN madness that we’re experiencing today - OpenFlow! I got fairly carried away with writing about this protocol, and understandably so - this is a complicated topic.
That’s why I’ve split this post (which is already part of a series - very meta, much deep) into two parts. This post - Part 1 - will address OpenFlow’s mid to high-level concepts, exploring what it does, why/how the idea of control plane abstraction may be useful, and some details on how hardware interaction works.
The networking industry in the last few years has seen an explosion in buzzwords, slide decks, new technologies, and SDN product announcements. The honest truth is that the networking industry is still in a great state of flux, as we collectively discover what SDN means to us.
There’s a lot of new terms floating around, and what makes things even harder to keep up with, the marketing engines are alive and well - muddying the waters, and making it nearly impossible to get technical facts straight.
I was pleased as punch to wake up the other day and read Marten Terpstra’s blog post on getting over the fear of using automation to make changes on our network infrastructure. He illuminated a popular excuse that I’ve heard myself on multiple occasions - that automation is great for things like threshold alarms, or pointing out the percieved root cause of a problem, but not actually fixing the problem.
I’ve mentioned before the need for networks to be addressed in a very programmatic way. Very often, I’ve found the discussion is actually a lot less about “programming language” details and more about getting rid of the methodology of addressing the network as a mere “collection of boxes” (see “Box Mentality”).
Instead, we have the ability to address the network as any developer would address the distributed components of an application.
With all of the activity going on in the networking industry right now, and all of the new terminology (as well as old re-invented terminology), it’s quite easy to get messages mixed up. After all, there’s no centralized dictionary for all of this stuff. I’d like to address something that has bugged me for a while.
I’ve now heard from quite a few folks that SDN to them means the ability to automate network tasks.
Glue Networks had a presence at the last ONUG, where Tom Hollingworth was able to get an overview from Glue’s founder, Jeff Gray:
As you can see, Glue’s product targets the WAN, and specifically addresses the difficult provisioning tasks that most shops do manually. These include but are not limited to:
Provisioning (and deprovisioning) of QoS resources for various applications like SAP and Lync based off of need and time of day.
This post is the “text” version of a talk I gave at Cisco Live US 2014 titled “SDN: People, Process, and Evolution”. While there is certainly some technical details involved here, this topic is really more of a philosophical one, and it is very near and dear to my heart as I talk with more folks about how networking is going to evolve in the years to come.
The Problem with Networking Most of my readers would consider themselves network engineers - folks that live and breathe networking and everything that’s required to build them.
I recently ran into a slew of errors when using Pylint - a sort of “quality checker” for your Python code. If you haven’t used it yourself, I highly recommend you check it out - it WILL make you a better Python coder.(Thanks to Matt Stone for introducing me!)
This particular error is common if you forget to append a newline character to the end of your python script, but I was getting one for every single line of code in my program.
Last week I attended the Open Networking User Group conference. My main reason for attending was to participate in three roundtable discussions put on by Tech Field Day. These sessions were recorded, and I’ll be following up with specific thoughts on each session in later blog posts.
These round-tables only occupied a portion of the two-day conference, so I spent the remainder of the time speaking with some of the vendors and sitting in a few of the sessions.
Today I’m off to NYC for Open Networking User Group 2014. Tech Field Day was at the last ONUG back in October, 2013 and they were kind enough to invite me out to this one. Here’s a quick intro video of ONUG for those that aren’t aware of it - Tom Hollingsworth interviews ONUG creator Nick Lippis:
We have a good group of vendors lined up for similar round-table discussions.
I’ve talked with all kinds of IT professionals in the past year or so about building an organization of various IT disciplines that are truly service-oriented towards each other and to the other parts of the business. While I will never claim to be an expert in business development and will always claim allegiance to the nerdy technical bits, it’s easy to see the value in such an organizational model, and very interesting to explore the changes that technical people can make to push for such an approach.
My previous post on automatically generating a SAN configuration explored what is possible when using a templating language like Jinja2, and a little Python work.
I’d like to take this a step further. There are two areas I did not address in that post.
The typical SAN or UCS administrator likely knows little if any Python. I’d like to produce a tool that is easy enough to consume, and requires no programming knowledge to use.
I’ve spent a lot of time lately considering skillsets, and how people go about learning new things. Many aspects of the IT industry are starting to overlap with each other (the idea of DevOps being just one manifestation) and it’s incredibly interesting to see how individual professionals are incorporating new knowledge into their repertoire. I did a little contemplation on this over the weekend and I’d like to share some observations I’ve made.
One of my least favorite things to do in my day job is create or maintain a zoning configuration on a fibre channel switch, such as a Cisco Nexus or MDS. It’s tedious, very error prone, and annoying when changes need to be made. I wrote earlier in the week on the value of using a templating language like Jinja to define the structure of a switch configuration, but dynamic enough to accept all kinds of input from some higher-level intelligence elsewhere.
Networking Field Day 7 was the third Tech Field Day event I attended as a delegate, and as expected, it was a blast. Its always good to be reunited with old friends, especially in this kind of environment, where constant technical discussions are…….well, they’re just going to happen. There were certainly some common undertones in every single presentation. One big example is OpenDaylight - nearly every vendor had at least something to say about it.
We’ve all been there at some point in our careers - especially those that work for VARs. You’re presented with a bunch of new gear that needs to be configured and deployed, and you’re tasked with making the magic happen.
It was great to wake up yesterday to read Jason Edelman’s post on Ansible for networking - taking an approach to network automation that’s built upon existing, proven tools just makes sense, especially for the use case of initial configuration, but hopefully beyond.
Matt Oswalt