BGP is the kitchen-sink of networking protocols, right? Whatever control-plane information you need to transport around, you can do it with BGP… including the battleship coordinates carried in BGP communities.

On the more serious front, it's nice to see at least some ISPs still care enough about the stability of the global Internet to use BGP route flap dampening.

As part of his “how does Avaya implement data center fabrics” presentation, Roger Lapuh talked about use cases for SPB in data center fabrics.

I have no idea what Extreme decided to do with the numerous data center fabric solutions they bought in the last few years, so the video might have just a historic value at this point… but it’s still nice to see what you can do with smart engineering.

Someone left a comment on my Zero-Touch Provisioning post claiming how Big Switch Networks solved ZTP challenge using just IPv6 Link-Local Address and Neighbor Discovery instead of the complicated DHCP/TFTP/whatever sequence.

Here’s what he wrote:

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

Every now and then someone asks me “Why are we making so little progress on network automation? Why does it seem so hard?”

There are some obvious reasons:

• Tightly-coupled components and humongous blast radius;
• Lack of good tools and programming interfaces;
• Lack of transactional consistency (in some cases even simple commits);

However, there’s a bigger elephant in the room: every network is a unique snowflake.

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).

You might say “but we could politely agree to disagree” but unfortunately that implies that at least one of us is not fully rational due to Aumann’s Agreement Theorem.

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.

When the Spring 2018 Building Network Automation Solutions online course started, we didn’t know whether we’d run another course in 2018, so we offered engineers who wanted to get an early start Believer price.

The wait is over: the autumn 2018 course starts on September 18^th. The schedule of the live sessions is already online, and we also have the first guest speakers. We’ll announce them in early June at which time you will no longer be able to get the Enthusiast price, so register ASAP.