DOCSEARCHbyAlgolia
Submit Docs

Labctl Documentation

website·Indexed 31 days ago

https://labctl.net/

A collection of helper tools for network engineers to configure and experiment with network topologies. Features include a Config Engine shared with containerlab, a web user interface for topology visualization, template functions for configuration, and a CLI for managing settings and transmitting commands.

Tokens
5.3K
Snippets
41
Records
51
Agent score
50%

What's inside Labctl

  1. Overview of Labctl for network engineers

    Labctl is a collection of helper tools for network engineers to use while configuring and experimenting with network labs. It uses the containerlab topology file format (.clab.yml) to represent network topologies, but it is compatible with labs running on EVE-NG, GNS3, or physical network equipment. It is designed to act as a companion to containerlab.

  2. Overview of the Config Engine

    The Config Engine combines Golang's Text Templates with network topology knowledge to render CLI snippets. It allows developers to declare logical variables in the topology, template network links and nodes using local and far-end variables, and send commands to routers based on their specific kind. The engine is shared between labctl and containerlab, meaning command line flags for configuration can be used via either labctl config or containerlab config.

  3. Deploy and manage sros4 network topology with labctl

    To deploy a network topology using the sros4.clab.yml file and manage its configuration (including Ports and ISIS) via labctl, follow these steps: deploy the topology, compare the base configuration against templates, and commit the base configuration.
    # 1. Deploy the topology
containerlab deploy -t sros4.clab.yml

# 2. Compare base config using templates
labctl config compare -p ./templates -l base -t sros4.clab.yml

# 3. Deploy the base config
labctl config commit -p ./templates -l base -t sros4.clab.yml

  4. Deploy and serve a lab from the labctl-examples repository

    Each example in the labctl-examples repository includes a README.md with specific deployment instructions.

    1. Deploy the topology: Navigate to the lab's directory and run containerlab deploy. Containerlab will auto-detect the topology file if only one exists in the folder.
    2. Start the server: Run labctl serve. To specify one or more paths where the server should look for templates, use the -p or --paths flag.
    # Deploy the lab
containerlab deploy

# Start the server with specific template paths
labctl serve -p /path/to/templates

  5. Transmit rendered templates to nodes using Config Engine

    After rendering templates, labctl can transmit them to nodes via SSH. Depending on the node's capabilities, you can send plain commands or use transactions. The engine pre-processes templates by removing empty whitespace (including blank lines and leading/trailing whitespace) and removing comments if supported by the node config.

    Commands available for transmission:

    • config send: Sends generated text to the node (typically for 'show' commands; no configuration session is started).
    • config compare: Starts a configuration privilege level and a transaction to compare results and discard changes.
    • config commit: Starts a configuration privilege level and executes a commit transaction.

  6. Install Bash command completions for labctl

    Bash command completions are available for labctl (powered by the Kongplete library). Note that this feature is currently marked as work-in-progress and may require additional predictors for full functionality.

  7. Understand Config Engine transport and platform mapping

    The Config Engine maps Containerlab 'Kinds' from the topology file to Scrapligo platforms. These platforms define how to authenticate and handle privilege level changes for configuration. The mapping of Kinds to platforms, including specific comment characters and commit/compare commands, is managed within the labctl source code.

  8. Inspect magic variables in the UI

    The Config Engine UI allows you to inspect the 'magic variables' used to render templates for specific nodes. For example, if a node in the topology file has defined vars (such as clab_system_ip or isis_iid), these are visible in the UI for testing against templates.
     nodes:
  R4:
    kind: nokia-srsim
    config:
      vars:
        clab_system_ip: 192.0.2.4/32
        ipv4_sid_label: 14004
        isis_iid:
          - 1

  9. Start the Config Engine web server

    The Config Engine UI is started using the labctl serve command. After execution, the server provides URLs (e.g., localhost or a specific IP) to access the web interface via a browser.
    labctl serve -t topo.clab.yaml -p ./ --addr :8080

  10. Install Labctl on Linux

    Labctl is distributed as a single executable for Linux-based distributions. It can be installed using a shell script via curl.
    bash -c "$(curl -sL https://labctl.net/get.sh)"

  11. Auto-generate link IPs using clab_system_ip

    When clab_system_ip is defined for nodes, the Config Engine automatically generates clab_link_ip values. It uses the last octet of the loopback addresses of the two connected nodes (<n1> and <n2>, where n1 < n2) to create a /31 subnet: 10.<n1>.<n2>.<side>/31. The <side> is 0 for the node with the smaller octet and 1 for the larger. For multiple links, clab_link_num is used to ensure uniqueness by adding 2 x <clab_link_num> to the side index.
    topology:
  nodes:
    pe1:
      config:
        vars:
          clab_system_ip: 10.0.0.1/32
    pe2:
      config:
        vars:
          clab_system_ip: 10.0.0.2/32

  links:
    - endpoints: ["pe1:eth1", "pe2:eth1"]

  12. Target non-containerlab labs with labctl

    labctl can target physical nodes or nodes deployed via other methods (such as virsh) as long as a valid topology file is provided. Use the ssh_host and ssh_port variables in the topology file to point to the external infrastructure.