Containerlab Guide: Build Multi-Vendor Network Labs with Docker

Building a lab used to mean hardware, licenses and a spare rack. Containerlab replaces that with containers: you describe the topology in a short YAML file, and it wires virtual routers and switches together, allocates management addresses and gives you a repeatable environment that fits in a CI pipeline. This guide covers installation, the topology definition file, links and management networks, startup configurations, and the lifecycle commands you will use every day.

Install and check your environment

bash -c "$(curl -sL https://get.containerlab.dev)"
containerlab version

docker pull ghcr.io/nokia/srlinux
docker pull ceos:latest                 # Arista cEOS (from Arista support)
docker pull frrouting/frr:latest        # free, Linux-based router

Docker must be running and your user should be in the docker group. If you have no vendor images, FRRouting, Linux containers and Nokia SR Linux are all freely available and enough to build a convincing BGP/OSPF lab.

The topology file

name: dc-lab

mgmt:
  network: clab-mgmt
  ipv4-subnet: 172.20.20.0/24

topology:
  nodes:
    spine1:
      kind: linux
      image: frrouting/frr:latest
      binds:
        - configs/spine1:/etc/frr/frr.conf
    spine2:
      kind: linux
      image: frrouting/frr:latest
    leaf1:
      kind: linux
      image: frrouting/frr:latest
    leaf2:
      kind: nokia_srlinux
      image: ghcr.io/nokia/srlinux
      startup-config: configs/leaf2.cfg
  links:
    - endpoints: ["spine1:eth1", "leaf1:eth1"]
    - endpoints: ["spine1:eth2", "leaf2:eth1"]
    - endpoints: ["spine2:eth1", "leaf1:eth2"]
    - endpoints: ["spine2:eth2", "leaf2:eth2"]

Each node needs a kind (which tells containerlab how to treat the container) and an image. Endpoints name a node and an interface - the interface name must exist inside the container, so consult the kind's documentation for the naming (.e.g. cEOS uses eth1 onward, SR Linux uses e1-1).

Deploy, inspect, destroy

containerlab deploy -t dc-lab.clab.yml
containerlab inspect -a
containerlab inspect --format json | jq '.containers[].name'

docker exec -it clab-dc-lab-leaf1 vtysh
# inside the lab: configure, then exit back to the host

containerlab graph -t dc-lab.clab.yml      # SVG of the topology
containerlab destroy -t dc-lab.clab.yml
containerlab destroy -t dc-lab.clab.yml --cleanup

Deployment prints a table with container names and management IP addresses; those addresses are how you SSH or attach to each node. Use --cleanup when you want the management network and artefacts removed as well, which prevents address-pool exhaustion on long-lived lab hosts.

Management network and external access

# publish a node port to the host for browser access
topology:
  nodes:
    leaf2:
      kind: nokia_srlinux
      image: ghcr.io/nokia/srlinux
      ports:
        - 8443:443

Containerlab creates a bridge for the management network, so every node is reachable from the lab host and from your workstation if you route the 172.20.20.0/24 subnet. This is what lets you point Ansible, NAPALM, pyATS or a NetBox-driven pipeline at lab devices that look and behave like real ones.

Startup configuration and version control

Keep configs/ in Git next to the topology file, one file per node, and reference them either with startup-config or with binds. That gives you a lab that can be rebuilt identically after any disaster - and the same repository becomes the test fixture for automation. For more advanced setups, containerlab supports magic variables such as __clabNodeName__ and shared binds, so one template file can serve every node in a large fabric.

What to do with a lab

Test the change before production: BGP policy changes, EVPN-VXLAN designs, MLAG failure scenarios, upgrade procedures, automation playbooks. Because the environment is disposable, you can also break it deliberately, which is the cheapest way to learn how a protocol actually fails. Related reading: CloudVision and AVD with containerlab, Linux namespaces and veth pairs (what makes this all possible), Docker networking drivers and Open vSwitch basics.

原文链接：https://containerlab.dev/manual/topo-def-file/