I was reading the nice BGP Multi-Homed with Two ISPs and Two Routers scenario by Suresh Vinasiththamby - Packetswitch and thought wouldn’t it be nice if he were using netlab to build the lab, as that would give you the opportunity to build the same lab with zero hassle using non-Cisco devices. Guess what – Suresh already did just that. I was so glad to see someone using netlab in just the way I imagined it to be used.

A Packet Pushers newsletter brought me a link to a fantastic CLI tool: octomon by Simon Thorpe. Not only does it look awesome for a CLI tool, but it’s also one of those things always worth having in your toolbox, because you never know when you’ll need it.

Thanks a million, Ethan and Drew, for collecting the nuggets for us.

Traditional network devices used a single (active or running) configuration, with a snapshot of it stored in permanent memory (startup configuration). The active configuration was modified with every configuration command, making it a perfect recipe for disaster in the days of in-band configuration¹.

The situation improved drastically when Juniper introduced the candidate configuration. You could make changes to a copy of the configuration, and then commit them as a single all-or-nothing transaction. While you could still cut yourself off from the device, at least it was harder to do with a single misordered command.

I decided to add “Further Reading” sections to BGP lab exercises, containing links to vendor documentation and useful related blog posts. I naively expected to offload the job to Claude, commit the results, and move on. The “related blog posts” were a piece of cake; precise links to relevant vendor documentation turned out to be more of a challenge.

TL&DR: I would love to get your suggestions for further reading as PRs in the BGP Labs repo.

Apart from FRRouting, the vendor documentation is mostly generated from whatever internal system and uses auto-generated anchors that can change at any moment – somewhat “suboptimal” for what I wanted to do.

Donnie Savage decided to use netlab to test OpenEIGRP-Cisco IOS interoperability (TL&DR: it works and the source code is in Donnie’s EIGRP repository).

He asked me for a few hints before setting up his test server. This is what I sent him; you might find it useful if you ever decide to use netlab to test a new network device/protocol implementation.

The Packet Pushers newsletter dropped into my Inbox this morning, and it included a lovely Network Labs on a Budget article by Suresh Vinasiththamby, explaining how you can build a virtual lab on a mini-PC (exactly what I’m using for my netlab server) using EVE-NG, CML, or the containerlab/netlab combo.

On a tangential note: I’m busy getting various netlab features to work with netmiko, so something had to give (= blog posts).

Here’s another you can’t make this up SNAFU observation I made when running integration tests for netlab Syslog functionality: Cisco Nexus OS cannot send Syslog messages to a directly connected silent host.

The setup is as trivial as it can get: a Cisco Nexus OS VM (running version 10.6(2)) connected to a dnsmasq container running rsyslogd.

All the videos in the Data Center Fabric Architectures webinar are now available without a valid ipSpace.net account.

The webinar hasn’t been updated in years, so the vendor-specific information is mostly obsolete. However, I’m sure you’ll still find the requirements, architectures, designs, and technology overviews sections relevant.

To watch more free ipSpace.net videos, browse them here, or click the Access Free Content button in any webinar roadmap.

After Kazuya Takahashi released his wonderful network-xray tool and added it as an external tool to the open-source BGP configuration labs, I wrote a short document explaining how to start external tools in your BGP labs without changing the lab topology, and how it works in GitHub Codespaces (hint: wonderfully).

I also modified all lab instructions to include a pointer to the optional tool-setup step.

Happy labbing ;)

TL&DR: Programmers writing Cisco Nexus OS code should have known better. They didn’t (care?).

One can understand that an operating system written in the late 1980s generates crappy suboptimal error messages, even though it was known even in those days how to do things right.

Is it too much to hope that the programmers writing newer operating systems (like Cisco Nexus OS) would be better? Obviously, it is 🤦‍♂️