I was considering an AI add-on that would have access to the netlab documentation and help you figure out how to use it for a few years, but never got around to implementing it (and surprisingly, with all the AI hype out there, there were no volunteers submitting pull requests). A few weeks ago, someone suggested adding an MCP server as an interface to ipSpace.net content, but the discussion quickly devolved into vague ideas.

However, as ChatGPT now has access to the live Internet, I decided to try out whether it can get the job done with a bit of prompting.

TL&DR: After a hiccup, it worked surprisingly well.

Andrew Yourtchenko and Dr. Tony Przygienda left wonderful comments to my Screen Scraping in 2025 blog post, but unfortunately they prefer commenting on a closed platform with ephemeral content; the only way to make their thoughts available to a wider audience is by reposting them. Andrew first:

I keep saying CLI is an API. However, it is much simpler and an easier way to adapt to the changes, if these three conditions are met:

netlab release 2.0.0 is out. I spent the whole week fixing bugs and running integration tests, so I’m too brain-dead to go into the details. These are the major features we added (more about them in a few days; the details are in the release notes):

• Well-defined node roles (host, router, bridge) are now available on multiple platforms
• The firewall.zonebased plugin allows you to configure a rudimentary firewall
• SRv6: BGP L3VPN support is now available for FRRouting, so you can go out and kick its (free) tires.
• bridge nodes can be used as simple bridges or to implement multi-access links
• netlab defaults command provides sysctl-like CLI interface to user/system defaults.

Other changes include:

After inspecting the confusing bridging/routing/switching terminology and a brief detour into the control/data plane details, let’s talk about how packets actually move across a network.

As always, things were simpler when networks were implemented with a single cable. In that setup, all nodes were directly reachable, and the only challenge was figuring out the destination node’s address; it didn’t matter whether it was a MAC address, an IP address, or a Fiber Channel address. On a single cable, you could just broadcast, like, “Who has this service?” and someone would reply, “I’m the printer you’re looking for.” That’s how many early non-IP protocols operated.

Dr. Tony Przygienda left a very valid (off-topic) comment to my Breaking APIs or Data Models Is a Cardinal Sin blog post:

If, on the other hand, the customers would not camp for literally tens of years on regex scripts scraping screens, lots of stuff could progress much faster.

He’s right, particularly from Juniper’s perspective; they were the first vendor to use a data-driven approach to show commands. Unfortunately, we’re still not living in a perfect world:

In a previous blog post, I described how OSPF route selection rules prevent a summary LSA from being inserted back into an area from which it was generated. That works nicely for area prefixes turned directly into summary LSAs, but how does the loop prevention logic work for summarized prefixes (what OSPF calls area ranges)?

TL&DR: It doesn’t, unless… ;)

A networking-focused entity known only as humblegrumble sent me the following question after reading my When OSPF Becomes a Distance Vector Protocol article:

How do A1 and A2 know not to advertise a Type-3 summary LSA generated from area 1 prefixes back into area 1?

He’s right. There is no “originating area” information in the type-3 LSA, so how does an ABR know not to reinsert the type-3 LSA generated by another ABR back into the area?

TL&DR: The OSPF route selection process takes care of that.

Imagine you decide to believe the marketing story of your preferred networking vendor and start using the REST API to configure their devices. That probably involves some investment in automation or orchestration tools, as nobody in their right mind wants to use curl or Postman to configure network devices.

A few months later, after your toolchain has been thoroughly tested, you decide to upgrade the operating system on the network devices, and everything breaks. The root cause: the vendor changed their API or the data model between software releases.

I wanted to test a loop prevention when propagating summary LSA across areas scenario (more about that in another blog post) using the lab topology I developed for the When OSPF Becomes a Distance Vector Protocol article.

I started the lab with the FRRouting routers and configured OSPF area ranges. Astonishingly, I discovered that the more-specific prefixes from an area appear as summary routes in the backbone area even when the area range is configured. When I tried to reproduce the scenario a few days later, it turned out to be a timing quirk (I didn’t wait long enough), but my squirrelly mind was already investigating.

After discussing networking layers and addressing, it’s time to focus on moving packets across a network. Vendors love to use ill-defined terms like switching instead of forwarding, routing, or bridging, so let’s start with the terminology.

Connecting all relevant devices to a single cable would indubitably simplify any networking stack, but unfortunately, we’re almost never that lucky. We need devices in the network (typically with multiple interfaces) that perform packet forwarding between end nodes.