5. Zero Touch Provisioning

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.

Zero Touch Provisioning (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.

5.1. Applicability

The following implementation is currently supported:

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

5.2. Overview

For auto-boot using OOB, 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.

Once initiated, the auto-boot mode starts the auto-provisioning process. The 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 provision 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. Once 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.

5.2.1. Network requirements

ZTP requires the following components:

  1. DHCP server (IPv4 or IPv6) – To support the assignment of IP addresses through DHCP requests and offers.
  2. 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.
  3. DHCP relay – Required if the server is outside the management interface broadcast domain.

ZTP works in the following network environments:

  1. nodes, HTTP file servers, and DHCP server in the same subnet
  2. HTTP file servers and DHCP server in the same subnet, separate from the nodes
  3. nodes, HTTP file servers, and DHCP server in different subnets

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 2:  All components in the same subnet 

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

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.

Figure 4:  All components in different subnets 

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

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

  1. 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 will be populated with the chassis MAC address.
  2. 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 will assign the IP address to the node. The DHCP offer for IPv4 should contain the options shown in Table 4.

Table 4:  Required DHCP offer options 

Option

Name

Description

viaddr

Client-Ip-Address

Network interface – IP address (for NW 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 defines DHCP IPv4 and IPv6 equivalents.

Table 5:  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

—

5.3.1.1. 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 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 References for procedures and commands used to provision available options.

5.3.1.2. DHCP server Option 42 (IPv4) and 56 (IPv6) for NTP

DHCP will provide an NTP server URL using Option 42 (for IPv4) or Option 56 (for IPv6). When the time is obtained and synced 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.

5.3.2. 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, like 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.

5.3.2.1. Default gateway route configuration for IPv4

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

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

5.3.3. 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 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 and places it on the storage device. The node then uses the Python provisioning script to download any RPMs, images, scripts, or config and places them in 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 once 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. Once the nodes reboot, they will come up in an operational state with the config and image.

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

5.3.4. Auto-provisioning failures

The following are possible failure scenarios:

  1. 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).
  2. The download of the Python provisioning script failed or the server was not reachable.
  3. The download of the RPMs, scripts, or config failed (possibly due to the server not being available, or incorrect directory or credentials).
  4. Copying the RPMs, scripts, or config to the storage device failed.

If a failure occurs:

  1. 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.
  2. The DHCP task is notified of the failure and releases the IP address on the port.
  3. 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.

5.3.5. ZTP log files

ZTP log files are stored under /var/log/ztp. For example:

[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]#

5.4. Configuring ZTP

The following are common ZTP configuration procedures:

  1. Configuring the Python provisioning script
  2. Configuring the ZTP timeout value using the provisioning script

The following are common ZTP configuration procedures using the ZTP CLI:

  1. Configuring options in the grub.cfg using ZTP CLI
  2. Managing images using ZTP CLI
  3. Configuring the NOS using ZTP CLI
  4. Redownloading the executable files with ZTP CLI
  5. Starting, stopping, and restarting a ZTP process using ZTP CLI
  6. Checking the status of a ZTP process using ZTP CLI

The following are common ZTP configuration procedures using the SR Linux CLI:

  1. Configuring options in the grub.cfg using SR Linux CLI
  2. Specifying the image, kernel, or RAM to boot the system using SR Linux CLI
  3. Starting, stopping, and restarting a ZTP process using the SR Linux CLI
  4. Checking the status of a ZTP process using the SR Linux CLI

5.4.1. ZTP CLI versus SR Linux CLI

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

  1. SR Linux CLI (sr_cli)
  2. 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.

Refer to the References sections for a complete list of available ZTP-related commands.

5.4.2. Configuring the Python provisioning script

The primary components of the Python provisioning script include:

  1. location of provider certificate and trust anchor when HTTPS is used to download RPMs and other bash/Python scripts
  2. the URL location for each RPM, script, and config
  3. 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.
  4. a section to clear the auto-boot option from the grub.cfg kernel section

The following is an example Python provisioning script.

Example: 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()

5.4.3. 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:

  1. ZTP CLI (see procedure 5.4.4 Configuring options in the grub.cfg using ZTP CLI)
  2. SR Linux CLI (see procedure 5.4.10 Configuring options in the grub.cfg using SR Linux CLI)

5.4.4. 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:

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

Table 6:  ZTP CLI: ztp 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 specific 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-3600

duration

Set the number of ZTP retry attempts

ztp option duration --retry <integer>

Default=3, range=1-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:

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

5.4.5. 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:

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.

Table 7:  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 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   |
+-------------+---------+

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

5.4.7. Redownloading the executable files with ZTP CLI

Executable files (RPMs, scripts, and configs) 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>

5.4.8. 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:

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.

Table 8:  ZTP CLI: ztp service command examples 

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]

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

Output Example:

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

5.4.10. 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:

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 commands and available arguments.

Table 9:  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 specific 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-3600

attempts

Set the number of ZTP retry attempts

system boot autoboot attempts <integer>

Default=3, range=1-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

5.4.11. 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:

# 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 command and available argument.

Table 10:  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

system boot image <ordered list of images>

Note: Up to 3 files can be specified.

5.4.12. Starting, stopping, and restarting a ZTP process using the SR 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:

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 commands and available arguments.

Table 11:  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

5.4.13. Checking the status of a ZTP process using the 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

5.5. References

5.5.1. 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
— canstart
— [--format table | json]
— restart
— --autoboot enable | disable
— start
— --autoboot enable | disable
— status
— [--format table | json]
— stop
— --autoboot enable | disable

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