Category: automation

One of my readers wondered whether it makes sense to attend my Building Network Automation Solution course even if they plan to deploy a $Vendor platform.

It depends, this time on how fast and how far you want to proceed with network automation.

One of the challenges traditional networking engineers face when starting their network automation journey is the “build or buy” decision: should I use a plethora of small open-source or commercial tools and components and build my own solution, or should I buy a humongous platform from a reassuringly-expensive $vendor.

Most of us were used to buying platforms ranging from CiscoWorks to HP OpenView (oops, Business Technology Optimization Software) or now Cisco’s NSO, so it’s natural that we’re trying to map this confusing new world into old patterns, leading to interesting discussions like the one I had during one of my workshops:

In June 2016 I got an interesting idea: let’s create a webinar series with numerous guest speakers that would describe several widely-used network automation use cases.

It took me almost half a year to get there, but finally the first session is scheduled for November 22nd.

Got this comment on my Network Automation RFP Requirements blog post:

Looks like you are paid shill for Brocade based on the quote earlier in your blog "The Pass/Fail information included below was collected to the best of my knowledge with extensive help from Jason Edelman, Nick Buraglio, David Barroso and several Brocade engineers (THANK YOU!)."

Hooray, one more accolade to add to my list of accomplishments. And now for a few more details:

We did a podcast describing NAPALM, an open-source multi-vendor abstraction library, a while ago, and as the project made significant progress in the meantime, it was time for a short update.

NAPALM started as a library that abstracted the intricacies of network device configuration management. Initially it supported configuration replace and merge; in the meantime, they added support for diffs and rollbacks

One of my readers left this comment (slightly rephrased) on my Network Automation RFP Requirements blog post:

Given that we look up to our *nix pioneers as standard bearers for system automation, why do we demand an API from network devices? The API requirement would make sense if the vendor OS is a closed system. If an open system vendor creates APIs for applications running on their system (say for BGP configs) - kudos to them, but I no longer think that should be mandated.

He’s right - API is not a mandatory prerequisite for reliable network automation.

After finishing the network automation part of a recent SDN workshop I told the attendees “Vote with your wallet. If your current vendor doesn’t support the network automation functionality you need, move on.”

Not surprisingly, the next question was “And what shall we ask for?” Here’s a short list of ideas, please add yours in comments.

My friend Matthias Luft sent me an interesting tweet a while ago:

@ioshints What’s your take on firewall rule sets & IP addresses vs. hostnames?

— Matthias Luft (@uchi_mata) August 16, 2016

All I could say in 160 characters was “it depends”. Here’s a longer answer.

One of the attendees of my Building Next-Generation Data Center course asked this interesting question after listening to my description of differences between Chet/Puppet and Ansible:

For Zero-Touch Provisioning to work, an agent gets installed on the box as a boot up process that would contact the master indicating the box is up and install necessary configuration. How does this work with agent-less approach such as Ansible?

Here’s the first glitch: many network devices don’t ship with Puppet or Chef agent; you have to install it during the provisioning process.

In March 2016 my friend Matt Oswalt announced a distributed network testing framework that he used for validation in his network automation / continuous integration projects. Initial tests included ping and DNS probes, and he added HTTP testing in May 2016.

The project continues to grow (and already got its own Github and documentation page) and Matt was kind enough to share the news and future plans in Episode 63 of Software Gone Wild.

To ask questions about the project, join the Todd channel on networktocode Slack team (self-registration at slack.networktocode.com)

When people started talking about OpenConfig YANG data models, my first thought (being a grumpy old XML/XSLT developer) was “that should be really easy to implement for someone with XML-based software and built-in XSLT support” (read: Junos with SLAX).

Here’s how my simplistic implementation would look like:

Matt Oswalt made two great points while tweeting about my Automation Gone Wild blog post:

• Automation should be a strategy. You need management buy-in;
• You should have at least one person with strong software development experience in your automation team.

However, life is not always rosy, so @stupidengineer asked:

Marcel Reuter sent me a few questions about my upcoming Network Automation workshop. You might find them interesting, so here they are:

We have a lab with virtual IOS-XE, IOS-XR and Junos (vMX) router. I would like to learn how to provisioning the Lab router.

Covered in the workshop. I’m focusing on vIOS (which is pretty close to IOS Classic and IOS-XE) and Nexus OS because that’s what I can get up and running quickly in VIRL.

My “this is why you need automation” blog post triggered numerous comments and tweets. I loved this one:

What if the mistake was embedded into the automation process/tool (designed by humans) in the first place? Now you have a video series titled "Automation Gone Wild".

I guess this tweet is a priceless answer to that question:

I spent the last week creating numerous scenarios using Ansible networking modules for my upcoming Network Automation workshop. The scenarios use Cisco IOS and Nexus OS modules as I used VIRL for network simulation, but you could easily adapt them to other networking devices.

All the scenarios I’m covering in the workshop are available in my Github repository; to get the them explained you’ll have to attend the workshop. Enjoy!