MikroTik Cloud Hosted Router Images in containerlab

It's a slow day in the office. My US customers are busy gorging themselves with all of the good food that goes with US Thanksgiving and I'm not at all jealous. Really. I'm not. (Sigh.) Okay, I'm flat-out lying.

While I try to avoid thinking of turkey filled with delicious stuffing, I'll try to distract myself by likening that to containers filled with functional VMs. It's not a perfect analogy, but it will have to do.

Over the last little while, I've been migrating my networking labs from EVE-NG to containerlab, mostly because I really like the idea of pre-building my topologies and device configurations in templates rather than dragging and dropping new connections every time I want to to build something. That write-up will come soon, but for now I want to do a quick outline of what I did to make MikroTik's Cloud Hosted Router (CHR) easier to work with in this setup.

Using vrnetlab To Host a MikroTik CHR

Per the name of the product, containerlab works best with containers. This introduces an additional step if we want to include device images that run as VMs, like our MikroTik CHR. Thanks to vrnetlab, which wraps VM-based devices in a QEMU container, we can integrate these into our containerlab setups too.

RouterOS is available as a freely-downloadable VM (speed limited without licensing) from the MikroTik web site and is easily integrated into containerlab using the vrnetlab wrapper... if we only want the basics.

Optional RouterOS Packages

MikroTik devices and, by extension their virtual appliance, have a number of additional packages that provide functionality beyond what is shipped with the core RouterOS image. These are usually installed as needed after the device has completed its initial startup.

When we're using interactive products like EVE-NG, this isn't a problem because we can just add the packages as part of the setup. Using containerlab, the ideal is to be able to prescriptively define everything we need and bring it up at once without any need for additional interactive configuration. We want to get the lab up and running and get started without any further manual work.

This requires a change in our normal vrnetlab build, so let's go about it.

Build Steps

I'm going to assume that you already have containerlab installed, that Docker is running and that you're using a user that is set up to manage your containerlab installation. If you haven't got that far, I recommend taking a break to get that set up first. These next steps will break (and, frankly, aren't all that useful) without that in place.

Get vrnetlab

We'll start by using git to clone vrnetlab into our containerlab host.

Get the CHR Image

Then we'll enter vrnetlab's working directory and get the MikroTik CHR image. Version 7.20.4 is current at the time of writing, so adjust the chrVersion variable if it isn't at the time of reading.

This will leave us with a single chr-7.20.4.vmdk file. If we were building a basic RouterOS image for vrnetlab, we could just run "make" here , the script would load the image into Docker, and we would be ready to deploy labs. I want to make sure we have all of the optional functionality I mentioned earlier, so we're going to take some extra steps first.

Install QEMU

The changes we're making to the base image require that we run the CHR as a VM for a short period and we're going to need a hypervisor for that. I'm running Debian 12 (Bookworm) for my containerlab system, so the commands I'll use for this may be different from what you're using, but as long as you have QEMU available when you're done, we're good.

Launch the CHR Image

First, we'll rename the image to differentiate it from the base image. Depending on your needs, you may want to have both the base image and one with all of the optional packages installed.

Next, we'll launch the CHR image under QEMU.

Login To the CHR

The CHR will start up and we'll be presented with a login prompt. The default username on a CHR is "admin" and there is no default password, so just hit enter for this.

Once we're in, we'll see the splash screen and a prompt asking if we want to read the license. I've read it before, so I skip that part.

Next we'll be prompted to change the password. We won't be keeping the system configuration when we're done here, so there's not much point. Just press Ctrl-C to skip this and go to the initial prompt.

Add Optional Packages

Next, we'll install all of the optional packages.

We just downloaded the image moments ago, so there won't likely be any updates but the check will update the packages list, which is the important part. Executing the "print" command in the /system/packages context will show us all of the packages, marked as disabled but available.

There are a number of packages here that will probably never be needed in a containerlab installation, but I'm not going to second guess your requirements. Let's just enable them all, verify that they're scheduled, and apply the changes.

Verify Packages

We'll repeat the same login process we went through when we first launched the CHR. Just as before, there's no need to actually set an admin password. We'll be resetting the configuration when we're done here, so there's no point.

Next, we'll switch to the /system/package context and verify that the packages are installed.

If we see output similar to the above, everything is loaded and good to go.

Reset the CHR's Configuration

Once we have verified that the packages have been installed, we'll reset the CHR's configuration and shut it down to prepare it for the vrnetlab process.

The VM will now shut down and QEMU will drop us back to our vrnetlab prompt.

Runn vrnetlab

Now that the VM image is fully prepared with all of the optional packages, we can run "make" to produce the Docker image.

Verify That the Docker Image is Present

A quick run of "docker image ls" shows our new image is available for containerlab.

Updates

It's worth mentioning that upgrading the image is relatively easy. Just start the QEMU process again with the same "chr-7.20.4-full.vmdk" file that we left in ~/vrnetlab/mikrotik/routeros and follow the steps for installing the optional packages up to checking for updates. When we reach that point, we can install the update to RouterOS and all installed packages.

The VM will then reboot and come up with the updates installed. We can then reset the configuration like we did before.

At this point, we can rename the vmdk image to reflect the update and run "make" again to deploy the update image to our containerlab's Docker installation.

Conclusion:
Custom Images Offer Better Lab Flexibility

Now that we have a source image that contains all of the optional packages, we have much more ability to build predefined labs without having to be concerned about whether we need to do optional package installations. If we want to add a node that uses User Manager features or The Dude, that is now available to us without having to manually perform package installations and paste supplemental configurations after deployment.

I hope you find this useful as you explore RouterOS labbing with containerlab.