Zero Touch Provisioning

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.

Applicability

The following implementation is currently supported:

  • auto-boot using the Out-of-Band (OOB) port, which includes support of HTTP, HTTPS, TFTP, and FTP
    Note: No VLANs are supported on the management port.
  • dual-stack IPv4 and IPv6 (including DHCP client IPv4/IPv6)

ZTP overview

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 do not enter auto-boot mode.

Network requirements

ZTP requires the following components:

  • DHCP server (IPv4 or IPv6) – To support the assignment of IP addresses through DHCP requests and offers.
  • file server – For staging and transfer of RPMs, configurations, images, and scripts. HTTP, HTTPS, TFTP, and FTP are supported. For HTTPS, the default Mozilla certificate should be used.
  • DHCP relay – Required if the server is outside the management interface broadcast domain.

ZTP works in the following network environments:

  • nodes, HTTP file servers, and DHCP server in the same subnet
  • HTTP file servers and DHCP server in the same subnet, separate from the nodes
  • nodes, HTTP file servers, and DHCP server in different subnets

All components in the same subnet 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 1. All components in the same subnet

HTTP file and DHCP servers in the same subnet 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 2. HTTP file and DHCP servers in the same subnet

All components in different subnets 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.

Figure 3. All components in different subnets

Process information

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 and solicitation

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 is then sent out. The DHCP timeout is 60 seconds.

  • For DHCP IPv4, Option 61 is used for pool selection. By default, the node sends Option 61 with the serial number of the chassis.
    Note: The grub.cfg can be provisioned with a MAC option as well. When a MAC option is specified, Option 61 is populated with the chassis MAC address.
  • For DHCP IPv6, Option 1 is used for pool selection. By default, the node uses RFC 3315 DUID Type 2 vendor-assigned unique ID. The value for enterprise-id is 6527 and the identifier is the chassis serial number.
    Note: Type 3 is configurable in the grub.cfg.

When the DHCP server receives the discovery packet, it assigns the IP address to the node. The DHCP offer for IPv4 requires the options shown in Required DHCP offer options.

Table 1. Required DHCP offer options

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 hostname

Server IP address

67

Bootfile Name

URL or IP to the provisioning file

DHCP IPv4 and IPv6 equivalents lists DHCP IPv4 and IPv6 equivalents.

Table 2. 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

Auto-provisioning options

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 performs 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 server Option 42 (IPv4) and 56 (IPv6) for NTP

DHCP provides 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 has the correct timestamp. Any log event before the time was obtained does not have the correct timestamp, and has the default timestamp instead.

DHCP offer

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.

Default gateway route configuration for IPv4

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).

DHCP relay

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.

Python provisioning script

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 is 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 do not enter auto-boot mode. When the nodes reboot, they come up in an operational state with the configuration and image.

For more information about the Python provisioning script, see Configuring the Python provisioning script.

Auto-provisioning failures

The following are possible failure scenarios:

  • No Option 66 and 67 or 43 is received (possibly because the format is a URL or no IP address was provided via the DHCP server).
  • The download of the Python provisioning script failed or the server was not reachable.
  • The download of the RPMs, scripts, or configurations failed (possibly because to the server is not available, or incorrect directory or credentials).
  • Copying the RPMs, scripts, or configuration to the storage device failed.

If a failure occurs:

  • Details of the failure display on the console and are recorded in the appropriate log files. Log files are stored in the storage device. There can be three log files, which are overwritten in a circular manner.
  • The DHCP task is notified of the failure and releases the IP address on the port.
  • The auto-boot task goes through the process cycle again until it succeeds, the timeout value is reached, or the auto-boot Option is removed from the grub.cfg, either by editing the grub.cfg or using the ZTP CLI.

ZTP log files

ZTP log files are stored under /var/log/ztp.

[root@srlinux ztp]# ls -ltr
total 28528
-rw-r--r-- 1 root root    18220 Sep  4 23:04 ztp_2019-09-04_23-03-52_880867.log
-rw-r--r-- 1 root root     1789 Sep  4 23:29 ztp_2019-09-04_23-29-38_496995.log
-rw-r--r-- 1 root root    18220 Sep  4 23:31 ztp_2019-09-04_23-31-08_996284.log
-rw-r--r-- 1 root root     1791 Sep  5 17:42 ztp_2019-09-05_17-42-01_082002.log
-rw-r--r-- 1 root root        0 Sep  5 21:56 ztp_2019-09-05_21-56-13_730783.log
-rw-r--r-- 1 root root        0 Sep  5 21:56 ztp_2019-09-05_21-56-14_036070.log
[root@srlinux ztp]#

Configuring ZTP

ZTP CLI versus SR Linux CLI

There are two CLIs where ZTP-related commands can be executed:

  • SR Linux CLI (sr_cli)
  • ZTP CLI

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.

See the ZTP CLI and SR Linux CLI command structures sections for a complete list of available ZTP-related commands.

Configuring the Python provisioning script

The primary components of the Python provisioning script include:

  • location of provider certificate and trust anchor when HTTPS is used to download RPMs and other bash/Python scripts
  • the URL location for each RPM, script, and configuration
  • DNS information for resolving the URL of a file. At least one DNS entry is needed for resolving the URL of downloaded files. This DNS can be different from the DHCP offered DNS. If a DNS is defined in the provisioning file, it takes precedence over the DHCP DNS. If there is no DNS in the provisioning script, the DHCP DNS will be used.
  • a section to clear the auto-boot option from the grub.cfg kernel section

Python provisioning script

import errno
import os
import sys
import signal
import subprocess
from subprocess import Popen, PIPE
import threading
srlinux_image_url = 'http://135.227.249.116/srlinux/srlinux-20.6.1-10656.squashfs'
srlinux_image_md5_url = 'http://135.227.249.116/srlinux/srlinux-20.6.1-10656.md5'
srlinux_config_url = 'http://135.227.249.116/srlinux/config.json'
class ProcessError(Exception):
    def __init__(self, msg, errno=-1):
        Exception.__init__(self, msg)
        self.errno = errno
class ProcessOpen(Popen):
    def __init__(self, cmd, cwd=None, env=None, flags=None, stdin=None,
        stdout=None, stderr=None, universal_newlines=True,):
        self.__use_killpg = False
        shell = False
        if not isinstance(cmd, (list, tuple)):
            shell = True
        # Set flags to 0, subprocess raises an exception otherwise.
        flags = 0
        # Set a preexec function, this will make the sub-process create it's
        # own session and process group - bug 80651, bug 85693.
        preexec_fn = os.setsid
        self.__cmd = cmd
        self.__retval = None
        self.__hasTerminated = threading.Condition()
        Popen.__init__(self, cmd, cwd=cwd, env=env, shell=shell, stdin=stdin,
           stdout=PIPE, stderr=PIPE, close_fds=True, 
           universal_newlines=universal_newlines, creationflags=flags,)
        print("Process [{}] pid [{}]".format(cmd, self.pid))
    def _getReturncode(self):
        return self.__returncode
    def __finalize(self):
        # Any finalize actions
        pass
    def _setReturncode(self, value):
        self.__returncode = value
        if value is not None:
            # Notify that the process is done.
            self.__hasTerminated.acquire()
            self.__hasTerminated.notifyAll()
            self.__hasTerminated.release()
    returncode = property(fget=_getReturncode, fset=_setReturncode)
    def _getRetval(self):
        # Ensure the returncode is set by subprocess if the process is finished.
        self.poll()
        return self.returncode
    retval = property(fget=_getRetval)
    def wait_for(self, timeout=None):
        if timeout is None or timeout < 0:
            # Use the parent call.
            try:
                out, err = self.communicate()
                self.__finalize()
                return self.returncode, out, err
            except OSError as ex:
                # If the process has already ended, that is fine. This is
                # possible when wait is called from a different thread.
                if ex.errno != 10:  # No child process
                    raise
                return self.returncode, "", ""
        try:
            out, err = self.communicate(timeout=timeout)
            self.__finalize()
            return self.returncode, out, err
        except subprocess.TimeoutExpired:
            self.__finalize()
            raise ProcessError(
                "Process timeout: waited %d seconds, "
                "process not yet finished." % (timeout)
            )
    def kill(self, exitCode=-1, sig=None):
        if sig is None:
            sig = signal.SIGKILL
        try:
            if self.__use_killpg:
                os.killpg(self.pid, sig)
            else:
                os.kill(self.pid, sig)
        except OSError as ex:
            self.__finalize()
            if ex.errno != 3:
                # Ignore:   OSError: [Errno 3] No such process
                raise
        self.returncode = exitCode
        self.__finalize()
    def commandline(self):
        """returns string of command line"""
        if isinstance(self.__cmd, six.string):
            return self.__cmd
        return subprocess.list2cmdline(self.__cmd)
    __str__ = commandline
def execute_and_out(command, timeout=None):
    print("Executing command: {}".format(command))
    process = ProcessOpen(command)
    try:
        #logger.trace("Timeout = {}".format(timeout))
        ret, out, err = process.wait_for(timeout=timeout)
        return ret, out, err
    except ProcessError:
        print("{} command timeout".format(command))
        process.kill()
        return errno.ETIMEDOUT, "", ""
def execute(command, timeout=None):
    ret, _, _ = execute_and_out(command, timeout=timeout)
    return ret
def pre_tasks():
    pass
def srlinux():
    nos_install()
    nos_configure()
def post_tasks():
    pass
def nos_install():
    cmd = 'ztp image upgrade --imageurl {} --md5url {}'.format(srlinux_image_url, srlinux_image_md5_url)
    ret,out,err = execute_and_out(cmd)
def nos_configure():
    cmd = 'ztp configure-nos --configurl {}'.format(srlinux_config_url)
    ret,out,err = execute_and_out(cmd)
def main():
    pre_tasks()
    srlinux()
    post_tasks()
if __name__ == '__main__':
    main()

Configuring the ZTP timeout value using the 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:

Configuring options in the grub.cfg using ZTP CLI

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:

Table 3. Configuring options

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

ZTP CLI: option command examples describes examples of ztp option commands and available arguments.

Table 4. ZTP CLI: option command examples

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 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

Example output

The following is an example output of the ztp option list command:

# ztp option list
+--------------+----------+
| Name         | Value    |
+--------------+----------+
| autoboot     | False    |
| nosinstall   | False    |
| bootintf     | mgmt0    |
| timeout      | 3600     |
| retry        | 3        |
| clientid     | serialid |
| downgrade    | True     |
| formatovl    | False    |
| formatsrlopt | True     |
| formatsrletc | False    |
| srlflags     | None     |
+--------------+----------+

Managing images using ZTP CLI

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:

Table 5. Image command descriptions

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

ZTP CLI: ztp image command examples describes examples of ztp image commands and available arguments.

Table 6. ZTP CLI: ztp image command examples

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 outputs

Example output (list images):

[root@localhost ~]# ztp image list
[ 1638.035200] EXT4-
fs (sdb2): mounted filesystem with ordered data mode. Opts: (null)
+--------------+
| Versions     |
+--------------+
| 20.6.1-10654* |
| 20.6.1-10587  |
| 20.6.1        |
+--------------+

Example output (activate image):

[root@localhost ~]# ztp image list 
[  227.172007] EXT4-
fs (sdb2): mounted filesystem with ordered data mode. Opts: (null)
+--------------+
| Versions     |
+--------------+
| 20.6.1-10587* |
| 20.6.1-10654  |
| 20.6.1        |
+--------------+

Example output (version):

[root@localhost ~]# ztp image version --filename ./srlinux-20.6.1-12617.tar
+-------------+---------+
| version     | message |
+-------------+---------+
| 20.6.1-12617 | None   |
+-------------+---------+

Configuring the NOS using ZTP CLI

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>

Redownloading the executable files with ZTP CLI

Executable files (RPMs, scripts, and configurations) can be redownloaded if required. The redownload 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>

Starting, stopping, and restarting a ZTP process using ZTP CLI

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:

Table 7. Starting, stopping, and restarting command descriptions

Command

Description

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

ZTP CLI: ztp service command examples describes examples of ztp service commands and available arguments.

Table 8. ZTP CLI: ztp service command examples

Command and description

Command syntax

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]

Checking the status of a ZTP process using ZTP CLI

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

# ztp service status
+---------+----------+
| Service | Status   |
+---------+----------+
| ztp     | Active   |
+---------+----------+
#

Configuring options in the grub.cfg using SR Linux CLI

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:

Table 9. Configuring options

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

SR Linux CLI: autoboot commands for grub.cfg update examples describes examples of SR Linux autoboot commands and available arguments.

Table 10. SR Linux CLI: autoboot commands for grub.cfg update examples

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

Specifying the image, kernel, or RAM to boot the system using SR Linux CLI

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:

# tools system boot <command> [<arguments>]

where command must be the following:

Table 11. Specifying the image, kernel, or RAM

Command

Description

image

User-specified ordered list of local images used to boot the system

SR Linux CLI: image and kernel boot command example describes an example of the SR Linux image and kernel boot command and available argument.

Table 12. SR Linux CLI: image and kernel boot command example

Command and description

Command syntax

image

Specify an ordered list of images to boot the system

tools system boot image <ordered list of images>

Note: Up to 3 files can be specified.

Starting, stopping, and restarting a ZTP process usingSR Linux CLI

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:

Table 13. Commands

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

SR Linux CLI: start, stop, and restart process command examples describes examples of SR Linux start, stop, and restart commands and available arguments.

Table 14. SR Linux CLI: start, stop, and restart process command examples

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

Checking the status of a ZTP process using SR Linux CLI

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

ZTP CLI and SR Linux CLI command structures

This section describes the ZTP CLI command structure and SR Linux CLI command structure.

ZTP CLI command structure

The following ZTP CLI commands are available at the console:

ztp
    — chassis
        — control
            — [--format table | json]
        — linecards
            — [--format table | json]
    configure-nos
        — --configurl <URL to download configuration>
    image
        — activate
            — --version <build version>
                — [--no-reboot]
        — bootorder
            — --version <up to 3 build versions>
        — delete
            — --version <build version>
        — list
            — [--format table | json]
        — upgrade
            — --imageurl <URL to download image> --md5url <URL to download md5 file>
                — [--no-reboot]
                — [--skip-check]
                — [--not-active]
        — version
            — --filename <name>
                — [--format table | json]
    option
        — autoboot
            — --status enable | disable
        — bootintf
            — --intf <boot interface>
        — clientid
            — --type serialid
        — downgrade
            — --status enable | disable
        — duration
            — --timeout <seconds> --retry <integer>
        — formatall
            — --status enable | disable
        — formatovl
            — --status enable | disable
        — formatsrletc
            — --status enable | disable
        — formatsrlopt
            — --status enable | disable
        — grubopt
            — [--key <text>]
            — [--value <text>]
            — [--delete]
        — list
            — [--format table | json]
        — nosinstall
            — --status enable | disable
        — reload
        — srlflags
            — [--value <text>]
            — [--delete]
    provision
        — --url <URL to download provisioning script>
    service
        — restart
            — --autoboot enable | disable
        — start
            — --autoboot enable | disable
        — status
            — [--format table | json]
        — stop
            — --autoboot enable | disable

SR Linux CLI command structure

The following SR Linux auto-boot related tool commands are available when the SR Linux is operational:

system
   — boot
        — autoboot
            — admin-state
            — attempts
            — client-id
            — interface
            — status
            — timeout
        — image
tools
    — system
        — boot
            — autoboot
                — execute-script
                — restart
                — start
                — status
                — stop

Refer to the SR Linux Data Model Reference for additional information about SR Linux commands and parameter descriptions.