Archive

Category Archives for "Keeping It Classless"

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.

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 three 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 this 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.

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. 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 of the NETCONF protocol itself, it’s worth briefly jumping ahead to address the 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.

[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.

[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. 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.

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. 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.

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:

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

1 8 9 10 11 12 38