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