Category: automation

Carl Montanari recently published an interesting blog post on the punditry of network APIs (including hilarious fact that “SNMP is also an API”), and as someone sent me a link to that post he commented “it reminds me of a few blog posts you wrote a while ago”.

Speaking of those blog posts… last July I was getting bored and put together a list of interesting blog posts I published on that topic. Enjoy!

When I published the Optimize Network Data Models series a long while ago, someone made an interesting comment along the lines of “You should use JSON Schema to validate the data model.”

It took me ages to gather the willpower to tame that particular beast, but I finally got there. In the next installment of the Data Models saga I described how you can use JSON Schema to validate Ansible inventory data and your own YAML- or JSON-based data structures.

To learn more about data validation, error handling, unit- and system testing, and CI/CD pipelines in network automation, join our automation course.

In early 2018 I described how Hans Verkerk implemented zero-touch provisioning with Ansible. Recently he rewrote his scripts as a Python-only solution using Nornir. Enjoy!

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

Most automation projects are gradual improvements of existing manual processes, but every now and then the stars align and you get a perfect storm, like what Adrian Giacommetti encountered during one of his automation projects.

The customer had well-defined security policies implemented in Cisco ACI environment with tenants, endpoint groups, and contracts. They wanted to recreate those tenants in a public cloud, but it took way too long as the only migration tool they had was an engineer chasing GUI screens on both platforms.

Anyone using text files as a poor man’s database eventually stumbles upon the challenge left as a comment in Automating Cisco ACI Environments blog post:

The biggest challenge we face is variable preparation and peer review process before committing variables to Git. I’d be particularly interested on how you overcome this challenge?

We spent hours describing potential solutions in Validation, Error Handling and Unit Tests part of Building Network Automation Solutions online course, but if you never built a network automation solution using Ansible YAML files as source-of-truth the above sentence might sound a lot like Latin, so let’s make it today’s task to define the problem.

I was telling you there’s no need to become a programmer over six years ago, but of course nobody ever listens to grumpy old engineers… which didn’t stop Ethan Banks from writing another excellent advice on the same theme: Don’t Become A Developer, But Use Their Tools.

Got this question from one of my long-time readers:

I am looking for commercial SDN solutions that can be deployed on top of brownfield networks built with traditional technologies (VPC/MLAG, STP, HSRP) on lower-cost networking gear, where a single API call could create a network-wide VLAN, or apply that VLAN to a set of ports. Gluware is one product aimed at this market. Are there others?

The two other solutions that come to mind are Apstra AOS and Cisco NSO. However, you probably won’t find a simple solution that would do what you want to do without heavy customization as every network tends to be a unique snowflake. 

In mid-September, Carl Buchmann, Fred Hsu, and Thomas Grimonet had an excellent presentation describing Arista’s Ansible roles and collections. They focused on two collections: CloudVision integration, and Arista Validated Designs. All the videos from that presentation are available with free ipSpace.net subscription.

Want to know even more about Ansible and network automation? Join our 2-day automation event featuring network automation experts from around the globe talking about their production-grade automation solutions or tools they created, and get immediate access to automation course materials and reviewed hands-on exercises.

Contrary to what some evangelists would love you to believe, getting fluent in network automation is a bit harder than watching 3-minute videos and cobbling playbooks together with google-and-paste… but then nothing really worth doing is ever easy, or everyone else would be doing it already.

Here’s a typical comment from a Building Network Automation Solutions attendee:

I’m loving the class. I feel more confused than I ever have in my 23 year career… but I can already see the difference in my perspective shift in all aspects of my work.

In March I explained why it’s unrealistic to expect to use machine learning to solve unknown problems in today’s snowflake networks… but are there other problems that could be solved?

Here’s an idea Paul Greenberg pointed me to: machine learning on public DNS data. Let’s see whether it might make sense:

If you’re like me, you’re probably sick-and-tired of Python versions, environments… Every time I update Python on my MacBook Pro with Homebrew, I lose all packages I installed for the previous version of Python (because I’m installing them system-wide and they’re stored in version-specific directory).

Jon Langemak found a potential solution to this problem: PyEnv. My first reaction was: Great, just what I need… but as he described how it really works, I realized that it’s always possible to add another layer of indirection. RFC1925 strikes again.

Brett Lykins published an excellent description of what an automation Minimum Viable Product could be.

Not surprisingly, he’s almost perfectly in sync with what we’ve been telling networking engineers in ipSpace.net Network Automation online course:

• Start small
• Go for quick wins
• Do read-only stuff before modifying device configurations
• Test, test, test…

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 (now defunct, huge “Thank you!” to whoever was financing them), but is that really all NRE should be?