Category: worth reading

They say time goes faster as you get older, and it seems to be true. Another year has (almost) gone by.

Try to disconnect from the crazy pace of the networking world, forget the “vibe coding with AI will make engineers obsolete” stupidities (hint: Fifth Generation Languages and Natural Language Programming were all the rage in the 1980s and 1990s), and focus on your loved ones. I would also like to wish you all the best in 2026!

In the meantime, I’m working on weaning netlab off of a particular automation tool (you can always track the progress on GitHub). Expect the first results in the January netlab release.

Want to look up various HTTP status/error codes when troubleshooting a DNS BGP network server problem? Start at http.pizza for badly-needed stress relief (HT: Networking Notes), then start a chat session with your new AI friend exploring more focused resources like the Wikipedia list of HTTP status codes.

In 2007, Jeff Atwood published a legendary blog post summarizing a 1997 paper by Brian Foote and Joseph Yoder.

Reading that blog post (or the original paper), the inevitable conclusion is that we haven’t made much progress in the last 20 years. Even worse, almost every single pathological architecture described in that blog post applies quite well to real-life organically grown networks.

Sean Goedecke published an excellent set of recommendations for good technical writing, including:

• Keep it short
• Try to make your point in the first sentence
• Details matter less than you think.

Based on some emails I received in the past (and the lack of response to the lengthy emails I sent), we should apply the same rules to emails (and all other forms of technical communication).

What could be better than watching 0x02 Jeffs discuss networking? How about having Petr Lapukhov of the RFC 7938 fame as a guest discussing AI/ML Data Center Design?

Note: Petr disappeared into the information black hole called Facebook over a decade ago, so I wondered how they allowed him to chat on a podcast for hours. It turns out he moved to NVIDIA, which might influence the podcast content a bit, but I’m pretty sure Petr is still Petr ;)

In his latest blog post (Systems design 3: LLMs and the semantic revolution), Avery Pennarun claims that LLMs might solve the problem we consistently failed to solve on a large scale for the last 60 (or so) years – the automated B2B data exchange.

You might agree with him or not (for example, an accountant or two might get upset with hallucinated invoice items), but his articles are always a fun read.

Aleksandr Albin built a large (almost 20-router) lab topology (based on an example from Jeff Doyle’s Routing TCP/IP Volume 2) that he uses to practice inter-AS IP multicast. He also published the topology file (and additional configuration templates) on GitHub and documented his experience in a LinkedIn post.

It’s so nice to see engineers using your tool in real-life scenarios. Thanks a million, Aleksandr, for sharing it.

Dmitry Klepcha published an excellent document describing how you can use netlab to build a series of data center fabric labs, starting from a simple IP network (without routing) and finishing with a complex EVPN/VXLAN network using symmetric IRB and MLAG toward hosts.

But wait, there’s more: all the lab topologies he used in his exercises are available on GitHub, which means that you could just clone the repo and start using them (I also “borrowed” some of his ideas as future netlab improvements).

Finally, thanks a million to Roman Pomazanov for bringing Dmitry’s work to my attention (and for the quote at the end of his post ;).

Many engineers who tried out (or use) various AI products would agree that they’re useful when used correctly, but way overhyped. However, as Anil Dash explains in his Majority AI View article, we rarely hear that opinion:

What’s amazing is the reality that virtually 100% of tech experts I talk to in the industry feel this way, yet nobody outside of that cohort will mention this reality.

Jason Gintert published an excellent explanation why AI won’t replace (all) network engineers, and reading it, I felt like reading one of my “automation won’t replace network engineers” blog posts.

Here’s a quote to get you in the mood:

AI will make good engineers better and will expose mediocre ones. If your value proposition is memorizing CLI commands or being a human grep for log files, then yes, you might need to be worried.

Pat Allen wrote an interesting guide for managers of networking teams dealing with the onslaught of AI (HT: PacketPushers newsletter).

The leitmotif: use AI to generate a rough solution, then review and improve it. That makes perfect sense and works as long as we don’t forget we can’t trust AI, assuming you save time doing it this way.

Is it possible to deploy Precision Time Protocol across a country-wide WAN network and reach nanosecond-level synchronization between cities? It’s definitely not trivial and only works over dedicated infrastructure; for more details, watch the PTP in WANs (video) presentation Oliver Ettlin had at SwiNOG 40.

Whenever you see Gerhard Stein and Thomas Weible from Flexoptix in a list of presenters, three things immediately become obvious:

1. It will be about transceivers
2. It will be fun
3. It will include some crazy stuff

Their SwiNOG 40 presentation (video) met all three expectation. We learned how well transceivers cope with high temperatures and what happens when you try to melt them with a heat gun.

If you know as much about submarine cables (the thingies that carry 90% of international Internet traffic) as I do (= nothing), you SHOULD watch the Technical Update on Submarine Cables (video) presentation Liam Taylor had at the SwiNOG 40 event. Have fun ;)

Suresh Vina published a great netlab tutorial, going from the very basics to a full-blown MPLS network with custom multi-vendor device configuration. Thank you!