For those that followed my SDN Protocols series last summer, you might have noticed a missing entry: NETCONF. This protocol has actually existed for some time (the original now-outdated specification was published in 2006), but is appearing more often, especially in discussions pertaining to network automation. The current, updated specification - RFC6241 - covers a fairly large amount of material, so I will attempt to condense here. NETCONF operates at the management layer of the network, and therefore plays a role similar to that of OVSDB.
For the last few years, if you wanted to set up a virtual network environment (for testing purposes, or setting up a lab, etc), it was more or less a manual process of installing software like the CSR 1000v from an ISO or OVA. Rinse and repeat. If you were fortunate enough to work at a company with decent virtual machine automation and infrastructure (and had access to it) then you could in theory make this a little easier, but it’s hardly portable.
TL;DR - buzzwords suck and I want to rant about that. I’ve been doing a lot of posts lately on the skillsets and technologies needed to move networking into the same level of productivity that other disciplines have reached. During this process, I’ve had time to contemplate labels and buzzwords. By itself, I don’t see much value in the term “DevOps”, whether it’s succeeded by the phrase “for networking” or not.
I was fortunate enough to be invited out to Milan, Italy for Cisco Live Europe, and we had a few interesting discussions about a multitude of topics. One of them was more free-form than the others, and focused on defining SDN, what it’s value is, and where that value is most realized. Check out this video recording of the session; it was good to get a few perspectives from non-networkers, since I’m sure their perspective is different from the network administrator’s as it pertains to the ongoing shift in this industry:
With all the flux that is going on in the networking space, it’s hard to figure out what to do next. You may want to add to your skillset, but you’re not sure where to throw your effort. I’d like to focus on five different areas you can focus on, without talking about a specific product - at the end of the day, that’s just implementation details. These areas are going to be increasingly more valuable and will help you be more marketable when added to your existing network knowledge and experience.
In case you are planning on attending Interop in Las Vegas this year, I’d like to let you know about my two sessions, both centered around emerging methodologies and technologies in the networking space. Practical Network Automation With Ansible and Python This is going to be a 3 hour workshop, aiming to be a practical look into network automation. I picked the topics that I have been working with most heavily in this space, and I think this workshop will be a great way to get up to speed with some down-to-earth network automation methodologies.
One problem I’ve noticed with my Pocket list is that my reading list contains quite a few duplicate entires. Sometimes I forget I saved an article and I save it multiple times, or maybe I save it across-sources (like Twitter or Facebook, or just browsing. It looks like Pocket has some protective capabilities around this. If I endlessly spam the button provided to me by my Pocket chromecast extension, Pocket only saves the one copy and all is good.
Popular development methodologies like Continuous Integration are usually accompanied by some kind of automated workflow, where a developer checks in some source code, which kicks off automated review, testing, and deployment jobs. I believe the same workflows can be adopted by network engineers. Let’s say you are the Senior Network Engineer for your entire company, which boasts a huge network. You don’t have time to touch every device, so you have a team of junior-level network engineers that help you out.
When I started this post, the following mental image popped into my head, and I found it an apt description of 2014: Doing the year-end recap post. 2014 was all: pic.twitter.com/aXtC2sjN8l — Matt Oswalt (@Mierdin) December 30, 2014 Oh well…..let’s give this a try anyways. 2014 Recap I’ll list off the goals I set in my post one year ago, and reflect upon how they were pursued in 2014:
In talking with folks about automation, the conversation almost always come around to “speed, speed, speed”. It’s easy to see why this is the first benefit that pops into mind - we’ve all spent gratuitous amounts of time doing repetitive, time-consuming tasks. It’s obvious why the prospect of automating these tasks and getting the time back is such an attractive one, even though most of us that have tried know that this is an absolute reality:
Since this post was written, the company behind Schprokits has unfortunately gone out of business. Though this approach is no longer something that you can read and follow along with, I have left this post active as an academic exercise in network automation. I hope it is useful in some way. I recorded an in-depth explanation of the process (~42 mins), and [it can be found here](), as well as at the end of this post.
I mentioned in a previous post that version control is an important component of efficiently managing network infrastructure. I’m going to take is a step further than what most are doing with RANCID, which is traditionally used at the end of a workflow (gathering running config diffs) and show you what it’s like to start with version controlled configuration artifacts, specifically using Ansible’s “template” module. I’m not going to discuss how you get the resulting configurations actually running on your network devices - that is best saved for another post.
I am in the Bay Area this week, working on some network automation stuff, and I was fortunate to be able to stop by and say hello to the Storage Field Day 6 folks over drinks. I was told by several impressed delegates about a talk by Andy Warfield of Coho Data, where he described how they used OpenFlow to steer storage traffic intelligently to and from various nodes in a distributed storage array.
I’ve mentioned in past articles about my belief that networking - both as a discipline and a technology - needs to be more consumable to other disciplines. But what does this mean? I was reminded of a few great examples today that I think are relevant to this idea, and might help explain my point a little more clearly. Mass Production Meets Customization The assembly line revolutionized the auto industry. Prior to this, vehicle production was very slow, and extremely costly.
I’d like to write about five things that you as a hardcore, operations-focused network engineer can do to evolve your skillsets, and take advantage of some of the methodologies that have for so long given huge benefits to the software development community. I won’t be showing you how to write code - this is less about programming, and more about the tools that software developers use every day to work more efficiently.
I’ve been focusing lately on shortening the gap between traditional automation teams and network engineering. This week I was fortunate enough to attend the DevOps 4 Networks event, and though I’d like to save most of my thoughts for a post dedicated to the event, I will say I was super pleased to spend the time with the legends of this industry. There are a lot of bright people looking at this space right now, and I am really enjoying the community that is emerging.
If you weren’t paying attention, it was easy to miss. NX-API, Cisco’s new JSON/XML switch API is now shipping as version 1.0. NX-API originated on the Nexus 9000 platform created by the Insieme group, and I’ve explored this in detail before. In review, NX-API is a new, programmatic method of interacting with a Cisco Nexus switch. In many ways, Cisco is playing catch-up here, since this interface is really just a wrapper for the CLI (admittedly with some convenient output parsing), and most of their competitors have had similar interfaces for a while.
My first experience with ThousandEyes was a year ago at Network Field Day 6, where they were kind enough to give us a tour of their office, and introduce us to their products. I’ve been fairly distracted since then, but kept an eye on what other delegates like Bob McCouch were doing with the product since that demo. A year later, at Network Field Day 8, they presented again. If you’ve never heard of ThousandEyes, and/or would like an overview, watch Mohit’s (CEO) NFD8 introduction:
In this post, we will be discussing a relatively new protocol to the SDN scene - OpFlex. This protocol was largely championed by Cisco, but there are a few other vendors that have announced planned support for this protocol. I write this post because - like OVSDB - there tends to be a lot of confusion and false information about this protocol, so my goal in this post is to provide some illustrations that (hopefully) set the record straight, with respect to both OpFlex’s operation, and it’s intended role.
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”.