Category: worth reading

Stumbled upon a totally unexpected fun fact:

Every server vendor either peaked or hits the peak of maximum units sold per quarter in 2015. In the years that follow, the monthly averages drop.

Keep that in mind the next time Cisco sales team comes along with a UCS presentation.

Years ago, I compared EVPN to SIP – it has a gazillion options, and every vendor implements a different subset of them, making interoperability a nightmare.

According to Andrew Alston, SRv6 is no better (while being a security nightmare). No surprise there.

Tom Hollingsworth published a more eloquent version of what I’ve been saying for ages:

• Complexity belongs to the end nodes;
• Network should provide end-to-end packet transport, not a fix for every stupidity someone managed to push down the stack;
• There’s nothing wrong with being a well-performing utility instead of pretending your stuff is working on unicorn farts and fairy dust.

Obviously it’s totally against the vested interest of any networking vendor out there to admit it.

Christoph Jaggi, the author of Ethernet Encryption webinar and ethernet encryptor market overviews launched a new site in which he collected tons material he created in the past – the network security and news and articles sections are definitely worth exploring.

I’m positive that this pointer to The Gift of It’s Your Problem Now by Avery Pennarun will generate similar comments to the blockchain one: “he’s an idiot, and you’re an idiot for wasting my time posting this”.

That might be true, but in that case he’s my kind of idiot, and you shouldn’t complain about a gift anyway – there are tons of high-quality lolcats videos waiting for you instead.

If you find smart NICs interesting, you’ll like the latest blog post by James Hamilton explaining how AWS emulated Xen environment on Nitro hardware to keep old VM instances running on new hardware.

In Git as a source of truth for network automation, Vincent Bernat explained why they decided to use Git-managed YAML files as the source of truth in their network automation project instead of relying on a database-backed GUI/API product like NetBox.

Their decision process was pretty close to what I explained in Data Stores and Source of Truth parts of Network Automation Concepts webinar: you need change logging, auditing, reviews, and all-or-nothing transactions, and most IPAM/CMDB products have none of those.

On a more positive side, NetBox (and its fork, Nautobot) has change logging (HT: Leo Kirchner) and things are getting much better with Nautobot Version Control plugin. Stay tuned ;)

Christopher Hart wrote a great blog post explaining the fundamentals of how packet load balancing works on network devices. Enjoy.

For more details, watch the Multipath Forwarding part of Advanced Routing Protocol Topics section of How Networks Really Work webinar.

It took more than seven years to publish an obvious fact as an RFC: IPv6 extension headers are a bad idea (RFC 9098 has a much more polite title or it would never get published).

Another must-read masterpiece by Julia Evans: how to get useful answers to your questions.

I read tons of articles debunking the blockchain hype, and the stupidity of waisting CPU cycles and electricity on calculating meaningless hashes; here’s a totally different take on the subject by Avery Pennarun (an update written ten years later).

TL&DR: Bitcoin is a return to gold standard, and people who know more about economy than GPUs and hash functions have figured out that’s a bad idea long time ago.

I heard about SRv6 when it was still on the drawing board, and my initial reaction was “Another attempt to implement source routing. We know how that ends.” The then-counter-argument by one of the proponents went along the lines of “but we’ll use signed headers to prevent abuse” and I thought “yeah, that will work really well in silicon implementations”.

Years later, Andrew Alston decided to document the state of the emperor’s wardrobe (TL&DR: of course SRv6 is insecure and can be easily abused) and the counter-argument this time was “but that applies to any tunnel technology”. Thank you, we knew that all along, and that’s not what was promised.

You might want to browse the rest of that email thread; it’s fun reading unless you built your next-generation network design on SRv6 running across third-party networks… which was another PowerPoint case study used by SRv6 proponents.

Long long time ago (seven years to be precise), ISOC naively tried to bridge the gap between network operators and Internet Vendor Engineering Task Force¹. They started with a widespread survey asking operators why they’re hesitant to participate in IETF mailing lists and meetings.

The result: Operators and the IETF draft that never moved beyond -00 version. A quick glimpse into the Potential Challenges will tell you why IETF preferred to kill the messenger (and why I published this blog post on Halloween).

Just FYI: if you’re wondering about the wisdom of every networking engineer should become a programmer religion, you might benefit from the Programming Sucks reality check. I had just enough exposure to programming to realize how spot-on it is (and couldn’t decide whether to laugh or cry).

In case you’re ever asked to justify an investment in network automation, read How to Make the Case for Automation Architecture first. Not surprisingly, it includes the evergreen what problem are you trying to solve?