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…

Pete Lumbis started his Cumulus Linux 4.0 update with an overview of differences between Cumulus Linux on hardware switches and Cumulus VX, and continued with an in-depth list of ASIC families supported by Cumulus Linux.

You can watch his presentation, as well as the more in-depth overview of Cumulus Linux concepts by Dinesh Dutt, in the recently-updated What Is Cumulus Linux All About video.

It’s amazing how sometimes people fond of sharing their opinions and buzzwords on various social media can’t answer simple questions. Today’s blog post is based on a true story… a “senior network architect” fully engaged in a recent hype cycle couldn’t answer a simple question:

Why exactly would you need VXLAN and EVPN?

We could spend a day (or a week) discussing the nuances of that simple question, but all I have at the moment is a single web page, so here we go…

A few weeks ago I described the basics of AWS networking, now it’s time to describe how different Azure is.

As always, it would be best to watch my Azure Networking webinar to get the details. This blog post is the abridged CliffsNotes version of the webinar (and here’s the reason I won’t write a similar blog post for other public clouds ;).

Here’s the final push before we hit the summer break at the end of June (and recover a bit from the relentless production of new content we had throughout the first half of 2020):

• I finished the Introduction to Containers and Docker update just in time to cover the nuances of Docker Networking before the summer break. The first live session will take place today, the second one on June 11th.
• Later this week (May 28th) we’ll have some fun with routing protocol basics.
• Dinesh Dutt covered Vagrant in his last live session and plans to cover other network simulation tools on June 2nd.
• We did a “should I use VMware NSX or Cisco ACI” webinar a few years ago. In the meantime both vendors launched major new features, so it’s high time for a thorough refresh starting on June 9th.
• Mario Rosi will continue the Cisco ACI Introduction series on June 16th.
• David Barroso described the basics of Nornir in our network automation course. We’ll turn that material into an independent webinar (available with standard ipSpace.net subscription) and David plans to augment it with a deep dive into Nornir internals in a live session on June 18th.
• I will need another live session on June 23rd to continue the NSX-or-ACI comparison, and we plan to start the summer break on June 25th.

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.

After describing Cisco SD-WAN fundamentals and its network abstraction mechanisms, David Penaloza explained the components of Cisco SD-WAN solution and its architecture, including in which plane each element operates and its assigned role in the overlay network.

I got this question about the use of AS numbers on data center leaf switches participating in an MLAG cluster:

In the Leaf-and-Spine Fabric Architectures you made the recommendation to have the same AS number on all members of an MLAG cluster and run iBGP between them. In the Autonomous Systems and AS Numbers article you discuss the option of having different AS number per leaf. Which one should I use… and do I still need the EBGP peering between the leaf pair?

As always, there’s a bit of a gap between theory and practice ;), but let’s start with a leaf-and-spine fabric diagram illustrating both concepts:

When I started designing Data Center Infrastructure for Networking Engineers webinar I wanted to create something that would allow someone fluent in networking but not in adjacent fields like servers or storage to grasp the fundamentals of data center technologies, from server virtualization and containers to data center fabrics and storage protocols.

Here’s what a network architect said about the webinar:

During the Comparing Transparent Bridging and IP Routing part of How Networks Really Work webinar I said something along the lines of:

While packets should never be reordered in transit in transparent bridging, there’s no such guarantee in IP networks, and IP applications should tolerate out-of-order packets.

One of my regular readers who designs and builds networks supporting VoIP applications disagreed with that citing numerous real-life examples.

Of course he was right, but let’s get the facts straight first:

A few days ago Greg Ferro published an interesting post claiming DHCP is an example of intent-based networking (a bit less tongue-in-cheek than my “so is OSPF configuration” rant from 2017). BTW, so is RADIUS or TACACS+ ;)

He got quickly “corrected” by Phil Gervasi who loosely relied on Gartner’s definition of Intent-Based Networking, and claimed that an intent-based networking system should have three major components:

If you treat your engineers like interchangeable human resources you’ll get the results you deserve ;)… but if you wonder how to make them keep them happy and production, there’s no better place to start than the Key Factors in Attracting and Retaining Talent by Daniel Dib.

A while ago we discussed a software-focused view of Network Interface Cards (NICs) with Luke Gorrie, and a hardware-focused view of them with Or Gerlitz (Mellanox), Andy Gospodarek (Broadcom) and Jiri Pirko (Mellanox).

Why would anyone want to implement features in hardware and not in software, and what would be the best hardware implementation? We discussed these dilemmas with Silvano Gai in Episode 110 of Software Gone Wild podcast.