Matt Oswalt

Author Archives: Matt Oswalt

Moving Soon!

I would like to take the opportunity to let you all know that Keeping It Classless will be moving to a different blogging platform in the near future. For the vast majority of you, this will not be a problem. My intent is to keep as much as possible consistent between moves. However, some of you subscribe to my blog using some WordPress-specific features such as email subscription, as well as following me through the WordPress service itself.

SDN: Integration over Manipulation

I’d like to briefly express a sentiment that I pondered after listening to another one of Ivan’s great podcasts, specifically regarding the true value of a software-defined network approach. The statement was made that ACLs are terrible representations of business policy. This is not inaccurate, but the fact remains that ACLs are currently the de facto representation of business policy on a network device. The “network team” gets a request from an application team to “fix the firewall”, and the policy that is applied to enable that application typically results in an ACL change.

If you’ve ever been in this situation, you likely realize this entire process probably takes some time. Either the application team doesn’t know what exactly needs to be changed, or the network team is too busy, or both. Clearly, there’s a problem. And more often than not, this discussion becomes all about the forwarding architecture.

Oh yes, with old-school ACLs we could only match on a few things – IP subnets, TCP ports, that’s about it. But now with OpenFlow – we can match on EtherType!! We’re saved!!

Don’t be misled – the value of an SDN architecture does not lie in the fact that we can do Continue reading

SDN: Integration over Manipulation

I’d like to briefly express a sentiment that I pondered after listening to another one of Ivan’s great podcasts, specifically regarding the true value of a software-defined network approach. The statement was made that ACLs are terrible representations of business policy. This is not inaccurate, but the fact remains that ACLs are currently the de facto representation of business policy on a network device. The “network team” gets a request from an application team to “fix the firewall”, and the policy that is applied to enable that application typically results in an ACL change.

The Two “Network As Code” Domains

This entry is part 4 of 4 in the series DevOps for Networking

You’ve probably heard the term “network programmability” at this point. You probably also heard it equated to anything to do with code, automation, and networking. This was not always the case.

Network programmability really first hit the big time back in 2011 in the early days of the public OpenFlow discussion. That phrase was almost universally understood to be a data plane concept – because it was describing the revolutionary ideas brought up by abstracting away a forwarding pipeline. “You mean I can program my network device directly?” Network programmability.

I was inspired by a thread that my friend Josh kicked off with this tweet:

An interesting dialogue followed, and I felt compelled to address the problem caused by marketing departments muddying the waters of what would otherwise be a very simple idea.

Now obviously it’s too late to “right the wrong” that resulted from marketing and journalism engines chugging at full steam trying Continue reading

The Two “Network As Code” Domains

You’ve probably heard the term “network programmability” at this point. You probably also heard it equated to anything to do with code, automation, and networking. This was not always the case. Network programmability really first hit the big time back in 2011 in the early days of the public OpenFlow discussion. That phrase was almost universally understood to be a data plane concept - because it was describing the revolutionary ideas brought up by abstracting away a forwarding pipeline.

Three Tips for Technical Blogging

From time to time, I’m asked by new or potential technical bloggers for advice on how to get into writing, or how to overcome some kind of mental reservation that he/she may have.

It’s actually somewhat ironic – I still suffer from many of the same issues that I suffered from back before Keeping It Classless existed.

So, truth be told, I constantly remind myself of the same advice that I give to the bloggers-to-be that ask me for advice. It’s high time that I open the kimono a little bit and hopefully help someone in the process. Here are my top five tips for technical bloggers – whether you’re just getting started, or if you’re already fairly established but maybe hitting some blockage.

Know Why You Do It

Be keenly aware of the motivation(s) that drive your blogging. Write them down. Look at them every day. Keeping these in mind should be your primary source of energy when writing about a technical topic. Unless blogging is your actual job (in which case Continue reading

Three Tips for Technical Blogging

From time to time, I’m asked by new or potential technical bloggers for advice on how to get into writing, or how to overcome some kind of mental reservation that he/she may have. It’s actually somewhat ironic - I still suffer from many of the same issues that I suffered from back before Keeping It Classless existed. I have been having some serious "Newbie Blogger" issues last few weeks. Ironically, I feel compelled to write about them.

[SDN Protocols] Part 5 – NETCONF

This entry is part 6 of 6 in the series SDN Protocols

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. This is in contrast to protocols like OpenFlow  which operate at the control plane.

A key difference between NETCONF and other management protocols (including SNMP) is that NETCONF is built around the idea of a transaction-based configuration model. The NETCONF specification provides for some optional device capabilities aimed at assisting operators with the lifecycle of configuring a network device, such as rolling back a configuration upon an error. Unfortunately, not all network devices support such capabilities, but the protocol was built to make it easier to discover what kind of capabilities a network device can support.

 

Configuration Datastores

Before getting into the semantics Continue reading

[SDN Protocols] Part 5 – NETCONF

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.

Go Go Gadget Networking Lab!

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. However, this is still much better than it was only a few short years ago, when many vendors simply did not offer a virtual machine version of their routers and firewalls.

The other day I was catching up on some Twitter feed, and I noticed a tweet from John Deatherage that caught my eye:

I’ve been using Vagrant for about a year, so I’ve got a bit of experience with it, but mostly with server operating systems. Seeing this tweet reference it’s use in the context of spinning up instances of a Continue reading

Go Go Gadget Networking Lab!

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.

Networks! Now, With More DevOps!

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. These days, the person using this term might just mean “automation”, or be describing a technical position.

As in “We’re looking for an experienced DevOp.” I know, right?

Just today I heard yet another story that illustrated a total misuse of this term, undoubtedly confusing all involved. I say, what’s in a name?

DevOps For Networks

This leads me down the path of considering that the phrase “DevOps for networking” is just as useless. Although I’m sure this was certainly not intended, this phrase implies that there is a special sector of the DevOps movement that is specific to networking. Unless you’re focusing on specific tools (which you shouldn’t be) then this isn’t the case. The underlying business value is precisely the same.

The DevOps culture and tooling that came Continue reading

Networks! Now, With More DevOps!

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.

Free-Form Discussion at CLEUR

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:

For the record, it’s not fair to say that VLAN provisioning takes two weeks, even after change approval. What the server administrator is usually asking for is an entirely new logical network, and there’s much that has to happen in order to do this, the easiest of which is tagging the server port on the ToR. These networks have dependencies, like IP space, firewall and load balancer contexts. Sometimes, routing configurations have to be changed. Is the current provisioning model optimal, or even acceptable? Of course not – that’s why I’m focusing on the newer, more automated methods. However, there’s more than meets the eye here.

I also want Continue reading

Free-Form Discussion at CLEUR

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:

Five Next-Gen Networker Skills

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.

This isn’t meant to say that all of these skills are required to move your career forward; indeed, everyone’s situation is unique. These are just ideas – the way you implement these skillsets in your own life is up to you.

1. Software Skills

Here, I’m not necessarily talking about full-fledged code knowledge. This section isn’t about going and getting a 4 year CS degree. This is mostly about tools, methodologies, and workflows. For some, this will include some kind of interpreted language like Python, but will vary in degree greatly from person to person.

I_am_a_Programmer

To help get more detailed with this point, I’d like to drill down on four very Continue reading

Five Next-Gen Networker Skills

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.

Network Automation @Interop Vegas 2015

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 Schprokits

This is going to be a 3 hour workshop, aiming to be a practical look into network automation. I picked the two tools 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.

I am going to separate this workshop into three main parts:

  1. YAML and Jinja2 – These are text-based specifications that allow Ansible and Schprokits to do what they need to do. I will be making the assumption that attendees have little to no experience with either of these things, so I will spend some time exploring how these work. There’s not enough time in the workshop to be totally exhaustive, so I will only be covering the portions of either specification that are totally relevant for use with Ansible and Schprokits.
  2. Ansible – These days, it’s hard to talk about automation generally without Ansible being Continue reading

Network Automation @Interop Vegas 2015

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.

Remove Duplicates from Pocket List

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.

However, take the following example. Many of the articles we read and put into our Pocket list use some kind of URL options for tracking purposes:

?utm_source=social&utm_medium=twitter&utm_campaign=1215

If you arrive to an article from different sources, but save both to Pocket, Pocket will treat these as different URLs. This means that if you’re bad about staying caught up with your Pocket list (like I am), it can be very easy to save duplicate articles, making the situation even worse.

Fortunately I have a solution. I wrote this python script to automate the removal of duplicates of entries in your pocket list.

Currently this script works by removing ALL text after a question mark (?) or a hash mark (#) in each Continue reading