Networking engineers familiar with Junos love to tell me how easy it is to configure and operate IBGP EVPN overlay on top of EBGP IP underlay. Krzysztof Szarkowicz was kind enough to send me the (probably) simplest possible configuration (here’s another one by Alexander Grigorenko)

Got this response to my Stretched Layer-2 Revisited blog post. It’s too good not to turn it into a blog post ;)

Recently I feel like it's really vendors pushing layer 2 solutions, rather than us (enterprise customer) demanding it.

I had that feeling for years. Yes, there are environment with legacy challenges (running COBOL applications on OS/370 with emulated TN3270 terminals comes to mind), but in most cases it’s the vendors trying to peddle unique high-priced non-interoperable warez.

Steve Krause created a full-blown network services deployment solution, including post-deployment validation of OSPF and BGP routing, while attending Building Network Automation Solutions online course (I prefer course attendees working on real-life problems instead of artificial ones).

Hope you’ll enjoy exploring it ;)

An attendee of my Building Next-Generation Data Center online course asked me what the best learning path might be for a total (data center) beginner that has to design and install a small leaf-and-spine fabric in a near future.

This blog post was written for ipSpace.net subscribers who want to get the most out of ipSpace.net content. If you’re only interested in free stuff, you might feel it’s a waste of your time. You’ve been warned ;)

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

Tom Limoncelli wrote a great article about starting an automation journey from sysadmin perspective. Not surprisingly, his recommendations aren’t that far off from what I’m telling networking engineers in my network automation presentations, Network Automation 101 webinar, and introductory part of Building Network Automation Solutions online course:

Our good friend mr. Anonymous has too many buzzwords and opinions in his repertoire, at least based on this comment he left on my Using 4-byte AS Numbers with EVPN blog post:

But IGPs don't scale well (as you might have heard) except for RIFT and Openfabric. The others are trying to do ECMP based on BGP.

Should you be worried about OSPF or IS-IS scalability when building your data center fabric? Short answer: most probably not. Before diving into a lengthy explanation let's give our dear friend some homework.

EVPN might be the next big thing in networking… or at least all the major networking vendors think so. It’s also a pretty complex technology that still faces some interoperability challenges (I love to call it SIP of networking).

To make matters worse, EVPN can easily become even more confusing if you follow some convoluted designs propagated on the ’net. The best antidote to that is to invest time into understanding the fundamentals and slowly work through more complex scenarios after mastering the basics.

I always wondered why it’s so hard to accept that someone might not find your preferred solution beautiful but would call it complex or even harmful (or from the other side, why someone could not possibly appreciate the beauty of your design)… and then stumbled upon this blog post by Scott Adams describing cognitive dissonance (the actual topic they’re discussing in the mentioned video doesn’t matter – look for the irrational behavior).

More and more network devices support REST API as the configuration method. While it’s not as convenient as having a dedicated cmdlet, it’s possible to call REST API methods (and configure or monitor network devices) directly from a PowerShell script, as Mitja Robas demonstrated during the PowerShell for Networking Engineers webinar.

You’ll need at least free ipSpace.net subscription to watch the video.

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

We’ve been told for years how we’re over-complicating networking, and how the software-defined or intent-based whatever will remove all that complexity and remove the need for networking engineers.

What never ceases to amaze me is how all these software-defined systems are demonstrated: each one has a fancy GUI that looks great in PowerPoint and might even work in practice assuming you’re doing exactly what they demonstrated… trying to be creative could result in interesting disasters.