Module Containerlab

Module: Containerlab

This page describes the Containerlab module for dot2net.

What is Containerlab?

Containerlab is a container-based networking lab platform that enables rapid deployment of network topologies using Docker containers. It supports various network operating systems (Nokia SR Linux, Arista cEOS, FRR, etc.) and provides a simple YAML-based topology definition.

• Official Website: https://containerlab.dev/
• GitHub: https://github.com/srl-labs/containerlab

What dot2net Generates

The Containerlab module generates topo.yaml, the topology definition file for Containerlab:

name: mylab
topology:
  nodes:
    r1:
      kind: linux
      image: quay.io/frrouting/frr:8.5.0
      binds:
        - r1/frr.conf:/etc/frr/frr.conf
      exec:
        - vtysh -b
  links:
    - endpoints: [r1:net0, r2:net0]

Generated Sections

Section	Source	Description
name	YAML name field	Lab name
nodes	DOT nodes	Node definitions with kind, image, binds, exec
links	DOT edges	Network connections between nodes

Automatic Features

• binds: Automatically generated from FileDefinitions that have path set
• exec: Generated from user-defined startup config block
• links: Generated from DOT edge definitions

Required Parameters

Each non-virtual node must have these parameters defined:

Parameter	Description	Example
image	Container image	quay.io/frrouting/frr:8.5.0
kind	Containerlab node kind	linux, srl, ceos

Define these in your NodeClass:

nodeclass:
  - name: router
    values:
      image: quay.io/frrouting/frr:8.5.0
      kind: linux

Optional: startup Config Block

The startup config block defines commands to run inside the container. This is used to generate the exec section in topo.yaml.

nodeclass:
  - name: router
    config:
      - name: startup
        template:
          - "vtysh -b"
          - "ip addr add {{ .ip_loopback }}/32 dev lo"

Behavior:

• If startup exists and is non-empty → exec section is generated
• If startup is missing or empty → exec section is omitted

Optional: File Bind Mounts

Files with path defined in FileDefinition are automatically mounted into containers:

file:
  - name: frr.conf
    path: /etc/frr/frr.conf    # This triggers bind mount generation
  - name: daemons
    path: /etc/frr/daemons

Generated binds:

binds:
  - r1/frr.conf:/etc/frr/frr.conf
  - r1/daemons:/etc/frr/daemons

Complete Example

input.yaml

name: ospf_lab
module:
  - containerlab
  - frr

file:
  - name: frr.conf
    path: /etc/frr/frr.conf
  - name: daemons
    path: /etc/frr/daemons

layer:
  - name: ip
    default_connect: true
    policy:
      - name: p2p
        range: 10.0.0.0/16
        prefix: 30

nodeclass:
  - name: router
    values:
      image: quay.io/frrouting/frr:8.5.0
      kind: linux
    config:
      - file: frr.conf
        template:
          - "hostname {{ .name }}"
          - "!"
          - "router ospf"
          - " router-id {{ .ip_loopback }}"
      - file: daemons
        sourcefile: ./daemons
      - name: startup
        template:
          - "vtysh -b"

input.dot

digraph {
  r1 [class="router"]
  r2 [class="router"]
  r1 -- r2
}

Generated topo.yaml

name: ospf_lab
topology:
  nodes:
    r1:
      kind: linux
      image: quay.io/frrouting/frr:8.5.0
      binds:
        - r1/frr.conf:/etc/frr/frr.conf
        - r1/daemons:/etc/frr/daemons
      exec:
        - vtysh -b
    r2:
      kind: linux
      image: quay.io/frrouting/frr:8.5.0
      binds:
        - r2/frr.conf:/etc/frr/frr.conf
        - r2/daemons:/etc/frr/daemons
      exec:
        - vtysh -b
  links:
    - endpoints: [r1:net0, r2:net0]

Running the Lab

After generating files with dot2net:

# Generate configuration files
dot2net build -c input.yaml input.dot

# Deploy the lab
sudo containerlab deploy -t topo.yaml

# Destroy the lab
sudo containerlab destroy -t topo.yaml

See Also

• Module System - How modules work
• File Output - File generation and bind mounts
• Module: TiNET - Alternative container-based platform
• Module: FRR - FRR configuration helpers