Tag: Network Modeling

Network Modeling: Automating Mikrotik RouterOS CHR Containerlab images

Nate Gotz Leave a comment

Introduction

In a previous post, we talked about using Containerlab and ZeroTier to provide remote access to a lab instance. One of the things that was glossed over was creating the Containerlab images. As part of building the images, Containerlab ready Mikrotik RouterOS images are available on Docker Hub.

Containerlab images

Containerlab currently supports 2 different kinds of images: pre-built containers and VMs packaged as containers.

Presently, only a handful of NOS vendors provide pre-built containers (Nokia’s SR Linux, Juniper cRPD, Arista cEOS, Cumulus VX, and SONIC VS).

The other option utilizes vrnetlab and is essentially a QEMU VM packaged in a Docker container. The more traditional network operating systems are currently supported via this method. This includes operating systems like Mikrotik RouterOS, Juniper vMX, Nokia SROS, and many more.

http://iparchitechs.com/contact

Building Mikrotik RouterOS containers

Containerlab provides a nice and easy way to build Containerlab ready Docker images. The process is fairly simple.

Setting it up

Containerlab uses a custom fork of vrnetlab that sets things up so that the images built will work with Containerlab. That repository can be found on Github. The first step is to clone that repository.

The next step is to download the image(s) you want from Mikrotik’s website. The VMDK files should be put into the routeros folder

Make it

Once you download the image(s) you want to run into the vrnetlab/routeros folder, navigate to that folder. Then all you need to do is run:

 make docker-image

This will build all of the vmdk files you have into Docker images.

Once the make file runs, you can verify that the images are usable in Docker by running:

docker image ls

You should then see all of the images you had built named in the vrnetlab/vr-routeros:<tag> style.

Pre-built Mikrotik RouterOS containers

The previous methodology works really good if you only want to run images on the same machine you build them. One of the key concepts of Containerlab is that the labs are portable.

At IP Architechs, we’ve made that easier. Instead of needing to build the images yourself locally, you can find all of the prebuilt Mikrotik RouterOS containers on Docker Hub.

New Mikrotik CHR releases will be pushed to Docker Hub within a couple of hours of them being released by Mikrotik.

The images released on Docker Hub also have the trees that Mikrotik uses (long-term, stable, testing, and development). Using these tags will get you the most recent release of that tag.

Using in Containerlab

Using these images in Containerlab is now even easier than before having to build your own containers.

The previous GitHub repository is already setup to use the new images. If you want all nodes running the same version, it’s as simple as:

name: lab1-pod1
topology:
  kinds:
    vr-ros:
      image: docker.io/iparchitechs/chr:long-term
  nodes:
    R1:
      kind: vr-ros
    R2:
      kind: vr-ros
    R51:
      kind: vr-ros

If you’re trying to emulate a network with many different versions, something like this is how it would be setup:

name: lab1-pod1
topology:
  nodes:
    R1:
      kind: vr-ros
      image: docker.io/iparchitechs/chr:6.47.10
    R2:
      kind: vr-ros
      image: docker.io/iparchitechs/chr:7.1.rc7
    R51:
      kind: vr-ros
      image: docker.io/iparchitechs/chr:6.34.3

Network Modeling: Segmented Lab access with Containerlab and ZeroTier

Nate Gotz 4 Comments

Introduction

When building out network labs, often multiple people will need access to the lab. The main way right now is to use something like EVE-NG or GNS3 to provide access.

There are 2 downsides to this method. The first is that your server is exposed to the internet and if your usernames/passwords aren’t strong enough, your server can become compromised. The second is that sometimes you may not want everyone to be able to add or edit to the lab topology.

The solution to this is using Containerlab and ZeroTier. This setup is great for things like testing new hires, training classes, or for providing lab access to others on a limited basis.

What is Containerlab?

Containerlab is a container orchestrating tool for managing container-based networking labs. It doesn’t just support Container based Network Operating Systems though. Through vrnetlab, there is support for a wide variety of commonly used NOSes: Mikrotik RouterOS, Nokia SROS, Juniper vMX and vQFX, and many more.

Configs are text based making it easy to add/update links between nodes. The lab does need to be destroyed and redeployed when adding/removing links. With some tools to generate configs, it’s easy to spin up a 500+ node lab in under 30 minutes.


http://iparchitechs.com/contact


What is ZeroTier?

ZeroTier is a mesh VPN that allows for Layer 2 connectivity. It is typically used in a remote worker scenario to provide access to internal company resources. In our case, we use it to provide remote lab access.

Setting it up

This assumes that Containerlab and ZeroTier are already setup on the lab server. One thing that will be needed on the lab server is to enable ip forwarding. Otherwise, the lab server won’t be able to forward packets.

Sample labs showing the changes needed between labs are available in a repo. The main differences between the labs are the lab names and management networks. In the sample labs, we hardcode the management IP addresses to make access easier. This isn’t necessary but makes it easier when not using DNS.

Multiple Pod Network layout

Once the labs are deployed, you should be able to SSH into all of the nodes from the server.

Then you need to setup a ZeroTier network. The first step is to add a route to the managed route pointing from the lab network to the server IP address (we set the server IP address to 172.22.0.1).

172.16.0.0/16 is the lab network(s). 172.22.0.0/16 is the user network

If you’re not worried about preventing cross pod access, you are all set. But if you want to secure access to each pod to prevent end users from accessing each others lab pod, some rules need to be added to the ZeroTier network. Those can be found in the GitHub repo file named zerotier.rules.

Then you can set your server to prevent user to user traffic.

To provide user access to their pod, select the correct capabilities for the pod

Using the lab

With the lab setup with the security features, you should be able to access the nodes via SSH or Winbox.

Super interesting screenshot of a blank Winbox

With the ZeroTier rules in place, you are not able to reach the other running pods.