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 🤦‍♂️

When Donnie Savage announced the open beta of OpenEIGRP, I quickly asked him whether it would be possible to get an easy-to-use container with OpenEIGRP integrated with other FRR daemons (and its CLI).

Donnie delivered ;) – you can download a ready-to-use container and try its EIGRP features. Let’s see how you can make that process even simpler with netlab:

After his excellent Git for Networking Engineers series, Tony Mattke decided to take netlab for a spin (thank you!), starting with Install netlab, Build a Lab in Five Minutes

The DNS Museum documents tons of crazy uses of DNS, the world’s most distributed database (OK, a key-value store), including a “DNS for configuration management” podcast episode with Corey Quinn.

Have fun!

My initial “configuring Arista cEOS with Netmiko or Ansible” test was a bit biased. netlab generates the final configuration snippets in both cases (due to Ansible FUBARs we had to deal with), but then Netmiko just sends the configuration commands to the switch (after entering configuration mode), while the Ansible eos_config module executes show running, identifies the difference, and sends only the changes to the device.

While that use case is highly relevant (after all, we’re configuring network devices ;) I really should have done an apples-to-apples comparison, and FRRouting virtual machines are the ideal playground.

Now that we know what we need to make layer-3 services (BGP-free core transporting IPv4 and IPv6 traffic) work with SRv6, let’s go through the steps needed to configure them on Junos, continuing from the baseline SRv6 with IS-IS configuration (and again relying on the excellent SRv6 Micro-SID (uSID) Basics article by Krzysztof Szarkowicz).

In the BGP-Free Network Core with SRv6, we identified the components we need (assuming IBGP+IGP design):