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!

One of the attendees of our Building Network Automation Solutions online course asked an interesting question in the course Slack team:

Has anyone wrote a playbook for putting a circuit into maintenance mode — i.e. adjusting metrics to drain traffic away from a circuit that is going to be taken down for maintenance?

As always, you have to figure out what you want to do before you can start automating stuff.

As the last part of his network automation journey, Anne Baretta described the automation tools he used.

Notes

• We covered numerous automation tools (including the ones Anne used) in our Building Network Automation Solutions online course;
• For an overview of automation tools, watch the Network Automation Tools webinar.

Zero-Touch Provisioning (ZTP) is a solved problem if you believe the networking vendors… and yet numerous network automation projects involve at least some ZTP functionality. It seems that smart organizations investing in premium people (instead of premium vendors) prefer the Unix way of solving problems: take a number of small versatile tools, and put them together to build a solution that fits your requirements.

Anne Baretta did exactly that and combined Oxidized, FreeZTP, Ansible and custom web UI to build a ZTP solution that addresses the needs of his organization.

Notes

• Patrick Ogenstad covered numerous ZTP details in our network automation course.

Anne Baretta got pretty far in his automation story: after starting with configuration templates and storing network inventory into a database, he tackled the web UI. What’s next? How about a few auto-generated network diagrams?

Notes

• We covered the magic behind network diagrams in our network automation course.
• For whatever reason, I see numerous networking engineers focusing on generating useful network diagrams. Wasn’t that problem solved ages ago with miraculous single-pane-of-glass network management software?