After a series of forward-looking podcast episodes we returned to real life and talked with Carl Buchmann about his network automation journey, from managing upgrades with Excel and using Excel as the configuration consistency tool to network-infrastructure-as-code concepts he described in a guest blog post in February 2018

David Gee is coming back to Building Network Automation Solutions online course – in early March 2019 he’ll talk about hygiene of network automation. Christoph Jaggi did an interview with him to learn more about the details of his talk, and they quickly diverted into an interesting area: automated workflows.

Automation is about automated workflows. What kind of workflows can be automated in IT and networking?

Workflows most often fall into categorizations of build, operations and remediation.

Here’s another interesting talk from RIPE77: Routing Attacks in Cryptocurrencies explaining how BGP hijacks can impact cryptocurrencies.

TL&DR: Bitcoin is not nearly decentralized enough to be resistant to simple and relatively easy BGP manipulations.

You know that time of year when snowflakes mean more than description of uniqueness of your networking infrastructure? Some people love to complain about that season and how the weather hinders them, others put on sturdy winter boots and down jackets, change tires on their car, and have tons of fun.

Network automation is no different. Sometimes you can persuade your peers that it makes sense to simplify and standardize the infrastructure to make it easier to abstract and automate (consider that an equivalent of going to a tropic island with shiny beaches and everlasting summer), other times you have to take out your winter boots and make the best out of what you got.

In spring 2018 I started collecting real-life automation wins reported by the attendees of my Building Network Automation Solutions online course. I presented them at Troopers, and as a set of network automation use cases that are available to all ipSpace.net subscribers, some of them even with free subscription.

Today let’s start with how did it start story.

One of my readers sent me this question:

It would be nice to have a blog post or a webinar describing how to implement container networking in case when: (A) application does not tolerate NAT (telco, e.g. due to SCTP), (B) no DNS / FQDN, is used to find the peer element and (C) bandwidth requirements may be tough.

The only thing I could point him to is the Advanced Docker Networking part of Docker Networking Fundamentals webinar (available with free subscription) where macvlan and ipvlan are described.

A lightning talk at the recent RIPE77 conference focused on shortcomings of VXLAN and rise of Geneve.

So what are those perceived shortcomings?

No protocol identifier – a single VXLAN VNI cannot carry more than one payload type. Let me point out that MPLS has the same shortcoming, as does IPsec.

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

After publishing the Manual Work Is a Bug blog post, I got this feedback from Michele Chubirka explaining why automating changes in your network also increases network security:

After explaining the basics of SD-WAN, Pradosh Mohapatra, the author of SD-WAN Overview webinar focused on SDWAN reference network design.

The “everyone should be a programmer” crowd did a really good job of scaring network engineers (congratulations, just what we need!). Here’s a typical question I’m getting:

Do I need to be good in scripting to attend your automation course.

TL&DR: Absolutely not.

Here’s a question I got from someone attending the Building Next-Generation Data Center online course:

Cisco NCS5000 is positioned as a building block for a data center MPLS fabric – a leaf-and-spine fabric with MPLS and EVPN control plane. This raised a question regarding MPLS vs VXLAN: why would one choose to build an MPLS-based fabric instead of a VXLAN-based one assuming hardware costs are similar?

There’s a fundamental difference between MPLS- and VXLAN-based transport: the amount of coupling between edge and core devices.

The last two months of 2018 will be jam-packed with webinars and on-site events:

• Dinesh Dutt will talk about network observability, how it’s different from monitoring and why it matters on November 8^th;
• I’ll continue the Amazon Web Services networking saga with the third live session on November 15^th. We already covered VPCs, interfaces and addresses, network security, route tables, and Internet connectivity. Now it’s time for VPNs, Direct Connect and VPC peering;
• The annual Data Center Fabric Architectures update will take place on November 22^nd. I’ll cover the changes in data center switching market, and new hardware launched by major vendors;
• The Network Connectivity and Graph Theory webinar was a huge hit, so we agreed with Rachel Traylor to do a whole series of similar webinars. On November 29^th she’ll cover Reliability Theory: Networking through a Systems Analysis Lens;

December will be a storage, EVPN and SDN month:

Yves Haemmerli, Consulting IT Architect at IBM Switzerland, sent me a thoughtful response to my we need product documentation rant. Hope you’ll enjoy it as much as I did.

Yes, whatever the project is, the real added value of an IT/network architect consultant is definitely his/her ability to create models (sometimes meta-models) of what exists, and what the customer is really looking for.

I long while ago I stumbled upon an excellent resource describing why distributed systems are hard (what I happened to be claiming years ago when OpenFlow was at the peak of the hype cycle ;)… lost it and found it again a few weeks ago.

If you want to understand why networking is hard (apart from the obvious MacGyver reasons) read it several times; here are just a few points:

A few years ago I got cornered by an enthusiastic academic praising the beauties of his cryptography-based system that would (after replacing the whole Internet) solve all the supposed woes we’re facing with BGP today.

His ideas were technically sound, but probably won’t ever see widespread adoption – it doesn’t matter if you have great ideas if there’s not enough motivation to implementing them (The Myths of Innovation is a mandatory reading if you’re interested in these topics).