VyOS Networks VyOS#
Containerized VyOS network operating system is identified with the vyosnetworks_vyos
kind in the topology file.
VyOS nodes will launch with the following features
- Their management interface
eth0
configured with IPv4/6 addresses as assigned by the container runtime - Hostname assigned to the node name
- The VyOS HTTP API enabled
- Default credentials of
admin:admin
- Available SSH keys installed into the
admin
user authorized keys
Warning
VyOS node in Containerlab has only been tested with v1.5 Q1 Stream or higher
Getting VyOS image#
VyOS does not provide a native container; you must create a container from the ISO image that can be obtained in three ways:
- LTS release which requires paying for a subscription
- A release called Stream, this is the basis for what will become the next LTS release. Similar to CentOS Stream and RHEL
- A nightly rolling release with the bleeding edge changes
Once you've obtained an ISO you have to extract the squashfs filesystem and convert it to a container. VyOS provides instructions on their site on how to do this.
To simplify the process, you may use the following Dockerfile and script created for a Debian or its derivative (but can be adapted to another distribution).
Extract the filesystem#
# Install required tools
sudo apt-get update
sudo apt-get install -y squashfs-tools-ng libarchive-tools
bsdtar -xf vyos-1.5-stream-2025-Q1-generic-amd64.iso live/filesystem.squashfs
sqfs2tar live/filesystem.squashfs > rootfs.tar
Docker container#
FROM scratch
ADD rootfs.tar /
RUN for service in\
getty.target \
auditd.service \
;do systemctl mask $service; done && \
systemctl disable kea-dhcp-ddns-server.service
HEALTHCHECK --start-period=10s CMD systemctl is-system-running
CMD ["/sbin/init"]
Managing VyOS nodes#
VyOS nodes launched with containerlab can be managed via the following interfaces:
The VyOS HTTP API is running on the https port of the management interface. It uses the TLS certificate provided by containerlab. It uses the password as the API key.
Default user credentials#
User credentials: admin:admin
Interfaces mapping#
VyOS only allows interfaces in the format ethN
. The eth0
interface is reserved for the management interface
Features and options#
Node configuration#
VyOS nodes have a dedicated config
directory that is used to persist the configuration of the node. It is possible to launch nodes of vyosnetworks_vyos
kind with a basic config or to provide a custom config file that will be used as a startup config instead.
Default node configuration#
When a node is defined without startup-config
statement present, containerlab will generate an empty config from this template and copy it to the config directory of the node.
# example of a topo file that does not define a custom config
# as a result, the config will be generated from a template
# and used by this node
name: vyos_lab
topology:
nodes:
vyos:
kind: vyosnetworks_vyos
The generated config will be saved to the path clab-<lab_name>/<node-name>/config/config.boot
. Using the example topology presented above, the exact path to the config will be clab-vyos/vyos/config/config.boot
.
User defined config#
You may specify a customer startup configuration using the startup-config
property.
When a config file is passed via startup-config
parameter it will be used during an initial lab deployment. However, a config file that might be in the lab directory of a node takes precedence over the startup-config1.
It is possible to change the default config which every VyOS node will start with by specifying it in the topology.kinds.vyos.startup-config
name: vyos_lab
topology:
kinds:
vyosnetworks_vyos:
startup-config: vyos-custom-startup.cfg
nodes:
# vyos1 will boot with vyos-custom-startup.cfg as set in the kind parameters
vyos1:
kind: vyosnetworks_vyos
image: vyos:latest
# vyos2 will boot with its own specific startup config, as it overrides the kind variables
vyos2:
kind: vyosnetworks_vyos
image: vyos:latest
startup-config: node-specific-startup.cfg
links:
- endpoints: ["vyos1:eth1", "vyos2:eth1"]
-
if startup config needs to be enforced, either deploy a lab with
--reconfigure
flag, or useenforce-startup-config
setting. ↩