Some networking vendors realized that one way to gain mindshare is to make their network operating systems available as free-to-download containers or virtual machines. That’s the right way to go; I love their efforts and point out who went down that path whenever possible¹ (as well as others like Cisco who try to make our lives miserable).

However, those virtual machines better work out of the box, or you’ll get frustrated engineers who will give up and never touch your warez again, or as someone said in a LinkedIn comment to my blog post describing how Junos vPTX consistently rejects its DHCP-assigned IP address: “If I had encountered an issue like this before seeing Ivan’s post, I would have definitely concluded that I am doing it wrong.”²

The Junos vPTX DHCP FUBAR was a simple mistake, but it was impossible to diagnose or fix from the outside³. Also, it proved (to me) that the vPTX target audience is not people who run virtual machines in environments where the management IP address allocation is done via DHCP. I can’t imagine a scenario where someone doing the most rudimentary tests with something like vagrant-libvirt (or any other cloud environment) would miss that problem.

Unfortunately, it’s not just Juniper⁴. I built a Dell OS10 Vagrant box a few days ago, and its SSH server fails to start in approximately 30% of the cases, making it totally useless in any sort of CI/CD pipeline or any environment more complex than a virtual console cable attached to the virtual serial port. Here are sample netlab integration test results for Dell OS10; the crashed entries are caused by a failed SSH server (Vagrant couldn’t connect to the VM)⁵.

Based on what’s packed with the Dell OS10 image⁶, their target audience seems to be GNS3 users point-and-clicking their way around. Who am I to question their business decisions? However, it might be worth pointing out that an unreliable SSH server might scare away people believing in programmability and automation. Do they really want to compete with Cisco and Arista on who has a better lab GUI?

To make matters worse, someone mentioned the exact same problem on Dell community forum in 2022, and all he got back was effectively “we can’t help you as you’re not a paying customer” Seriously? Is that the way to gain mindshare?

But wait, it gets better. I also tried out the Dell Enterprise Sonic image. Its SSH server works (no surprise; it runs on mostly unmodified Linux), but the data plane doesn’t⁷. I don’t think that anyone trying to connect that VM to two Linux endpoints within a GNS3 system⁸ would get it to work without fixing the underlying problem, which (from my limited perspective) might indicate that nobody involved in the Dell Sonic release process ever tried to do that⁹.

Finally, there’s Nokia. People like Roman Dodin and Jeroen van Bemmel are doing a great job, only to have their hard work tarnished by stupidities like this one, which we had to “fix” with downgrading Ansible to release 4.10 and downloading nokia.grpc collection from GitHub (instead of Ansible Galaxy) when using Nokia devices in netlab. Nobody updated the nokia.grpc Ansible Galaxy collection in years (or merged a simple PR that would get rid of nokia.grpc collection crashing Ansible), and it took the Ansible team a year and a half to merge the fix on the Ansible side into release 9.5.1.

To wrap up:

• Making your software widely available has worked for numerous companies and might work for niche networking vendors.
• Regardless of the underlying motivation, we should loudly praise and support anyone releasing a no-strings-attached networking device VM or container image, and I will continue to do that.
• However, whatever you release in the wild should work in no-brainer scenarios, like running a DHCP client and accepting an address from a DHCP server on the management interface, having a working SSH server, or having a working data plane.
• You might want to attract people who think beyond GUI and console cables; they might appreciate a VM they can connect to via SSH.
• People you want to attract might be someone other than your paying customers, and the VM image you gave them will make a lasting impression. Have a support mechanism in place, or at least fix the glaring problems they point out (or even diagnose in some cases) in a timely manner.
• Finally, we all ship buggy code (I’m no exception), but what matters is the time it takes to fix it. It is unacceptable to take months to fix a broken DHCP client or years to merge one-line PRs.

Without all of the above, please don’t waste everyone’s time releasing images you claim could be used in virtual labs. A broken image does more harm than good.

Also, it’s not such a stretch goal. Arista vEOS/cEOS, Aruba CX, Cumulus, Cisco (ASAv, IOSv, IOS-XE, IOS-XR, NexusOS), Juniper vSRX, Mikrotik RouterOS7, Nokia SR Linux, and Vyos worked for me out of the box on the first try.