Category: automation

One of my readers sent me this question:

How can I learn more about reading REST API information from network devices and storing the data into tables?

Long story short: it’s like learning how to drive (well) - you have to master multiple seemingly-unrelated tasks to get the job done.

I always love to hear from networking engineers who managed to start their network automation journey. Here’s what one of them wrote after watching Ansible for Networking Engineers webinar (part of paid ipSpace.net subscription, also available as an online course).

This webinar helped me a lot in understanding Ansible and the benefits we can gain. It is a big area to grasp for a non-coder and this webinar was exactly what I needed to get started (in a lab), including a lot of tips and tricks and how to think. It was more fun than I expected so started with Python just to get a better grasp of programing and Jinja.

In early 2019 we made the webinar even better with a series of live sessions covering new features added to recent Ansible releases, from core features (loops) to networking plugins and new declarative intent modules.

We got pretty far in our data deduplication in network data model journey, from initial attempts to network modeled as a graph… but we still haven’t got rid of all the duplicate information.

For example, if we have multiple devices connected to the same subnet, why should we have to specify IP address and subnet mask for every device (literally begging the operators to make input errors). Wouldn’t it be better (assuming we don’t care about exact IP addresses on core links) to assign IP addresses automatically?

The No Scripting Required to Start Your Automation Journey blog post generated lively discussions (and a bit of trolling from the anonymous peanut gallery). One of the threads focused on “how does automation work in real life IT department where it might be challenging to simplify operations before automating them due to many exceptions, legacy support…”

Here’s a great answer provided by another reader:

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

At the end of my vNIC 2018 keynote speech I made a statement along these lines:

The moment you start using GUI with an SDN product you’re back to square one.

That claim confused a few people – Mark left this comment on my blog:

Remember the avoid duplicate data in network automation data models challenge and the restructuring we did to represent a network as a graph.

Well, I was not happy with the end result - I hated the complexity of supporting Jinja2 templates that had to check left- and right nodes of a link, so I generalized the data structure a bit, and all of a sudden I could model stub interfaces, P2P links and multi-access networks.

I hate listening to “this is what we were doing this year” podcasts as they usually turn into pointless blabbering, self-congratulations and meaningless plans (think New Year resolutions). The Full Stack Journey Episode 28 with Scott Lowe was an amazing deviation from this too-common template.

If you don’t have time to listen to the podcast (but you OUGHT TO do it) here’s what I loved most: “When faced with the onslaught of new technologies, don’t panic. Wait a few months to see which ones survive”.

Last week I explained how you could take a typical first attempt at a network automation data model and reduce the amount of duplicate data… but the data model we used was still describing a set of seemingly disconnected boxes.

How about restructuring the whole thing and describing what networks really are - graphs made of nodes (network devices) and links?

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

Remember the “every device configuration is really an expression of our intent” discussion? Forgetting the wrong level of abstraction (we mostly don’t want to deal with all the idiosyncratic stuff network devices want to see in their configurations) and box-oriented thinking caused by device-level intent for the moment, let’s focus on another aspect: how hard is it to manage your intent?

One of the toughest challenges in the hands-on part of Building Network Automation Solutions online course is the create a data model describing your service exercise.

Networking engineers never had to think about data models describing their networks or services, and the first attempt often results in something that looks like simplified device configuration in YAML or JSON format.

I wrote a long article describing how you can slowly redesign your box-focused data model into a network-focused one. The first parts describing the problem and initial deduplication are already online.

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

Imagine a small bank deciding in their infinite wisdom (in reality: because their CIO attended a conference organized by a database vendor) to implement their banking software by teaching bank tellers how to type SQL transactions by hand.

For example, to transfer money from one account to another account, a bank teller could simply type:

This is a guest blog post by Albert Siersema, senior network and cloud engineer at Mediacaster.nl. He’s always busy broadening his horizons and helping his customers in (re)designing and automating their infrastructure deployment and management.

This is the second post in a series focused primarily on brownfield automation principles using 802.1x deployments as an example (you might want to read part 1 first).

Before diving into the specifics of the next 802.1x automation phase, let’s take a step back and think about why we’re going through this effort. Automation is a wonderful tool, but it’s not a goal… and neither is 802.1x a goal - it’s just another tool that can help us realize business benefits like:

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

One of the toughest tasks faced by networking engineers attending our Building Network Automation Solutions course is designing a data model describing network infrastructure or services. They usually think in terms of individual devices (nodes) resulting in tons of duplicated data.

I always point that out when reviewing their solutions and suggest how to minimize or eliminate duplicate data. Not surprisingly, doing that is hard, and one of the attendees started wondering whether the extra effort makes sense:

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

One of the common questions we get in the Building Network Automation Solutions online course is “how do I create device inventory if I don’t know (exactly) what devices are in my network?”… prompting one of the guest speakers to reply “could it really be that bad?” (yes, sometimes it is).

Some of the students tried to solve the challenge with Ansible. While that might eventually work (given enough effort), Ansible definitely isn’t the right tool for the job.

What you need to get the job done is a proper toolchain:

Ladies and gentlemen, our Autumn 2019 Building Network Automation Solutions online course is now ready for boarding. Please make sure you have your boarding passes ready, board at your convenience, and start enjoying the pre-flight perks like over hundred hours of self-study materials.

Our flight will depart on September 3^rd with subsequent sessions on September 26^th, October 24^th and November 12^th. The guest speakers will focus on security, inventory managements, and describe their production deployments. More in a few days…

The only thing you have to do at this moment is to register (if you want to get the Enthusiast price… otherwise please feel free to wait ;)

And just in case you’re wondering: yes, I was sitting at an airport while writing this blog post ;))