Category: Automation

One of my readers sent me this question:

Other than using Excel (and of course an automation tool) any suggestions for a tool to create device config for some 200 customer VRFs from a standard template?

You need three things to get the job done:

Not long after I published the let’s drop some configuration commands rant I got a very nice email from Nicolas Delecroix, Technical Marketing Engineer in Cisco INSBU, effectively saying “Would you have time for a short WebEx call to discuss the root cause of the problem and what we did to fix it?”

Of course I agreed and here’s what they told me:

The awesome Troopers crew published conference videos, including my Securing Network Automation presentation (more, including slide deck).

Ansible, Puppet, Chef, Git, GitLab… the list of tools you can supposedly use to automate your network is endless, and there’s a new kid on the block every few months.

In Episode 77 of Software Gone Wild we explored Salt, its internal architecture, and how you can use it with Mircea Ulinic, a happy Salt user/contributor working for Cloudflare, and Seth House, developer @ SaltStack, the company behind Salt.

One of my readers considered joining the Building Network Automation Solutions course but wasn’t sure whether it would help him solve the challenges he’s facing in his network.

Fortunately, his challenges aren’t that hard to solve.

Most network automation presentations you can find on the Internet focus on configuration management, either to provision new boxes, or to provision new services, so it’s easy to assume that network automation is really a fancy new term for consistent device configuration management.

However, as I explained in the Network Automation 101 webinar, there’s so much more you can do and today I’d like to share a real-life example from Jaakko Rautanen, an alumni of my Building Network Automation Solutions online course.

One of my readers sent me a link to CCO documentation containing (at that time) this gem:

Beginning with Cisco NX-OS Release 7.0(3)I2(1), Cisco Nexus 9000 Series switches handle the CLI configuration actions in a different way than before the introduction of NX-API and DME. The NX-API and DME architecture introduces a delay in the communication between Cisco Nexus 9000 Series switches and the end host terminal sessions, for example SSH terminal sessions.

So far so good. We can probably tolerate some delay. However, the next sentence is a killer…

During Cisco Live Europe (huge thanks to Tech Field Day crew for bringing me there) I had a chat with Jeff McLaughlin about NETCONF support on Cisco IOS XE, in particular on the campus switches.

We started with the obvious question “why would someone want to have NETCONF on a campus switch”, continued with “why would you use NETCONF and not REST API”, and diverted into “who loves regular expressions”. Teasing aside, we discussed:

Niki Vonderwell kindly invited me to Troopers 2017 and I decided to talk about security and reliability aspects of network automation.

The presentation is available on my web site, and I’ll post the link to the video when they upload it. An extended version of the presentation will eventually become part of Network Automation Use Cases webinar.

Ansible network modules (at least in the way they’re implemented in Ansible releases 2.1 and 2.2) were one of the more confusing aspects of my Building Network Automation Solutions online course (and based on what I’m seeing on various chat sites we weren’t the only ones).

I wrote an in-depth explanation of how you’re supposed to be using them a while ago and now updated it with user authentication information.