I tried to wrap up my Lessons Learned presentation on a positive note: what are some of the things you can do to avoid all the traps and pitfalls I encountered in the almost four decades of working in networking industry:

• Get invited to architecture and design meetings when a new application project starts.
• Always try to figure out what the underlying actual business needs are.
• Just because you can doesn’t mean that you should.
• Keep it as simple as possible, but no simpler.
• Work with your peers and explain how networking works and why you face certain limitations.
• Humans are not perfect – automate as much as it makes sense, but no more.

Remington Loose sent me an interesting email describing his views on the right approach to network automation after reading my Network Reliability Engineering Should Be More than Software or Automation rant – he’s advocating standardizing network services and cleaning up your network before trying to deploy full-scale automation.

I think you are 100% right to start with a thorough cleanup before automation. Garbage in, garbage out. It is also the case that all that inconsistency and differentiation makes for complexity in automation (as well as general operations) that makes it harder to gain traction.

Every time I’m writing netsim-tools release notes I’m amazed at the number of features we managed to put together in just a few weeks.

Here are the goodies from netsim-tools releases 1.1.1 and 1.1.2:

New networking myths are continuously popping up. Here’s a BGP one I encountered a few days ago:

You don’t need IBGP sessions between BGP route reflectors

In general, that’s clearly wrong, as illustrated by this setup:

Last week I published a link to Pete Crocker’s RSVP-TE lab, but there’s more: he created another lab using the same topology that uses SR-MPLS with IS-IS to get the job done.

Jeroen Van Bemmel did something similar for SR Linux: his lab topology has fewer devices (plus SR Linux runs in containers), so it’s easily deployable on machines without humongous amount of memory.

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.

Yesterday I mentioned the giant glob of complexity called Kubernetes (see also more nuanced take on the topic). If you want to slowly unravel it, Kubernetes Architecture video from the excellent Kubernetes Networking Deep Dive webinar by Stuart Charlton is a pretty good starting point.

When I finally¹ managed to get SR Linux running with netlab, I wanted to test how it interacts with Cumulus VX and FRR in an OSPF+BGP lab… and failed. Jeroen Van Bemmel quickly identified the culprit: MTU. Yeah, it’s always the MTU (or DNS, or BGP).

I never experienced a similar problem, so of course I had to identify the root cause:

Got into an interesting BGP discussion a few days ago, resulting in a wild chase through recent SRv6 and BGP drafts and RFCs. You might find the results mildly interesting ;)

BGP has three dimensions of address family configurability:

• Transport sessions. Most vendors implement BGP over TCP over IPv4 and IPv6. I’m sure there’s someone out there running BGP over CLNS¹, and there are already drafts proposing running BGP over QUIC².
• Address families enabled on individual transport sessions, more precisely a combination of Address Family Identifier (AFI) and Subsequent Address Family Identifier.
• Next hops address family for enabled address families.

Aaron Glenn sent me his thoughts on hardware differences between routers and switches based on the last paragraph of Dmytro Shypovalov’s views on the topic

To conclude, what is the difference between routers and switches in my opinion? I have absolutely no idea.

It’s amazing how creative networking engineers become once they have the basic tools to get the job done a bit quicker. Last week Pete Crocker published the largest topology I’ve seen built with netlab so far: a 13-router lab running RSVP TE to transport IP traffic between external autonomous systems¹.

After Javier Antich walked us through the AI/ML hype and described the basics of machine learning it was time for a more thorough look at:

• Machine learning techniques, including unsupervised learning (clustering and anomaly detection), supervised learning (regression, classification and generation) and reinforced learning
• Machine learning implementations, including neural networks, deep neural networks and convolutional neural networks.

Remember the BGP anycast lab I described in December 2021? In that blog post I briefly mentioned a problem of extraneous IBGP sessions and promised to address it at a later date. Let’s see how we can fix that with a netlab plugin.

We always knew that it’s impossible to implement every nerd knob someone would like to have when building their labs, and extending the tool with Python plugins seemed like the only sane way to go. We added custom plugins to netlab in late 2021, but I didn’t want to write about them because we had to optimize the internal data structures first.

One of ipSpace.net subscribers asked for my opinion about Adaptive IP, a concept promoted by one of the optical connectivity vendors. As he put it:

My interest in Carrier Ethernet moving up to Layer 3 is to see if it would be something to account for in the future.

A quick search resulted in a marketecture using Segment Routing (of course) and an SDN controller (what else could one be using today) using Path Computation Element Protocol (PCEP) to program the network devices… and then I hit a regwall. They wanted to collect my personal details to grace me with their whitepaper, and I couldn’t find even a link to the product documentation.