This is the third blog post in “thinking out loud while preparing Network Infrastructure as Code presentation for the network automation course” series. You might want to start with Network-Infrastructure-as-Code Is Nothing New and Adjusting System State blog posts.

As I described in the previous blog post, the hardest problem any infrastructure-as-code (IaC) tool must solve is “how to adjust current system state to desired state described in state definition file(s)”… preferably without restarting or rebuilding the system.

There are two approaches to adjusting system state:

Here’s a bit of good news for those of you scared of network automation replacing your jobs: even Elon Musk didn’t manage to pull it off, so I don’t think a networking vendor dabbling in intent will manage to do it (particularly considering the track record of networking vendors’ network management and orchestration systems).

You might have noticed that almost every BGP as Data Center IGP design uses the same AS number on all spine switches (there are exceptions coming from people who use BGP as RIP with AS-path length serving as hop count… but let’s not go there).

There are two reasons for that design choice:

Pradosh Mohapatra, the author of last week’s SD-WAN Overview webinar started his presentation with a seemingly simple question: What Is SD-WAN?

In September 2018, Saša Ratković (Apstra) published a must-read Intent-Based Networking Taxonomy¹ which (not surprisingly) isn’t too far from what I had to say about the topic in a blog post and related webinar.

It’s also interesting to note that the first three levels of intent-based networking he described match closely what we’re discussing in Building Network Automation Solutions online course and what David Barroso described in Network Automation Use Cases webinar:

This is the second blog post in “thinking out loud while preparing Network Infrastructure as Code presentation for the network automation course” series. If you stumbled upon it, you might want to start here.

An anonymous commenter to my previous blog post on the topic hit the crux of the infrastructure-as-code challenge when he wrote: “It's hard to do a declarative approach with Ansible and the nice network vendor APIs.” Let’s see what he was trying to tell us.

Last year’s experiment generated so much interest that I decided to repeat it this year: if you’re an undergraduate or Master's student and manage to persuade us that you’re motivated enough to automate the **** out of everything, you’ll get a free seat in Ansible for Networking Engineers online course.

Interested? Check out the details, and apply before October 1^st.

Too old? Please spread the word ;)

Here’s a question I got from an attendee of my Building Next-Generation Data Center online course:

As far as I understood […] it is obsolete nowadays to build a new DC fabric with routing on the host using BGP, the proper way to go is to use IGP + SDN overlay. Is my understanding correct?

Ignoring for the moment the fact that nothing is ever obsolete in IT, the right answer is it depends… this time on answer(s) to two seemingly simple questions “what services are we offering?” and “what connectivity problem are we trying to solve?”.

Most blog posts generate the usual noise from the anonymous peanut gallery (if only they’d have at least a sliver of Statler and Waldorf in them), but every now and then there’s a comment that’s pure gold. The one made by Tony Przygienda (of RIFT fame) on Valley-Free Routing post is so good and relevant that I decided to republish it as a separate blog post. Enjoy!

Johannes Weber was forced to stress-test the IPv6 networks are easy to renumber nonsense and documented his test results – a must-read for everyone deploying IPv6.

He found out that renumbering IPv6 in his lab required almost four times as many changes as renumbering (outside) IPv4 in the same lab.

My cynical take on that experience: “Now that you’ve documented everything that needs to be changed, make sure it’s automated the next time ;)”