> For the complete documentation index, see [llms.txt](https://en.itmatic101.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://en.itmatic101.com/networking/supercharge-your-networking-lab-with-containerlab.md). # Supercharge your networking lab with Containerlab Recently, I discovered that the Containerlab development team released a plugin for VSCodium that provides an integrated GUI experience for managing Containerlab environments. The plugin looked promising, so I decided to try it and explore what it could bring to my workflow. At first, I was not entirely convinced about the need for a graphical interface for Containerlab. I generally prefer lightweight tools and tend to avoid adding extra layers to my setup, especially on my small desktop machine. Since Containerlab itself is already straightforward and works well from the command line, I initially assumed the plugin was simply a visual wrapper around existing functionality. After spending some time with it, I found that the plugin offers considerably more than just a graphical interface. Beyond simplifying topology visualization and management, it also integrates additional functionality directly into the VSCodium environment, making the overall workflow more streamlined and convenient. To get started, the first step is installing the Containerlab plugin in VSCodium. Open the Extensions section, search for **Containerlab**, and install the plugin as shown below.
Previously, I used GNS3 as the primary platform for building and testing my networking labs across various network devices. While GNS3 is feature-rich and capable of handling complex topologies, I found that Containerlab was significantly lighter and simpler for my specific use case and overall lab environment. Most of my networking experiments and learning activities are centered around MikroTik RouterOS, as it is also the primary platform used within my home network and homelab infrastructure. Migrating to Containerlab felt like a natural choice since it allows me to build and deploy network topologies with minimal overhead while keeping the setup clean and easy to manage. To evaluate how well it fit into my workflow, I started with a basic OSPF lab using MikroTik RouterOS version 7. The following topology configuration file was used to build the environment. ``` name: mtlab topology: nodes: rt1: kind: mikrotik_ros image: docker.io/iparchitechs/chr:stable startup-config: rt1-config.rsc rt2: kind: mikrotik_ros image: docker.io/iparchitechs/chr:stable startup-config: rt2-config.rsc rt3: kind: mikrotik_ros image: docker.io/iparchitechs/chr:stable startup-config: rt3-config.rsc rt4: kind: mikrotik_ros image: docker.io/iparchitechs/chr:stable startup-config: rt4-config.rsc rt5: kind: mikrotik_ros image: docker.io/iparchitechs/chr:stable startup-config: rt5-config.rsc rt6: kind: mikrotik_ros image: docker.io/iparchitechs/chr:stable startup-config: rt6-config.rsc rt7: kind: mikrotik_ros image: docker.io/iparchitechs/chr:stable startup-config: rt7-config.rsc rt8: kind: mikrotik_ros image: docker.io/iparchitechs/chr:stable startup-config: rt8-config.rsc rt9: kind: mikrotik_ros image: docker.io/iparchitechs/chr:stable startup-config: rt9-config.rsc sw1: kind: mikrotik_ros image: docker.io/iparchitechs/chr:stable startup-config: sw1-config.rsc pc1: kind: mikrotik_ros image: docker.io/iparchitechs/chr:stable startup-config: pc1-config.rsc pc2: kind: mikrotik_ros image: docker.io/iparchitechs/chr:stable startup-config: pc2-config.rsc pc3: kind: mikrotik_ros image: docker.io/iparchitechs/chr:stable startup-config: pc3-config.rsc pc4: kind: mikrotik_ros image: docker.io/iparchitechs/chr:stable startup-config: pc4-config.rsc pc5: kind: mikrotik_ros image: docker.io/iparchitechs/chr:stable startup-config: pc5-config.rsc pc6: kind: mikrotik_ros image: docker.io/iparchitechs/chr:stable startup-config: pc6-config.rsc links: - endpoints: [ "sw1:eth1", "rt1:eth1" ] - endpoints: [ "sw1:eth2", "rt2:eth1" ] - endpoints: [ "sw1:eth3", "rt3:eth1" ] - endpoints: [ "rt2:eth2", "rt3:eth2" ] - endpoints: [ "rt2:eth3", "rt4:eth1" ] - endpoints: [ "rt2:eth4", "rt5:eth1" ] - endpoints: [ "rt2:eth5", "rt6:eth1" ] - endpoints: [ "rt3:eth3", "rt7:eth1" ] - endpoints: [ "rt3:eth4", "rt8:eth1" ] - endpoints: [ "rt3:eth5", "rt9:eth1" ] - endpoints: [ "rt4:eth2", "pc1:eth1" ] - endpoints: [ "rt5:eth2", "pc2:eth1" ] - endpoints: [ "rt6:eth2", "pc3:eth1" ] - endpoints: [ "rt7:eth2", "pc4:eth1" ] - endpoints: [ "rt8:eth2", "pc5:eth1" ] - endpoints: [ "rt9:eth2", "pc6:eth1" ] ``` The above represents the final state of the OSPF lab running in Containerlab. In this setup, the startup-config: parameter is used to automatically load pre-configured settings for each device during deployment. This approach allows the lab environment to be provisioned with a fully functional configuration from the beginning, eliminating the need for manual device configuration after startup. The complete lab files, including the topology definition and device startup configurations, are available in the GitHub repository - The repository contains all required files to reproduce the lab environment and deploy it directly within Containerlab. The following screenshot shows how the topology is presented through the Containerlab plugin integrated into VSCodium.
To deploy the lab environment, simply right-click on the `mt-ospf.clab.yml` topology file and select **Deploy** from the context menu.
Once the deployment process is complete, the lab becomes fully operational with all links established and displayed in green, indicating active connectivity between the nodes. Since the topology uses predefined startup configurations, the devices are immediately ready for testing without requiring any additional manual setup.
The VSCodium plugin also provides useful troubleshooting and analysis capabilities. For example, you can right-click on any link within the topology and start a packet capture directly in Wireshark for traffic inspection and protocol analysis.
What makes this especially interesting is that the entire topology operates on containerized network nodes running in Docker behind the scenes. Containerlab abstracts much of the complexity, making it possible to build lightweight, fast, and highly flexible network labs with minimal resource consumption. It is a remarkably powerful approach for creating reproducible networking environments.
Here is the view from the **rt1** router located at the top of the topology. It displays the learned OSPF routes from across the entire network, along with the local OSPF configuration applied to the device.
The output also includes basic connectivity validation, including ping tests to verify end-to-end reachability across the lab. This confirms that OSPF adjacency has been successfully established and that route propagation is functioning as expected throughout the topology. Once you have finished working on the networking lab, cleaning up the environment is straightforward. Simply right-click on the active running lab and select **Destroy**.
This will remove the deployed topology along with its associated containers and virtual links, freeing up system resources and returning the environment to a clean state. Since Containerlab provisions the lab dynamically, the entire topology can be recreated again at any time using the same configuration files, making the workflow efficient and reproducible. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://en.itmatic101.com/networking/supercharge-your-networking-lab-with-containerlab.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.