This chapter describes Zero Touch Provisioning (ZTP) on SR Linux.Traditional deployment of new nodes in a network is a multistep process where the user has to connect to the hardware and provision global and local parameters.
ZTP automatically configures the nodes by obtaining the required information from the network and provisioning them with minimal manual intervention and configuration. The technician installs the nodes into the rack and when power is applied, and if connectivity is available, the nodes are auto-provisioned.
The following implementation is currently supported:
For auto-boot using the OOB port, the node storage device ships with the SR Linux image and the grub.cfg. Within the grub.cfg is an auto-boot flag. The correct part number should be ordered to obtain the grub.cfg with the auto-boot flag enabled by default. The flag can be manually changed if needed.
When the SR Linux boots, it checks the grub.cfg for the auto-boot flag. If the flag is set, the node goes into the auto-boot mode.
When initiated, the auto-boot mode starts the auto-provisioning process. The auto-provisioning process discovers the IP address of the node and provisions the node based on a Python provisioning script.
The DHCP server provides the node with the location of the provisioning script using Option 66 and 67, or Option 43. The node uses this URL to download the provisioning script. The provisioning script contains the location of the RPMs, configurations, images, and scripts. These files are downloaded to the storage device.
During provisioning, all events are logged and displayed at the console for debugging. After the process completes, the auto-boot flag is removed from the grub.cfg file. This ensures that after a successful auto-boot, additional reboots of the node will not enter auto-boot mode.
ZTP requires the following components:
ZTP works in the following network environments:
Figure 2 shows the first scenario where all components are in a Layer 2 broadcast domain. There is no DHCP relay and all IPs are assigned from a single pool.
Figure 3 shows the second scenario where only the HTTP file servers and DHCP server are in the same subnet. The DHCP relay is used to fill Option 82 as the gateway address. The gateway address is used to find the appropriate pool in the DHCP server to assign the correct subnet IP address to the SR Linux.
The DHCP offer allows the Option 3 router to define the default gateway. If multiple addresses are provided via Option 3, the first address is used for the default gateway.
Figure 4 shows the third scenario where all components are in different subnets. The DHCP relay adds the Option 82 gateway address to the DHCP request, and the DHCP server adds the Option 3 with the gateway address of the HTTP file server.
When the node reboots, the SR Linux starts the auto-boot process if the auto-boot flag is set in the grub.cfg. Currently only the management port is supported for auto-boot.
DHCP discovery is sent out from a management port that is operationally up with un-tag format when OOB is used. IPv4 DHCP discovery is sent out first, and if no offer is received within the DHCP timeout, an IPv6 DHCP solicitation will be sent out. The DHCP timeout is 60 seconds.
When the DHCP server receives the discovery packet, it will assign the IP address to the node. The DHCP offer for IPv4 requires the options shown in Table 4.
Option | Name | Description |
viaddr | Client-Ip-Address | Network interface – IP address (for network consistency, a fixed IP address is recommended vs randomly assigned from the DHCP server IP pool) |
1 | Subnet Mask | Network interface – Subnet mask |
3 | Router | Network interface – Default gateway (Only the first router is used. Additional routers are ignored.) |
51 | Lease Time | Validated to be infinite |
54 | Server Address | DHCP server identifier |
66 | Boot server host name | Server IP address |
67 | Bootfile Name | URL or IP to the provisioning file |
Table 5 lists DHCP IPv4 and IPv6 equivalents.
Option | IPv4 option | IPv6 Option | IPv6 Comments |
Client ID | Option 61 | Option 1 (DUID) | 2 - Vendor-assigned unique ID (default) 3 - Link-layer address |
NTP server | Option 42 | Option 56 | — |
User class | Option 77 | Option 15 | — |
TFTP server name | Option 66 | NA | — |
Bootfile name | Option 67 | Option 59 | — |
Vendor-specific options | Option 43 | Option 17 | — |
Defined options determine how DHCP discovery functions.
The client ID used in IPv4 and IPv6 can be configured as a chassis serial ID or chassis MAC address. By default, the chassis serial ID is used, but the user can configure the auto-boot option to use the chassis MAC address. This option can be configured by editing the grub.cfg and adding the -mac sub-option to the auto-boot option:
grub.cfg location: /nokiaboot/boot/grub2/grub.cfg or /mnt/boot/boot/grub2/grub.cfg
The ZTP timeout default is set at 1 hour for each attempt. During the provisioning process, the node will perform three attempts for a period of 3 hours (1 hour for each attempt). After the three initial attempts, the node reboots. The user can change the 1 hour default using the ZTP CLI.
See sections Configuring ZTP and ZTP CLI and SR Linux CLI command structures for procedures and commands used to provision available options.
DHCP will provide an NTP server URL using Option 42 (for IPv4) or Option 56 (for IPv6). When the time is obtained and synchronized from the NTP server, any log event obtained after this time will have the correct timestamp. Any log event before the time was obtained will not have the correct timestamp, and will have the default timestamp.
OOB auto-boot supports both IPv4 discovery and IPv6 solicitation, but when the offer is received, the provisioning script follows the same address family format for file download as the DHCP offer.
The first DHCP offer received with the correct Option 66 and 67 or Option 43 is used. The Python provisioning script is downloaded from the location defined by Option 66 and 67 or Option 43.
With an IPv4 DHCP offer, the node IP address and other information, such as the default route, is included.
For IPv6, only the IP arrives from the DHCP server. This offer does not include a prefix, and when it is received, the route is installed with a prefix of /128. This means that the prefix received from the RA is ignored, and the node always acts as a host with a prefix of /128. The default route is received from the Route Advertisement (RA) from the IPv6 peer.
After the DHCP offer is received, the Option 3 router can be used to program the default gateway on the SR Linux. A static route should be configured with the default route 0.0.0.0/0 as the next-hop IP address (provided by the Option 3 router).
The DHCP relay can be used to fill Option 82 for the gateway address. The gateway address can be used to find the appropriate pool in the DHCP server to assign the correct subnet IP address to the SR Linux.
The Python provisioning file is downloaded from the location dictated by Option 66 and 67 or 43 using HTTP, HTTPS, TFTP, or FTP. Option 66 and 67 takes precedence over Option 43 when both are present in the offer, but Option 43 will be used if there is a download error with Option 66 and 67. In addition, Option 66 and 67 can be summarized in Option 67 only. The URL of the provisioning file can be resolved via the DHCP-provided DNS. Up to three DNS servers can be offered by the DHCP.
The node downloads the Python script to storage device. The node then uses the Python provisioning script to download any RPMs, images, scripts, or configurations to the destination dictated by the script.
The URLs defined in the Python script define multiple levels of redundancy. If the primary location is unreachable and times out, two additional redundant servers can be configured. The node cycles through the primary, secondary, and tertiary locations and, when successful, downloads the files to the storage device where they are executed locally.
After successful completion, the provisioning script disables the auto-boot flag to ensure that additional reboots of the node will not enter auto-boot mode. When the nodes reboot, they come up in an operational state with the configuration and image.
For additional information about the Python provisioning script, see Configuring the Python provisioning script.
The following are possible failure scenarios:
If a failure occurs:
ZTP log files are stored under /var/log/ztp. For example:
The following are common ZTP configuration procedures:
The following are common ZTP configuration procedures using the ZTP CLI:
The following are common ZTP configuration procedures using the SR Linux CLI:
There are two CLIs where ZTP-related commands can be executed:
The SR Linux commands are available to use only when the SR Linux is operational at the sr_cli.
When the SR Linux is not operational, the ZTP CLI is a unified tool that can be used to manage ZTP tasks at the console.
Refer to the ZTP CLI and SR Linux CLI command structures sections for a complete list of available ZTP-related commands.
The primary components of the Python provisioning script include:
The following is an example Python provisioning script.
Example: Python provisioning script
The ZTP process sends DHCP discovery messages on all ports within a ZTP cycle. Every time the DHCP discovery timeout expires and a DHCP offer has not been received, the DHCP discovery process reinitiates on the port until the ZTP timeout expires.
The timeout value can be set using the:
Several options can be manually configured in the grub.cfg using the ZTP CLI at the console. The command has the following format:
# ztp option <command> [<arguments>]
where command must be one of the following:
Command | Description |
autoboot | Enables or disables the auto-boot flag |
bootintf | Specifies boot interface options |
clientid | Sets the client ID to a chassis MAC address or serial ID |
downgrade | Indicates whether NOS downgrade is allowed |
duration | Specifies the ZTP timeout value and number of retry attempts |
formatovl | Indicates the format overlay file system on the next reboot |
formatsrletc | Indicates the format /etc/opt/srlinux overlay file system |
formatsrlopt | Indicates the format /opt/srlinux overlay file system |
list | Displays the current value for each of the command options |
nosinstall | Specifies whether a NOS upgrade should be performed as part of the ZTP process |
reload | Reloads the config and updates the grub from the config |
srlflags | Sets the debug flag in cmdline to a specified value |
Table 6 describes examples of ztp option commands and available arguments.
Command and description | Command syntax |
autoboot Enable or disable the auto-boot flag | ztp option autoboot --status [enable | disable] |
bootintf Specify the boot interface to send DHCP over | ztp option bootintf --intf <name of interface> |
bootintf Remove the previously set boot interface | ztp option bootintf --remove |
duration Set the ZTP timeout value | ztp option duration --timeout <integer in seconds> Default = 3600, range = 200 to 3600 |
duration Set the number of ZTP retry attempts | ztp option duration --retry <integer> Default = 3, range = 1 to 10 |
clientid Set the client ID to a chassis MAC address | ztp option clientid --type mac |
clientid Set the client ID to a serialID | ztp option clientid --type serialid |
nosinstall Enable or disable NOS upgrade flag | ztp option nosinstall --status [enable | disable] |
list Display the current value of each option | ztp option list |
The following is an example output of the ztp option list command:
The ZTP CLI ztp image command can be used to activate, delete, list, or perform an upgrade at the console. The following command format is used:
# ztp image <command> [<arguments>]
where command must be one of the following:
Command | Description |
activate | Activate a specific image |
bootorder | Configure a grub entry to match the boot order as passed |
delete | Delete a specific image |
list | List all available NOS images |
upgrade | Perform an upgrade based on provided parameters |
version | Extract the version from a specific filename |
Table 7 describes examples of ztp image commands and available arguments.
Command and description | Command syntax |
activate Activate a specific NOS image | ztp image activate --version <build version> [--no-reboot] Note: --no-reboot means do not reboot after activate to take new build into use. |
bootorder Configure the bootorder | ztp image bootorder --version <build version 1> --version <build version 2> --version <build version 3> Note: --version means the image version order that booting is attempted, which allows up to 3 versions. |
delete Delete a specific NOS image | ztp image delete --version <build version> Warning: Active image must not be deleted. |
list List all available NOS images | ztp image list |
upgrade Download an image for NOS upgrade | ztp image upgrade --imageurl <URL to download image> |
upgrade Download an md5 file for NOS upgrade | ztp image upgrade --md5url <URL to download md5 file> |
upgrade Do not reboot after an upgrade install | ztp image upgrade --no-reboot |
version Extract a version | ztp image version --filename <filename path> [--format <format type>] Example commands: ztp image version --filename ./config --format json ztp image version --filename ./srlinux-20.6.1-12617.tar |
Example output (list images):
Example output (activate image):
Example output (version):
The ZTP CLI image command can be used to push the configuration from the console when SR Linux is not operational.
The following is an example showing how to configure the SR Linux with a configuration downloaded with a user-provided URL:
ztp configure-nos --configurl <URL to download configuration>
Executable files (RPMs, scripts, and configurations) can be redownloaded if required. This can be performed at the console using the ZTP CLI.
The following is an example showing how to run the provisioning script with a user-provided URL:
ztp provision --url <URL where files should be downloaded from>
The ZTP process can be manually started, stopped, and restarted using a ZTP CLI command at the console. The following command format is used:
# ztp service <command> [<arguments>]
where command must be one of the following:
Command | Description |
canstart | Indicates whether ZTP can be started in current condition |
start | Starts ZTP process if not currently running |
stop | Stops ZTP process if already running |
restart | Stops ZTP process (if running), and then restarts the process |
Table 8 describes examples of ztp service commands and available arguments.
Command and description | Command syntax |
canstart Verify whether ZTP can start in current condition | ztp service canstart |
start Start the ZTP process | ztp service start |
start Start the ZTP process and enable/disable auto-boot | ztp service start --autoboot [enable | disable] |
stop Stop the ZTP process | ztp service stop |
stop Stop the ZTP process and disable auto-boot | ztp service stop --autoboot disable |
restart Restart the ZTP process | ztp service restart |
restart Restart the ZTP process and enable/disable auto-boot | ztp service restart --autoboot [enable | disable] |
The ZTP process status can be manually checked using the ZTP CLI command at the console.
The following is an example showing how to check the status of the ZTP process:
ztp service status
Output Example:
Several auto-boot related options can be manually configured in the grub.cfg using the SR Linux CLI when SR Linux is operational. The command has the following format:
# system boot autoboot <command> [<arguments>]
where command must be one of the following:
Command | Description |
admin-state | Enables or disables the auto-boot functionality |
interface | Sets the interface used for the auto-boot functionality |
timeout | Sets the timeout for each auto-boot attempt |
attempts | Sets the amount of auto-boot executions to try before rebooting the system |
client-id | Sets the client ID to use on outgoing DHCP requests |
Table 9 describes examples of SR Linux autoboot commands and available arguments.
Command and description | Command syntax |
admin-state Enable or disable the auto-boot flag | system boot autoboot admin-state [enable | disable] Default = enable |
interface Specify the boot interface to send DHCP over | system boot autoboot interface <name of interface> Default = mgmt0 |
timeout Set the ZTP timeout value | system boot autoboot timeout <integer in seconds> Default = 3600, range = 200 to 3600 |
attempts Set the number of ZTP retry attempts | system boot autoboot attempts <integer> Default = 3, range = 1 to 10 |
client-id Set the client ID to a serial ID or a chassis MAC address | system boot autoboot client-id [serial | mac] Default = serial |
Users can specify an ordered list of local images, kernels, or initial RAM disks to boot the system using the SR Linux CLI when SR Linux is operational. This directly translates into boot configuration in the grub, where the images or kernels are tried in the order specified by the user. The command has the following format:
# system boot <command> [<arguments>]
where command must be the following:
Command | Description |
image | User-specified ordered list of local images used to boot the system |
Table 10 describes an example of the SR Linux image and kernel boot command and available argument.
Command and description | Command syntax |
image Specify an ordered list of images to boot the system | system boot image <ordered list of images> Note: Up to 3 files can be specified. |
The ZTP process can be manually started, stopped, and restarted using the SR Linux CLI when SR Linux is operational. The following command format is used:
# tools system boot autoboot <command>
where command must be one of the following:
Command | Description |
execute-script | Executes a specified script as if it were received during auto-boot |
start | Starts a ZTP process if not currently running |
stop | Stops a ZTP process if already running |
restart | Stops an in-progress auto-boot process, then initiates another |
Table 11 describes examples of SR Linux start, stop, and restart commands and available arguments.
Command and description | Command syntax |
execute-script Execute a specified script | tools system boot autoboot execute-script <URL to the script> |
start Start the ZTP process | tools system boot autoboot start |
stop Stop the ZTP process | tools system boot autoboot stop |
restart Restart the ZTP process | tools system boot autoboot restart |
The ZTP process status can be manually checked using the SR Linux CLI when SR Linux is operational.
The following is an example showing how to check the status of the ZTP process:
# tools system boot autoboot status
The following ZTP CLI commands are available at the console:
The following SR Linux auto-boot related tool commands are available when the SR Linux is operational:
Refer to the SR Linux Data Model Reference for additional information about SR Linux commands and parameter descriptions.