Remember the unnumbered IP interfaces saga? Let’s conclude with the final challenge: can we run link-state routing protocols (OSPF or IS-IS) over unnumbered interfaces?

Quick answer: Sure, just use IPv6.

Cheater! IPv6 doesn’t count. There are no unnumbered interfaces in IPv6 – every interface has at least a link-local address (LLA). Even more, routing protocols are designed to run over LLA addresses, including some EBGP implementations, allowing you to build an LLA-only network (see RFC 7404 for details).

OK, what about IPv4?

TL&DR: It works, but…

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.

Remember the Cloud Models, Layers and Responsibilities video by Matthias Luft? He continued his introduction of cloud services with Cloud Services Hierarchy, explained the differences between infrastructure, platform, function and software as a service, and concluded with a there’s no free lunch message.

In 2021, we completed one of the longest ipSpace.net webinars: Cisco ACI Deep Dive (almost 13 hours of content¹). One of the participants found it extremely useful:

I really like the technical detail of the webinar and the way it is composed. Mario also does a good job in explaining all the complexity in a clear way without oversimplifying. All the sessions help to build up an understanding on the inner workings of the ACI solution, because they deliver technical details in depth piece by piece.

I also liked his take on the value of this webinar:

I’m always amazed on how much other (offical) training vendors under deliver in their courses that cost thousands of dollars, compared to the real expert level stuff you’ve got here.

Hope you’ll like the webinar as much as he did – you can get it with Standard or Expert ipSpace.net Subscription.

All BGP implementations I’ve seen so far use recursive next hop lookup:

• The next hop in the IP routing table is the BGP next hop advertised in the incoming update
• That next hop is resolved into the actual next hop using one or more recursive lookups into the IP routing table.

Furthermore, all BGP implementations I’ve seen used multiple recursive next hops (if available) to implement load balancing toward the BGP next hop – that’s how we made EBGP load balancing work in Stone Age of networking.

While I liked reading the Where to Stick the Firewall blog post by Peter Welcher, it bothered me a bit that he used microsegmentation to mean security groups.

I know that microsegmentation became approximately as well-defined as cloud or SDN¹, but let’s aim our shiny lance ² at the nearest windmill and gallop away…

Tons of new things were added to netsim-tools in December 2021:

• Pete Crocker contributed support for Fortinet devices. You can configure IPv4, IPv6 and OSPF. More details…
• Jeroen van Bemmel contributed support for Nokia SR Linux and SR OS (including initial device configuration, OSPF, ISIS, BGP, and SR-MPLS).
• I added Vagrant box names for IOSv, CSR and vSRX on VirtualBox. You still have to build the boxes, but at least you won’t have to change the default settings.

It’s hard to believe, but another year has swooshed by, and it’s time to shut down my virtual office and disappear until mid-January. Of course I’ll be around in case of urgent support problems – I will read my email, but won’t reply to 90% of the stuff coming in.

I hope you’ll be able to find a few days to disconnect from the crazy pace of networking world and focus on your loved ones. I would also like to wish you all the best in 2022!

I wanted to cover fast failover (at least the basics and Prefix Independent Convergence – PIC) in another live session of How Networks Really Work webinar in 2021, but unfortunately I ran out of time.

As a teaser, you might want to watch the recording of Fast Failover: Marketing and Reality presentation I had at the Seventh RSNOG Conference.

The Dynamic Negotiation of BGP Capabilities blog post generated almost no comments, apart from the #facepalm realization that a certain network operating system resets IBGP sessions when the sole EBGP session goes down, but there were a few interesting comments on LinkedIn and Twitter.

While most engineers easily relate to the awkwardness of bringing down a BGP session to enable new functionality (Tearing down BGP session, as a solution reminds me rebooting a host, as a solution.), it’s not as easy as it looks. As Adam Chappell put it “Dynamic capability renegotiation does tend to sound a bit like changing the tyres while still moving. Very neat if you can pull it off but so much to go wrong…”

Here’s a fun fact network automation pundits don’t want to hear: if you’re working with replaceable device configurations (as we did for the past 20 years, at least those fortunate enough to buy Junos), you already meet the Infrastructure-as-Code requirements. Storing device configurations in a version control system and using reviews and merge requests to change them (aka GitOps) is just a cherry on the cake.

When I made a claim along these same lines a few weeks ago during the Network Automation Concepts webinar, Vladimir Troitskiy sent me an interesting question:

Setting up a network automation development environment is an interesting task:

• You have to install a half-dozen tools, each one with tons of dependencies;
• SSH libraries like paramiko have to installed manually;
• Ansible modules for individual network devices might need extra libraries;
• Parsing tools invoked with Ansible Jinja2 filters have to be installed separately;
• Add your pet peeve here ;)

Now imagine having to do that for a dozen networking engineers and software developers working on all sorts of semi-managed laptops. Containers seem to be one of the sane solutions¹.

In his latest blog post, Tom Hollingsworth compares network device disaggregations with cord cutting (replacing cable TV subscription with Netflix and friends), and comes to the inevitable conclusion:

The idea is that you gain freedom and cheaper software. The hope is that you can build an enterprise network for half of what it would normally cost. The reality is that you’re going to gain less functionality and spend more time integrating things together on your own instead of just putting in a turnkey solution.

To rephrase it, you’ll design a snowflake network with snowflake devices. Good job – just because it makes sense for the FAANG club (or LinkedIn), it doesn’t mean you should be doing it.

After the (in)famous October 2021 Facebook outage, Corey Quinn invited me for another Screaming in the Cloud chat, this time focusing on what went wrong (hint: it wasn’t DNS or BGP).

We also touched on VAX/VMS history, how early CCIE lab exams worked, how BGP started, why there are only 13 root name servers (not really), and the transition from networking being pure magic to becoming a commodity. Hope you’ll enjoy our chat as much as I did.

Dmytro Shypovalov sent me his views on the hardware differences between routers and switches. Enjoy!

So, a long time ago routers were L3 with CPU forwarding and switches were L2 with ASIC. Then they had invented TCAM and L3 switches, and since then ASICs have evolved to support more features (QoS, encapsulations etc) and store more routes, while CPU-based architectures have evolved to specialised NPU and parallel processing (e.g. Cisco QFX) to handle more traffic, while supporting all features of CPU forwarding.