Deploying Initial Device Configurations¶
netlab initial command uses expanded Ansible inventory data created with netlab create command, device-specific Jinja2 templates, and an internal Ansible playbook to deploy initial device configurations.
After a successful completion of the Ansible playbook, netlab initial displays the help message defined in the lab topology.
The Ansible playbook invoked by netlab initial command deploys device configurations in three steps:
Initial device configurations1
Module-specific device configurations2
Custom configuration templates3
Jinja2 templates are used together with device_config Ansible modules to configure most devices. In some cases, the configuration task list includes additional tasks4. Some devices (for example, Fortinet firewall) are configured through calls to device-specific Ansible modules. See Platform Caveats for more details.
When run with -v parameter, the command displays device configurations before deploying them.
netlab initial command does not need a topology file; It’s just a thin wrapper around an Ansible playbook which uses Ansible inventory created by netlab create or netlab up command. You don’t have to specify the topology file name or other netlab create CLI parameters you used to tweak the lab topology.
usage: netlab initial [--log] [-q] [-v] [-i] [-m [MODULE]] [-c] [--fast] [-o [OUTPUT]] Initial device configurations optional arguments: -h, --help show this help message and exit --log Enable basic logging -q, --quiet Report only major errors -v, --verbose Verbose logging -i, --initial Deploy just the initial configuration -m [MODULE], --module [MODULE] Deploy module-specific configuration (optionally including a list of modules separated by commas) -c, --custom Deploy custom configuration templates (specified in "config" group or node attribute) --fast Use "free" strategy in Ansible playbook for faster configuration deployment -o [OUTPUT], --output [OUTPUT] Create a directory with initial configurations instead of deploying them All other arguments are passed directly to ansible-playbook
Initial Device Configurations¶
Initial device configurations are created from inventory data and templates in
netsim/ansible/templates/initial directory. Device-specific configuration template is selected using
ansible_network_os value (making IOSv and CSR 1000v templates identical). See Deploying Device Configurations for more details.
The following initial configuration parameters are supported:
interface IPv4 and IPv6 addresses
interface MAC addresses
interface bandwidth (when supported by the device)
The initial configuration also includes LLDP running on all interfaces apart from the management interface (not configurable).
Default passwords and other default configuration parameters are supposed to be provided by the Vagrant boxes.
Module-specific device configurations are created from templates in
netsim/ansible/templates/_module_ directory. Device-specific configuration template is selected using
Custom Deployment Templates¶
Custom deployment templates are specified in config group- or node parameter.
initial-config.ansible playbook tries to find the target configuration template in user- (current) and system (
netsim/extra) directories and uses node name,
ansible_network_os Ansible variables to allow you to create numerous device-specific configuration templates.
You’ll find more details in Deploying Device Configurations contributor documentation.
netlab initial command assumes you want to deploy the custom templates in the order you specified them and therefore deploys them on a single device at a time unless you use the
Numerous Ansible versions “optimize” task execution by rearranging the order of loop parameters, potentially resulting in custom configurations being applied out of order. As a workaround, the Ansible play deploying custom configuration templates executes on a single device at a time.
You can bypass that safety measure with
--fast parameter, but don’t complain if you get unexpected results.
Limiting the Scope of Configuration Deployments¶
-m flag, the command deploys all initial configurations. To control the deployment of initial configurations:
-iflag to deploy initial device configurations.
-mflag to deploy module-specific configurations.
-mflag followed by a module name (example:
-m ospf -m bgp) to deploy device configuration for specific modules. You can use the
-mflag multiple times.
-cflag to deploy custom configuration templates.
All unrecognized parameters are passed to internal
initial-config.ansible Ansible playbook. You can use ansible-playbook CLI parameters to modify the configuration deployment, for example:
-lparameter to deploy device configurations on a subset of devices.
-Cparameter to run the Ansible playbook in dry-run mode. Combine it with
-vparameter to see the configuration changes that would be deployed5
Debugging Initial Configurations¶
-oflag to create device configurations without deploying them. The optional value of
-oparameter specifies the output directory name (default:
To display device configurations from within the Ansible playbook without deploying them, use
-v --tags testflags (a bogus playbook tag disables configuration deployment).
-iflag or initial Ansible tag
-mflag or module Ansible tag
-cflag or custom Ansible tag
Cisco Nexus OS configuration cannot proceed until the Ethernet interfaces are ready – that can take up to a minute after the VM boot completes. Arista cEOS cannot be configured until its SSH daemon starts.
The Ansible playbook uses vtysh on Cumulus VX to deploy the FRR-related configuration changes from a file. The dry run will not display the configuration changes.