6WIND VSR#
6WIND VSR is identified with 6wind_vsr
kind in the topology file. A kind defines a supported feature set and a startup procedure of a 6wind_vsr
node.
6WIND VSR nodes launched with containerlab comes up pre-provisioned with SSH service enabled, root
and admin
user created and NETCONF enabled.
Getting 6WIND VSR image#
6WIND VSR images can be retrieved from your 6WIND customer portal. Free evaluation images with associated licenses are available upon registration.
Managing 6WIND VSR nodes#
6WIND VSR node launched with containerlab can be managed via the following interfaces:
Credentials#
Default credentials: admin:admin
Containerlab will automatically enable public-key authentication for the admin
user if public key files are found at ~/.ssh
directory.
Root access is also available but should not be used to configure 6WIND VSR nodes. The configuration entrypoint is the NETCONF server. The CLI is a local NETCONF client running inside the node.
Host server requirements#
6WIND VSR documentation lists the host requirements needed to run VSR as a container.
Among them, it is important to load the required kernel modules, as well as increasing the maximum number of inotify watchers.
To make the settings persist reboots append fs.inotify.max_user_instances=2048
and fs.inotify.max_user_watches=1048576
to /etc/sysctl.conf
. You can use the following one-liner:
echo -e "fs.inotify.max_user_instances=2048\nfs.inotify.max_user_watches=1048576" | sudo tee -a /etc/sysctl.conf
Interfaces mapping#
6WIND VSR container uses the following mapping for its interfaces:
eth0
- management interface connected to the containerlab management network
When containerlab launches a 6WIND VSR node, it will assign IPv4/6 address to the eth0
interface.
Data plane interfaces#
There is no restriction on the user-defined data interfaces name. Data plane interfaces needs to be configured with IP addressing manually.
Network interfaces added by containerlab to a 6WIND VSR node appears as infrastructure interfaces. They are probed at the container startup. The infrastructure interfaces are identified by a port name, corresponding to the name of the interface at container start. This port name stays the same during the container life, even if the interface is renamed or moved to another VRF. This output explains how to list the interfaces, and use them in the CLI
ssh admin@<containername>
Warning: Permanently added '<containername>' (ED25519) to the list of known hosts.
#######################################################################
# Welcome to 6WIND Virtual Service Router #
# #
# Most useful commands at that step: #
# #
# edit running # to edit the running configuration #
# show interface # for interface names, state and IP addresses #
# show summary # for the vRouter state summary #
# ? # for the list of available commands #
# help <cmd> # for detailed help on the <cmd> command #
# #
# Feel free to customize this banner using #
# cmd banner post-login message #
#######################################################################
Last login: Mon Mar 17 09:49:25 2025 from 3fff:172:20:20::1
gNodeB-north> show state / network-port
network-port infra-eth2
mac-address aa:c1:ab:a9:75:35
interface eth2
type virtual
..
network-port infra-eth1
mac-address aa:c1:ab:d8:3f:93
interface eth1
type virtual
..
network-port infra-eth0
mac-address 02:42:ac:14:14:09
interface eth0
type virtual
..
network-port pci-b2s2
bus-addr 0000:02:02.0
vendor VMware
model "VMXNET3 Ethernet Controller"
type physical
..
By default, the input packets received on an infrastructure interface is not received by the fast path (6WIND's accelerated networking stack), but directly by the control plane. Most of the time, this is a good option since these interfaces are used for management. To change this behavior, it is possible to add the network port to the fast path configuration. Here is a configuration example:
VSR> edit running
VSR running config# system fast-path virtual-port infrastructure infra-eth1
VSR running infrastructure infra-eth1# / vrf data interface infrastructure eth1 port infra-eth1
VSR running infrastructure infra-eth1# / vrf data interface infrastructure eth1 ipv4 address 192.168.0.1/24
VSR running infrastructure infra-eth1# commit
Configuration committed.
VSR running infrastructure infra-eth1# show interface vrf data
Name State L3vrf IPv4 Addresses IPv6 Addresses Description
==== ===== ===== ============== ============== ===========
lo UP default 127.0.0.1/8 ::1/128 loopback_data
eth1 UP default 192.168.0.1/24 fe80::a8c1:abff:fed8:3f93/64 infra-eth1
fptun0 UP default fe80::6470:74ff:fe75:6e30/64
As you see, the data plane interface eth1
is configured in the requested VRF.
Features and options#
Node configuration#
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.
Startup config#
It is possible to make 6WIND VSR nodes to boot up with a user-defined startup config. With a startup-config
property of the node/kind a user sets the path to the config file that will be mounted to a container:
With such topology file containerlab is instructed to take a file myconfig.conf
from the current working directory, copy it to the lab directory for that specific node under the init-config.cli
name and mount that file to the container. This will result in this config to act as a startup config for the node.
Note: The startup configuration will only be used if no user-defined configuration was saved as explained below. Also, the content of the default template is always appended to the configuration, in order to ease the connection to the container.
Devices#
6WIND VSR requires devices to be usable by the container. The following devices are automatically added when using the 6wind_vsr
kind:
- /dev/ppp
- /dev/net/tun
- /dev/vhost-net
Capabilities#
6WIND VSR required either to be run in privileged mode, or in non-privileged mode provided some capabilities. For now, containerlab executes all the containers in privileged mode. To make sure the 6wind_vsr
kind is not impacted if this default policy changes or becomes configurable, the list of capabilites required by the 6WIND VSR container is automatically added. Additional capabilities are listed below:
- NET_ADMIN
- SYS_ADMIN
- NET_BROADCAST
- NET_RAW
- SYS_NICE
- IPC_LOCK
- SYSLOG
- AUDIT_WRITE
- SYS_PTRACE
- SYS_TIME
Saving configuration#
With containerlab save
command it's possible to save running 6WIND VSR configuration into a file. 6WIND VSR nodes have a dedicated config
directory that is used to persist the configuration of the node. The configuration will be saved by user-startup.conf
path in the relevant node directory. When present, this file will be used as a startup configuration instead of the file provided by the startup-config
property of the node/kind.
License#
6WIND VSR containers require a license. The license serial is provided through the configuration.
Container configuration#
Please refer to 6WIND VSR User's guide for the configuration of the node.