Author Archives: ipSpace.net blog
Author Archives: ipSpace.net blog
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 configuration1.
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 🤦♂️
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 article1 by Krzysztof Szarkowicz).
In the BGP-Free Network Core with SRv6, we identified the components we need (assuming IBGP+IGP design):
I decided to make Netmiko the default configuration deployment method netlab uses for Cisco IOS XR. It works great, and I don’t have to worry about whether the user runs IOS XRd control-plane (in which case scripts work) or vRouter (in which case there’s a VM inside the container, so no luck).
After fixing the initial glitches (more on that another time), all integration tests passed except the OSPFv2 default origination test. It turns out the default waiting time (30 seconds) is way too low; Cisco IOS XR needs almost 90 seconds (after its reboot completes) to originate the OSPFv2 default route.
With the growing number of SRv6 implementations that netlab supports, it made sense to create a set of topologies to help you get started exploring the SRv6 world. The sample topologies include:
Read the getting started document and have fun exploring the scenarios 😎
We launched device configuration with Netmiko in the September 2026 netlab release and made it easier to use in the October 2026 release. It will become the default configuration method for several popular platforms (Arista EOS, Cisco IOS, Cisco Nexus OS, Cisco IOS XR, FRRouting virtual machines) in a few months, but before doing that, I wanted to check whether the change matters.
TL&DR: Yes, it does.
The Network Automation Forum is running the annual State of Network Automation Survey (here are the 2025 results).
If you’re involved in network automation in any way (I hope you are), please take a few minutes and complete it. Thank you!
The concept of a BGP-free core is decades old: