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.
Ever since I entered this field, I’ve been interested in this concept of “network programmability”. Forgetting for a second what we’ve been talking about in the past few years since the advent of the “SDN tsunami”, even the ability to automate simple infrastructure tasks at a small scale has grabbed my attention.
It’s important to note something here; the CLI is a wonderful tool. So many vendors take the wrong approach and say the CLI is going away in lieu of pretty GUIs and APIs, as if someone can’t write a really good CLI to consume a really good API.
The networking industry has long speculated that coding skillsets are something that will likely become key in the future. I’m sure this will vary from job to job, but I can tell you that - at least for me - it’s already happened.
I’m not even just talking about knowing syntax like Python, Java, Ruby, etc. I’ve maintained these skillsets sufficiently throughout my network-specific studies that recalling these skills isn’t that hard (admittedly I’m a youngin so it hasn’t been that long).
When using overlays, its important to remember (in most cases) that an entire Ethernet frame is being encapsulated in something else (usually Ethernet + IP + UDP + Overlay Header). This means that the Maximum Transmission Unit for the underlay must be adjusted.
There are a number of posts out there about correct MTU settings for VXLAN. Unfortunately, many of them are either wrong, or unclear as to the math behind these calculations.
I’ve had network configuration tools and protocols on my mind for the last few weeks. Everyone’s got some hot new API or configuration protocol - and on the outside looking in, it’s easy to assume that they’re all just different flavors of the same general concept - network configuration. So are they basically competing standards (VHS vs Betamax, anyone?)? Or is there a method to this madness?
Just to name a few, OVSDB and Netconf are actually established JSON-RPC and XML-RPC (respectively) based standardized formats for accomplishing network configuration on the wire, rather than chase down each vendor’s individual XML/JSON API.
A robust built-in API is not something you traditionally see in a Cisco router or switch. My first experience with anything like this on Cisco was with Unified Computing System. Though it’s a high-level API that interacts only with the UCSM application managing the entire stack, it’s still a robust way to configure policy and resources within UCS.
ACI is recieving the same treatment, and though it’s true that there will be a slew of programmability options built into the APIC controller that is the cornerstone of the ACI fabric that we’ll be hopefully seeing later this year, there are also some very cool options on each individual switch in NXOS or Standalone mode as well.
I was fortunate enough to be given access to a pair of Nexus 9Ks in our lab, and I want to give a brief overview of the initial configuration process, and a brief introduction to some of the features initially presented to us on the switch platform.
Here are a few summarized thoughts:
Calling it a switch is actually kind of funny to me. All ports are routed and shutdown by default, and though you can obviously “no shut” them, and you can convert to a switchport, the switch is clearly built for all-L3 operations.
I was fortunate enough to be given access to a pair of Nexus 9Ks in our lab, and I want to give a brief overview of the initial configuration process, and a brief introduction to some of the features initially presented to us on the switch platform.
Here are a few summarized thoughts:
Calling it a switch is actually kind of funny to me. All ports are routed and shutdown by default, and though you can obviously “no shut” them, and you can convert to a switchport, the switch is clearly built for all-L3 operations.
I was inspired by many little things over the past few days to begin writing a post about this whole “writing code” thing that network engineers the world over have been asking about.
I’ve said before I know that most network engineers already write some kind of code - even if it’s as simple as a snippet of VBA in an Excel spreadsheet to automatically convert a spreadsheet of configuration options into an actual running configuration.
I was fortunate enough to spend this morning (and will be here for quite a while) in Silicon Valley at the first ever OpenDaylight Summit. The initial keynotes were good, but for me the event started last night when I had the opportunity to sit with some of my own industry role models and just talk nerdy, nerdy networking.
Considering how very young this project is (10 months), there are a surprisingly large number of people here - over 550 attendees.
It’s been really interesting to see the industry in an all-out zerg rush to adopt Python as a skill-set. What is it about this seemingly arbitrary selection in the vast array of programming languages available out there? What is so special about Python that it comes up in nearly every conversation about SDN?
This post has been in drafts for some time, and I was motivated to finish it up by this Packet Pushers episode, where Jeremy Schulman and others discuss Python and its impact to networking.
Keeping It Classless