The proponents of the “let’s run EVPN over EBGP underlay” idea often ignore an interesting challenge: EVPN advocates the use of automatically-generated Route Targets, which might not work when every leaf switch uses a different AS number.

I explored this particular can of worms in the EVPN Route Target Considerations section of the Using BGP in a Data Center Leaf-and-Spine Fabric saga.

Remember the IPv6 elephant in the room – the inability to do small-site multihoming without NAT (well, NPT66)? IPv6 is old enough to buy its own beer, but the elephant is still hogging the room. Tons of ideas have been thrown around in IETF (mostly based on source address selection tricks), but none of that spaghetti stuck to the wall.

Stumbled upon this paragraph on Russ White’s blog:

I don’t really know how you write a certification that does not allow someone who has memorized the feature guide to do well. How do you test for protocol theory, and still have a broad enough set of test questions that they cannot be photographed and distributed?

As Russ succinctly explained the problem is two-fold:

One of my readers sent me a container security question after reading the Application Container Security Guide from NIST:

We are considering segregating dev/test/prod environments with bare-metal hardware. I did not find something in the standard concerning this. What should a financial institution do in your opinion?

I am no security expert and know just enough about containers to be dangerous, but there’s a rule that usually works well: use common sense and identify similar scenarios that have already been solved.

I’m always telling network engineers attending my network automation workshops and online courses that there’s no magic bullet or 3-steps-to- success.

You cannot automate a process until you can describe it with enough details so that someone who has absolutely no clue what should be done can execute it.

David Gee published a long (and somewhat ranty) version of that statement. Enjoy!

In the second half of his Networks, Buffers, and Drops webinar JR Rivers focused on end systems: what tools could you use to measure end-to-end TCP throughput, or monitor performance of an individual socket or the whole TCP stack?

REST API is the way of the world and all network devices should support it, right? Well, Ken Duda (Arista) disagreed with this idea during his Networking Field Day presentation, but unfortunately there wasn’t enough time to go into the details that would totally derail the presentation anyway.

Fixing that omission: should we have REST API on network devices or not?

My BGP in EVPN-Based Data Center Fabrics blog post generated numerous comments from engineers disagreeing with my views on using IBGP-over-EBGP.

As usual, there were three kinds of comments:

The idea of generating random IPv6 addresses (so you cannot be tracked across multiple networks based on your MAC address) that stay stable within each subnet (so you don’t pollute everyone’s ND cache every time you open your iPad) is pretty old: RFC 7217 was published almost exactly four years ago.

Linux was quick to pick it up, OpenBSD got RFC 7127 support a few weeks ago. However, there’s an Easter egg in the OpenBSD patches that implement it: SLAAC on OpenBSD now works with any prefix length (not just /64).

Years ago Petr Lapukhov decided that it’s a waste of time to try to make OSPF or IS-IS work in large-scale data center leaf-and-spine fabrics and figured out how to use BGP as a better IGP.

In the meantime, old-time routing gurus started designing routing protocols targeting a specific environment: highly meshed leaf-and-spine fabrics. First in the list: Routing in Fat Trees (RIFT).

One of my readers found a Culumus Networks article that explains why you can’t have more than a few hundred VXLAN-based VLAN segments on every port of 48-port Trident-2 data center switch. That article has unfortunately disappeared in the meantime, and even the Wayback Machine doesn’t have a copy.

Andy sent me this question:

I'm currently playing around with BGP & VXLANs and wondering: is there anything preventing from building a virtual IXP with VXLAN? This would be then a large layer 2 network - but why have nobody build this to now, or why do internet exchanges do not provide this?

There was at least one IXP that was running on top of VXLAN. I wanted to do a podcast about it with people who helped them build it in early 2015 but one of them got a gag order.

The pace of live webinar sessions will slow down a bit in April 2018 due to the onslaught of European spring holiday season. Nonetheless, you’ll be able to enjoy:

• The second part of EVPN Technical Deep Dive series with Dinesh Dutt on April 5th;
• The planning and design part of NSX, ACI or EVPN webinar with Mitja Robas on April 24th;

On April 19th we’ll have the first DIGS event in 2018, starting with introduction to SDDC and VMware NSX in the morning and NSX workshop in the afternoon.

Sitting in a taxi driving to CLEUR 2018 in Barcelona we couldn’t resist but complain about the stuff we’re seeing in real-life networks, resulting in someone exclaiming something along the lines of “I can’t understand how someone could do so many stupid things”

Welcome to the wonderful world of Dunning-Kruger Effect.

The networking engineers attending the Building Network Automation Solutions online course created numerous amazing automation solutions, most of them already deployed in production networks.

I described some of them in my Troopers 2018 Real-Life Automation Wins talk. The presentation is online and the video has been published on YouTube a few days ago. I hope you’ll find it as inspirational as the Troopers attendees did.

Did you create an awesome automation solution? I’d like to hear about it!

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