This blog post was initially sent to the subscribers of my SDN and Network Automation mailing list. Subscribe here.

Adam left a thoughtful comment addressing numerous interesting aspects of network design in the era of booming automation hype on my How Should Network Architects Deal with Network Automation blog post. He started with:

A question I keep tasking myself with addressing but never finding the best answer, is how appropriate is it to reform a network environment into a flattened design such as spine-and-leaf, if that reform is with the sole intent and purpose to enable automation?

A few basic facts first:

Daniel Teycheney published an excellent blog post with numerous hints on starting your automation journey including:

• Which programming language should you start with?
• Python or Ansible?
• What about Terraform?
• What resources could you use?

This blog post was initially sent to the subscribers of my SDN and Network Automation mailing list. Subscribe here.

In late 2018 Juniper started aggressively promoting Network Reliability Engineering - the networking variant of concepts of software-driven operations derived from GIFEE SRE concept (because it must make perfect sense to mimic whatever Google is doing, right?).

There’s nothing wrong with promoting network automation, or infrastructure-as-code concepts, and Matt Oswalt and his team did an awesome job with NRE Labs (huge “Thank you!” to whoever is financing them), but is that really all NRE should be?

A network architect friend of mine sent me a series of questions trying to figure out how he should approach network automation, and how deep he should go.

There is so much focus right now on network automation, but it’s difficult for me to know how to apply it, and how it all makes sense from an Architect’s PoV.

A network architect should be the bridge between the customer requirements and the underlying technologies, which (in my opinion) means he has to have a good grasp of both as opposed to fluffy opinions glanced from vendor white papers, or brushed off so-called thought leaders.

One of the attendees in our Building Network Automation Solutions online course sent me this question:

While building an automation tool using Python for CLI provisioning, is it a good idea to use SDK provided by device vendor, or use simple SSH libraries Netmiko/Paramiko and build all features (like rollback-on-failure, or error handling, or bulk provisioning) yourself.

The golden rule of software development should be “don’t reinvent the wheel”… but then maybe you need tracks to navigate in the mud and all you can get are racing slicks, and it might not make sense to try to force-fit them into your use case, so we’re back to “it depends”.

Loved the article from Philip Laplante about environmental antipatterns. I’ve seen plenty of founderitis and shoeless children in my life, but it was worshipping the golden calf that made me LOL:

In any environment where there is poor vision or leadership, it is often convenient to lay one’s hopes on a technology or a methodology about which little is known, thereby providing a hope for some miracle. Since no one really understands the technology, methodology, or practice, it is difficult to dismiss. This is an environmental antipattern because it is based on a collective suspension of disbelief and greed, which couldn’t be sustained by one or a few individuals embracing the ridiculous.

That paragraph totally describes the belief in the magical powers of long-distance vMotion, SDN (I published a whole book debunking its magical powers), building networks like Google does it, intent-based whatever, machine learning…

Helping a friend of mine figure out the details of using Salt in Zero-Touch-Provisioning environments, Zach Moody sent me a description of their process, and was kind enough to allow me to turn it into a blog post.

We follow the same basic ZTP process you would with anything else. Salt drives the parts that interface with the network devices with information from our source-of-truth, NetBox.

David Varnum created a fantastic leaf-and-spine fabric of vEOS switches running with GNS3 and automated with Ansible playbooks.

Not only that - his blog post includes detailed setup instructions, and the corresponding GitHub repository contains all the source code you need to get it up and running.

Andrea Dainese is continuing his journey through open-source NetDevOps land. This time he decided to focus on log management systems, chose Elastic Stack, and wrote an article describing what it is, why a networking engineer should look at it, and what’s the easiest way to start.

Imagine that you just stumbled upon the hammer Thor carelessly dropped, and you’re so proud of your new tool that everything looks like a nail even though it might be a lightbulb or an orange.

That happens to some people when they get the network automation epiphany: all of a sudden CLI and manual configuration should be banned, and everything can be solved by proper incantation of Git and Ansible commands or whatever other workflow you might have set up… even though the particular problem might have nothing to do with what you have just automated.

One of the attendees of my Building Network Automation Solutions online course quickly realized a limitation of Ansible (by far the most popular network automation tool): it stores all the information in random text files. Here’s what he wrote:

I’ve been playing around with Ansible a lot, and I figure that keeping random YAML files lying around to store information about routers and switches is not very uh, scalable. What’s everyone’s favorite way to store all the things?

He’s definitely right (and we spent a whole session in the network automation course discussing that).

Andrea Dainese added REST (Web) API to his Automation for Cisco NetDevOps article. You might love his explanation of the screen scraping methods used by legacy implementations. He was too polite to throw around any names, but I could immediately think of NETCONF or RESTCONF implementation on Cisco IOS.

One of our subscribers sent me this email when trying to use ideas from Ansible for Networking Engineers webinar to build BGP route reflector configuration:

I’m currently discovering Ansible/Jinja2 and trying to create BGP route reflector configuration from Jinja2 template using Ansible playbook. As part of group_vars YAML file, I wish to list all route reflector clients IP address. When I have 50+ neighbors, the YAML file gets quite unreadable and it’s hard to see data model anymore.

Whenever you hit a roadblock like this one, you should start with the bigger picture and maybe redefine the problem.

Over the last weekend I almost got pulled into yet-another CLI-or-automation Twitter spat. The really sad part: I thought we were past that point. After all, I’ve been ranting about that topic for almost seven years… and yet I’m still hearing the same arguments I did in those days.

Just for the giggles I collected a few old blog posts on the topic (not that anyone evangelizing their opinions on Twitter would ever take the time to read them ;).

One of the first hands-on exercises in our Networking in Public Cloud Deployments asks the attendees to automate something. They can choose the cloud provider they want to work with and the automation tool they prefer… but whatever they do has to be automated.

Most solutions include a simple CloudFormation, Azure Resource Manager, or Terraform template with a line or two of README.MD, but Erik Auerswald totally astonished me with a detailed and precise writeup. Enjoy!