Zero touch provisioning

Traditional deployment of a new node in a network is a multistep process in which the user connects to the hardware to provision global and local parameters. Zero Touch Provisioning (ZTP) automatically configures a node by obtaining the required information from the network and provisioning the node with minimal manual intervention and configuration. When new nodes that support ZTP are connected and boot up, the node is auto-provisioned.

Note: To support ZTP, make sure the new nodes are purchased with the auto-boot flag enabled in the factory-loaded BOF.

ZTP overview

ZTP is used to automatically install and provision new nodes in the field. For out-of-band management, the nodes can be installed and powered up with network connectivity on the management (Mgmt) port. For in-band management, the first two connectors on the first two slots can be used for ZTP.

Note: For breakout connectors, only the first breakout port on the first two connectors can be used for ZTP.

ZTP VLAN discovery is enabled by default.

After network connectivity is established, the ZTP process starts automatically. The node sends a DHCP discovery request to the DHCP server using a ZTP-capable port and the DHCP server returns an IPv4/IPv6 FTP or HTTP URL from which the provisioning information can be retrieved. The provisioning information is in a file called the provisioning file, which contains the URL of the image, config, and other files to be downloaded. After downloading these files and successfully provisioning, the node automatically reboots and comes back up in normal mode.

Secure ZTP (SZTP), which is an extension of ZTP, is also supported. See Zero touch provisioning for information about SZTP.

Network requirements

ZTP requires the following network components:

  • DHCP server (IPv4 or IPv6)

    The DHCP server supports assignment of IP addresses through DHCP requests and offers.

  • file server

    The FTP or HTTP URL is used for staging and transfer of RPMs, configurations, images, and scripts.

  • DHCP relay

    DHCP relay is required if the servers are across a Layer 3 network.

Network support

ZTP operates in the following network environments:

  • node, file servers, and DHCP server in the same subnet

    Auto-provisioning with all components in a Layer 2 broadcast domain shows the scenario where all components are in a Layer 2 broadcast domain. There is no DHCP relay and all IP addresses are assigned from a single pool.

    Figure 1. Auto-provisioning with all components in a Layer 2 broadcast domain
  • file servers and DHCP server in the same subnet, separate from the node

    Auto-provisioning with all components in a Layer 2 broadcast domain shows the scenario, where only the file servers and DHCP server are in the same subnet. 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 system.

    Figure 2. Auto-provisioning with all components in a Layer 2 broadcast domain

    DHCP allows the Option 3 router to define the default gateway. If multiple addresses are provided using Option 3, the first address is used for the default gateway.

  • node, file servers, and DHCP server in different subnets

    Auto-provisioning with all components in different subnets shows the scenario, where all components are in different subnets. DHCP relay adds the Option 82 gateway address to the DHCP request, and the DHCP server adds the Option 3 gateway address of the file server.

    Figure 3. Auto-provisioning with all components in different subnets

ZTP processes

ZTP consists of the following processes:

  • auto-boot process

  • auto-provisioning process

Auto-boot process

In this process, the node discovers and provisions the chassis and installed cards.

  1. The node is powered up.

  2. The out-of-band management port is checked for link connectivity. If a link is not found, the in-band management ports are checked for a link.

  3. The first two card or MDA slots are auto-provisioned based on the installed card types. See ZTP overview for information about the specific card or MDA slots that are used.

  4. The auto-boot process switches control to the auto-provisioning process.

See Auto-boot process for more information about the auto-boot process.

Auto-provisioning process

In this process, the node detects operational ports, attempts to discover its IP address, and downloads the relevant files for provisioning.

  1. The node sends a DHCP discovery request to the DHCP server using the out-of-band management port. If DHCP discovery is unsuccessful, the node reattempts it using the in-band management ports.

  2. After DHCP discovery is successful, the DHCP server returns an IPv4 or IPv6 FTP or HTTP URL of a file server from which the node can retrieve provisioning information.

  3. The node downloads the provisioning information and performs the auto-provisioning according to the specifications in the files.

  4. After the node is successfully provisioned, it automatically reboots and becomes operationally up.

See Provisioning files for more information about the auto-provisioning process.

The SR OS can also initiate the auto-provisioning process using a tools command.

DHCP support for ZTP

This section provides information about DHCP messages, DHCP clients, and DHCP servers that are supported by ZTP.

DHCP server offer Options 66, 67, and 43

Options 66, 67, and 43 are supported for indicating the location of the provisioning file. If both Options 66 and 67 are present in the DHCP offer, they take precedence over Option 43.

Option 66 contains the server URL or IP address, and Option 67 contains the URL of the provisioning file location.

Options 66 and 67 are meant for use by PXE TFTP, but are also used for HTTP and FTP. If an offer arrives with Options 66 and 67, Option 66 should resolve the server IP address and Option 67 should resolve the file location. Option 66 can be omitted by the provider, in which case Option 67 is used for both the server IP address and provider file URL. If an offer arrives with Option 67 only, it should resolve both the server IP address and file URL.

The auto-provisioning process distinguishes the host part of the URL and can resolve it using DHCP DNS.

Nokia-specific TLV

The Nokia-specific TLV is NOKIA-DCTOR-AUTOCONFIG. The location of the BOF for each system to use is configured in the optional autoboot file parameter, which is a standard Option 43 value initialized at the beginning of the process. The BOF location is sent in Option 43 as part of the DHCP offer and Ack messages from the DHCP server to the system. The system uses the location specified in Option 43 to initiate an FTP download of the BOF.

Supported DHCP client options for ZTP

Supported DHCP client options for ZTP lists the supported DHCP client options for ZTP.

Table 1. Supported DHCP client options for ZTP
Options DHCP IPv4 option IPv4 comments DHCP IPv6 option IPv6 comments

Lease time

Option 51

Always infinite

Requested option list

Option 55

Client ID

Option 61

Default is chassis serial ID

Option 1 (DUID)

Type 2 — vendor-assigned unique ID (default with chassis serial ID)

Type 3 — link-layer address

User class

Option 77

platform;timos-release;ztp”

Option 15

platform;timos-release;ztp”

Class ID

Option 60

‟NOKIA: FmtChassisType Strings”

Supported DHCP server options for ZTP

Supported DHCP server options for ZTP lists the supported DHCP server options for ZTP.

Table 2. Supported DHCP server options for ZTP
Options DHCP IPv4 option IPv4 comments DHCP IPv6 option IPv6 comments

Subnet mask

Option 1

Router

Option 3

Default gateway

DNS server

Option 6

DNS server

Lease time

Option 51

Must be infinite

Server address

Option 54

Identifies the DHCP server

Classless static route

Option 121

Used to install static routes

NTP server 1

Option 42

Option 56

TFTP server name

Option 66

Server IP address

Bootfile name

Option 67

URL of the file

Can be used without Option 66, in which case it contains the server name and the URL

Option 59

Server name and URL of the file

Vendor-specific options

(See Nokia-specific TLV)

Option 43

Nokia proprietary file location

Can be used instead of Options 66 or 67, but Options 66 and 67 take precedence over Option 43

Option 17

Nokia proprietary file location

Can be used instead of Option 59, but Option 59 takes precedence over Option 17

1 When the node is running in ZTP mode, the date and time are set by NTP. This information is required for HTTPs certificate verification, and to record date and time stamps in events and logs.

DHCP discovery and solicitation

IPv4 DHCP discovery and IPv6 DHCP solicitation are supported.

IPv4 DHCP discovery messages and IPv6 DHCP solicitation messages are sent from out-of-band and in-band management ports with active links. The first valid DHCP offer for the address family that arrives on the node is used.

In the BOF, the auto-boot option can be configured to send out IPv4, IPv6, or both IPv4 and IPv6 DHCP requests.

DHCP discovery (IPv4 and IPv6)

This section describes DHCP discovery options.

DHCP discovery Options 61 and 77

The SR OS supports both Option 61 (client ID) and Option 77 (user class) DHCP discovery options.

Option 61 provides the client ID; the serial ID of the chassis is used by default. Option 61 is used for DHCP server pool selection. By default, the chassis serial ID is sent in Option 61 with a type of 0. This option is configurable using the bof auto-boot context.

Option 77 provides the user class, describing what the device is and other information, such as the OS version. This option is set automatically, but can be removed using the BOF configuration. For example, the user can omit include-user-class in the BOF auto-boot configuration, to avoid sending Option 77.

For ZTP, the DHCP discovery message should be sent with Option 77; the following information is automatically configured:

platform;timos-release;ztp

For auto-provisioning, Option 77 should use the following information:

platform;timos-release;AP

DHCP discovery Option 1 DUID (IPv6)

By default, the node uses RFC 3315, DUID Type 2 vendor-assigned unique IDs. The value for enterprise-id is 6527 and the identifier is the chassis serial number.

Note: The system uses the chassis serial number for ZTP pool selection and auto-provisioning.

The option to use Type 3 is configured in the BOF. For MAC, the chassis MAC address is configured in a string format.

Type 1 is not supported.

DHCP solicitation (IPv6)

Unlike IPv4 DHCP offers, which contain the prefix and default route, IPv6 DHCP offers only contain the IP address assignment. The IPv6 route advertisement (RA) provides the default router and the prefix is set to /128 for the IP address supplied by the DHCP server.

For further information about RA support, see IPv6 DHCP/RA details. For further information about DHCP server offers, see DHCP server offer Options 66, 67, and 43.

IPv4 and IPv6 DHCP support

The ZTP process supports the use of IPv4 and IPv6 DHCP clients to obtain the provisioning file.

For ZTP processes, the node transmits both IPv4 and IPv6 discovery and solicitation messages. If offers arrive from both IPv4 and IPv6 servers, both offers are cached and the first offer received is processed. If the first offer does not fulfill the ZTP requirements and is rejected, the second offer is processed and accepted or rejected. If both offers received on an interface are rejected, ZTP goes to the next interface.

The provisioning file only allows file transfer in the address family of the DHCP offer that is used. If the offer is IPv4, the provisioning files are downloaded using IPv4. If the offer is IPv6, the provisioning files are downloaded using IPv6.

IPv4 route installation details

Option 3 (default route) and Option 121 (classless static route) are supported for IPv4 DHCP.

For identical routes with different next hops, only the first route is installed and the second route is kept as a backup route. ECMP is not supported.

There is no route limit for Option 121.

IPv6 DHCP/RA details

IPv6 DHCP offers do not contain an IP prefix. The IPv6 prefix is usually obtained from the IPv6 RA arriving from the upstream router. For ZTP, the 7750 SR is a host; therefore, the system assigns a /128 prefix to the IPv6 address obtained from the DHCP offer.

The 7750 SR supports the use of an IPv6 RA to install IPv6 default and static routes from upstream routers. The system installs all the routes advertised using the RA. If the same route has been advertised from multiple upstream routers (next hops), the system installs the route with the highest preference. The 7750 SR does not support ECMP if the same route is advertised from multiple next hops by multiple RAs.

In accordance with RFC 4861 recommendations, the 7750 SR ensures that all RAs are obtained before the auto-provisioning process is started for IPv6. RFC 4861 recommends that the host (in this case, the 7750 SR) send a minimum of three route solicitations to increase the likelihood of at least one route solicitation being received by the upstream routers.

Each route solicitation is followed by a 4-second timeout, so the third route solicitation is sent 8 seconds after the first. The upstream routers must respond within 0.5 seconds. As a result, the 7750 SR receives all RAs and routes within 8.5 seconds of the first route solicitation, and waits a maximum of 9 seconds to receive all RAs; ZTP always waits 20 seconds to receive all RAs, however, only the first RA received is used.

ZTP and DHCP timeouts

The ZTP timeout is user-configurable with a default value of 30 minutes. See Options and option modification and Configuring the ZTP timeout in the provisioning file for more information. After each ZTP timeout, the node reboots and reattempts the ZTP process. If the ZTP timeout interval expires while the node is executing a DHCP offer or downloading files, the node does not reboot. The DHCP offer is executed until it succeeds or fails, at which point the node reboots. If the offer is successful, the node comes up in normal operation mode.

The DHCP timeout interval is 20 seconds. If a DHCP offer is not received within the DHCP timeout interval, the auto-provisioning process is reattempted using the next valid interface.

ZTP procedure details

This section describes ZTP procedures including node bootup, BOF, auto-provisioning, logs, and events.

Node bootup

After the node is powered up, the BOF is examined for the auto-boot flag status. If the auto-boot flag is set in the bof.cfg file, the node goes into ZTP mode. If the auto-boot flag is not set in the bof.cfg file, the node continues booting normally.

If it is in ZTP mode, the node provisions all hardware necessary for the ZTP process. This includes the fabric, the first two card slots, and the MDAs for the first two card slots. The node then checks for links on the management (Mgmt) port and valid Ethernet ports.

Note: A bof.cfg file with the auto-boot flag enabled can be shipped as an orderable part with the applicable software license. The auto-boot flag can also be set using the bof auto-boot command.

For more information about the BOF, see BOF.

Reinitiating ZTP during normal node bootup

ZTP can be reinitiated any time by setting the auto-boot flag and configuring the flag options in the BOF. After the auto-boot flag is set, any reboot forces the node into ZTP mode, including DHCP discovery, and downloading and reprocessing the provisioning file. The old BOF is kept in the storage medium until the ZTP process is successful, then the old BOF information is overwritten. If an unsuccessful ZTP process is interrupted and the auto-boot flag is removed, the node boots using the old BOF.

BOF

Two versions of each supported 7750 SR platform software license are currently available: one for non-ZTP bootup, and one for ZTP bootup. Software packages for ZTP bootup contain a bof.cfg file with the auto-boot flag set, which causes the node to automatically boot up in ZTP mode and execute ZTP processes.

The auto-boot flag contains the following information:

  • client ID

    The client ID is sent to the DHCP server to identify the chassis or node and to find a pool for the DHCP offer. If no client ID is configured, the chassis serial number is sent.

    This option is used for both IPv4 client ID and IPv6 DUID Type 2.

  • port (port:vlan)

    The port is used to send DHCP discovery; the port number must be configured manually in the BOF.

    For more information about the BOF, see System Initialization and boot options.

SD card and compact flash support

Nokia recommends that the provisioning file be downloaded to an SD card, and the BOF should point to the SD card for imaging and configuration.

The BOF does not support loading from the network using HTTP or HTTPS.

Auto-boot process

This section describes the ZTP auto-boot process.

Options and option modification

By default, the auto-boot process scans all ZTP-enabled ports to find a port with an operational link. The scanned ports include:

  • out-of-band management port (Mgmt port)

  • Ethernet ports on the first two card or MDA slots (used for in-band management)

    Note: For breakout connectors, only the first breakout port in the connector can be used for ZTP.

ZTP attempts to discover the IP address of the node through DHCP and identifies the node using DHCP client ID Option 61 (IPv4) or Option 1 (IPv6). The client ID uses the chassis serial number by default. The chassis serial number is visible on the shipping box of the chassis.

Supported DHCP client options for ZTP lists the default DHCP client options for ZTP. Some client options can be manually configured in the BOF using the bof auto-boot command.

The auto-boot configuration options are as follows:
management port
Specify that ZTP should only be performed using the out-of-band management port (Mgmt port).
in-band VLAN
Specify ZTP should only be performed using Ethernet ports on the first two card or MDA slots. The VLAN ID can be used to specify an in-band VLAN to use for the auto-boot process.
IPv4, IPv6
Specify that IPv4 discovery, IPv6 discovery, or both, should be performed. If both are specified, the system dual-stacks.
client identifier
Identify the node to the DHCP server and find a pool for DHCP offers. This information is sent using Option 61 (IPv4) or Option 1 (IPv6). If the client-identifier options are not configured, the chassis serial number is sent by default. This option is used for both IPv4 client ID and IPv6 DUID Type 2.
include user class
You can specify to include Option 77.
timeout
You can specify in minutes the timeout for the ZTP process to be executed successfully before the node is rebooted and ZTP is retried because of an unsuccessful ZTP completion. The default ZTP timeout is 30 minutes.
See Configuring the ZTP timeout in the provisioning file for information about how to configure the ZTP timeout in a ZTP provisioning file.

The auto-boot options can be modified using the bof auto-boot command, or by interrupting the bootup process and manually modifying the bof.cfg file.

Caution: Manually modifying the bof.cfg file is not recommended. When modifying auto-boot options using CLI, all required options must be explicitly configured because the default cases are not used. When modifying the bof.cfg file manually, the format must be correct.

CLI access

The auto-boot process is executed in the background and does not block CLI usage. The user can enter CLI commands while the auto-boot process is running in the background. A warning message is displayed to notify the user that the auto-boot process is being executed. Any configurations performed using the CLI may be lost when the node reboots following successful auto-boot and auto-provisioning processes. After the node has finished booting and if the auto-boot flag is set in the BOF, the node displays the login prompt.

The user can access the CLI using a console and can change and save the BOF configuration; the user can remove or modify the auto-boot option in the BOF.

Interrupting auto-boot

The auto-boot process can be interrupted using the tools>auto-boot terminate command. After the auto-boot process is terminated, use the bof auto-boot command to modify the auto-boot flag.

Note: The auto-boot flag can also be modified without interrupting the auto-boot process.

Auto-provisioning process

In this process, the node detects operational ports, attempts to discover its IP address, and downloads the relevant files for provisioning.

  1. The node sends a DHCP discovery request to the DHCP server using the out-of-band management port. If DHCP discovery is unsuccessful, the node reattempts it using the in-band management ports.

  2. After DHCP discovery is successful, the DHCP server returns an IPv4 or IPv6 FTP or HTTP URL of a file server from which the node can retrieve provisioning information.

  3. The node downloads the provisioning information and performs the auto-provisioning according to the specifications in the files.

  4. After the node is successfully provisioned, it automatically reboots and becomes operationally up.

See Provisioning files for more information about the auto-provisioning process.

The SR OS can also initiate the auto-provisioning process using a tools command.

VLAN discovery

The node can perform VLAN discovery if it is shipped in ZTP mode. VLAN discovery is supported only for the in-band management port. It is not supported for the out-of-band management ports.

After the node is installed and powered up:

  1. ZTP is attempted on the null (untagged) port first, including the out-of-band management port, and then on all in-band management ports with operational links.

    1. SR OS scans each port with an operational link and sends IPv4 DHCP discovery messages.

    2. SR OS waits for the DHCP offer within the DHCP timeout.

  2. The first VLAN with a valid offer that includes the IPv4 DHCP Options 66 and 67, or Option 67 or 43, or IPv6 DHCP Option 59 or 17 is selected as the working VLAN and the ZTP process is executed on this VLAN.

    Note: If there is no offer or the offer does not have the relevant or correct options, SR OS floods the network with DHCP discovery messages on all remaining non-reserved VLANs (1 to 4094).
  3. When a VLAN is discovered, the ZTP process is executed on the respective VLAN as described in the following sections.

    Note: If there is no offer on any VLAN or the offer does not have the relevant or correct options, the node starts over from step 1.
VLAN discovery option

By default, the auto-boot flag in the bof.cfg file has the VLAN discovery option enabled. The option can be disabled manually in the bof.cfg file or implicitly from the CLI bof menu, using the command bof auto-boot inband. When the VLAN discovery option is disabled, the node executes the ZTP process using the untagged method only.

Auto-provisioning procedure

After the node enters ZTP mode, the auto-discovery process is executed to provision the necessary hardware for node discovery.

The following are the operational steps of the auto-discovery process.

  1. DHCP is used to discover the IP address of the node.

  2. Options 66 and 67, or Option 43 is used to find and download the provisioning file.

    The provisioning file includes the location of necessary files, such as configuration information, system image, and licenses, along with the DNS needed to resolve these location URLs. The file also includes BOF information required to boot the node into operational mode.

  3. The provisioning file is executed to download the named files to the node.

  4. After all files are successfully downloaded, the node is rebooted and the auto-boot flag is cleared from the BOF.

After the node reboots, it comes up in normal operational mode.

The node can be put back into ZTP mode by editing the BOF to include the auto-boot flag and saving the BOF. Doing this causes the node to enter ZTP mode after it is rebooted.

Use one of the following methods to run the auto-provisioning process.

  • automatic execution

    The auto-boot process automatically executes the auto-provisioning process if the auto-boot flag is set in the BOF.

  • manual execution

    The auto-provisioning process can be executed manually using the tools perform system auto-node-provisioning command.

    If the auto-provisioning process is executed manually, only interfaces without IP addresses are considered part of the discovery mechanism. Additionally, while the process is running, it attempts to discover DHCP servers using all card or MDA slots and ports with Layer 3 interfaces that do not have IP addresses.

    Note: Using the tools perform system auto-node-provisioning command while the auto-boot process is running is not allowed.

Out-of-band management versus in-band management

The auto-provisioning process can use the out-of-band management port (Mgmt port) or in-band management on Ethernet ports.

The node attempts the auto-provisioning process using any port with an operational link, starting with the out-of-band management port. If the node cannot be discovered using the out-of-band management port, either because the port is down or is not receiving a DHCP offer from the DHCP server, the process is reattempted using the Ethernet ports. If the Ethernet ports fail, the management port is tried again and the cycle repeats sequentially.

The following operational guidelines apply to in-band and out-of-band management ports.

  • Out-of-band management and in-band management support untagged frames.

  • Out-of-band management does not support dot1q (VLAN tags).

  • In-band management supports dot1q interfaces if the VLAN is correctly configured in the BOF.

  • In-band ports support VLAN Discovery for IPv4 by default, if not disabled in the BOF.

If out-of-band management is used, no card or MDA provisioning is necessary and the auto-provisioning process executes as soon as an active link is detected on the Mgmt port.

To use out-of-band management exclusively, use the following command:

bof auto-boot management-port

To use in-band management exclusively, use the following command:

bof auto-boot inband vlan
Supported in-band management ports

See ZTP overview for information about which ports support in-band management for ZTP.

Provisioning files

Provisioning files are created by the operator, based on requirements and the locations of the necessary files. A provisioning file contains the locations and URLs of critical files, such as the system image, configuration files, and necessary licenses, and can also contain DNS server information used to resolve these locations.

A provisioning file consists of two main parts:

  • location of file types

    Contains locations of the following file types:

    • system image

    • configuration files

    • licenses

    These items can be downloaded using HTTP, HTTPS, or FTP; DNS server information can also be included.

    Note: If classic configuration mode is required when booting with ZTP, configuration files must have exit all as the first executable line.
  • BOF information

    BOF information can be loaded on the node after the ZTP processes are completed; the BOF portion of the file must be formatted correctly.

    Caution: Ensure that the auto-boot flag is not set on the BOF to be downloaded by the auto-provisioning process. Failure to do so causes the node to go back into ZTP mode after it reboots.

    The provisioning file is stored on the SD card and can be executed using the following command to re-download the named files:

    tools perform system auto-node-provisioning file

Provisioning file download

The provisioning file location is discovered using DHCP offer Options 66, 67, or 43, and is downloaded using HTTP or FTP.

The provisioning file URL can be resolved using DNS, in which case up to three DNS server IP addresses should be present in the DHCP offer using Option 6 (IPv4). The DHCP DNS is only used for resolving the provisioning file URL, and not for resolving the URLs of the files named within the provisioning file.

ZTP does not support Option 15 domain names; the URL of the provisioning file should be in ‟host/domain” format, or a simple IP address should be used.

Provisioning file resolution using DNS

If the downloaded provisioning file includes a DNS IP in the DNS section of the file, the URLs of the files in the provisioning file must be resolved using this DNS server or by the DNS server listed in the DHCP offer.

Up to three DNS addresses (primary, secondary, tertiary) can be listed in the DNS section of the provisioning file. If all three DNS addresses are listed, they are attempted in the order they are listed, to resolve the file URLs.

File download and redundancy

Up to three locations can be set for each file type, using the primary-url, secondary-url, and tertiary-url fields. The auto-provisioning process attempts to download all files using the primary-url information for each file. If this attempt is unsuccessful, the process reattempts using the secondary-url information for each file. If this attempt is not successful, the process reattempts, using the tertiary-url information.

A ZTP operation is considered successful when all files named in the provisioning file are downloaded. If all file locations are attempted and all named files are not successfully downloaded, the auto-provisioning process fails and ZTP reattempts the provisioning process using the next valid interface.

Configuring the ZTP timeout in the provisioning file

The ZTP timeout is the total time allowed for the ZTP process to execute successfully. If the ZTP process fails to run successfully within the ZTP timeout duration, the node is rebooted and the ZTP process is retried. The default timeout is 30 minutes.

See Options and option modification for information about how to configure the ZTP timeout using CLI commands.

ZTP timeout information can be included in the provisioning file to configure a value different from the default. For a provisioning file example, see Example provisioning file. The following example shows how the timeout is added to the provisioning file to change the default value.

set {
  timeout hours 1
  timeout minutes 30
}

Downloading the image file

The image file can be downloaded in the following ways:

  • Extract the images from the OLCS CFLASH file and explicitly list them in the provisioning file. Each of the .tim files is validated and the version of the software is checked. The hash-value must be explicitly listed.
    download {
      image "$(BOOT-PATH)/both.tim" {
        primary-url "$(FILESERVER)/both.tim"
          verification {
              hash-algorithm sha256
              hash-value "53473e2727caf55f3a38fa466622af2147762e26a8587e9248240a572cdee849"
          }
    
      }
      ……..
    }
    
  • Zip the image files and perform a single image download. ZTP can extract the images and verify the .tim file and software version. An additional file can also be listed for all files to be verified using sha256 or md5.
    download {
      image "$(BOOT-PATH)/images.zip" {
          primary-url "$(FILESERVER)/images.zip"
          unzip
          verification {
              hash-algorithm sha256
              hash-value "53473e2727caf55f3a38fa466622af2147762e26a8587e9248240a572cdee849"
          }
      }
      # SHA-256 Checksum Files - File of a list of SHAR256 checksum values and file names (must be absolute)
      sha256 "$(BOOT-PATH)/somefile.txt" {
          primary-url "$(FILESERVER)/sha256-checksums.txt"
          verification {
              hash-algorithm sha256
              hash-value "53473e2727caf55f3a38fa466622af2147762e26a8587e9248240a572cdee849"
          }
      }
    }
    

Example provisioning file

This section provides examples of provisioning file information.

Provisioning file information
set {
    hours 1
    minutes 30
}
dns {
      primary 192.0.2.1
      secondary 192.0.2.2
      tertiary 192.0.2.3
      domain sample.domain.com
}
download {
  image "cf3:/both.tim" {
    primary-url "http://192.168.40.140:81/both.tim"
    secondary-url "http://192.168.40.140:81/both.tim"
    tertiary-url "http://192.168.40.140:81/both.tim"
  }
  image "cf3:/support.tim" {
    primary-url "http://192.168.40.140:81/support.tim"
    secondary-url "http://192.168.40.140:81/support.tim"
    tertiary-url "http://192.168.40.140:81/support.tim"
  }
  config "cf3:/config.cfg" {
    primary-url "ftp://ftpserv:name@192.168.194.50/./images/dut-a.cfg"
    secondary-url "http://192.168.41.140:81/dut-a.cfg"
    tertiary-url "http://192.168.42.140:81/dut-a.cfg"
  }
  file "cf3:/license.txt" {
    primary-url "ftp://ftpserv:name@192.168.194.50/./images/provision_example.cfg"
    secondary-url "http://192.168.41.140:81/dut-a.cfg"
    tertiary-url "http://192.168.42.140:81/dut-a.cfg"
  }
}
bof {
  primary-image cf3:/both.tim
  primary-config cf3:/config.tim
  address 192.168.100.1 active
  autonegotiate
  duplex full
  speed 100
  wait 3
  persist off
  console-speed 115200
}

For an HTTPS URL, the trust anchor needs to be referenced in the provisioning file. The trust anchor name references the entry in the import>trust-anchor section of the file. In the following example, the trust anchor name is TRUST_ANCHOR.

Trust anchor for HTTPS URL in provisioning file
import {
    client {
        cert "cf3:/client.crt" {
            format pem 
            primary-url http://10.10.10.67:81/client.crt 
        } 
        key "cf3:/client.key" { 
            format pem 
            primary-url http://10.10.10.67:81/client.key 
        } 
    } 
    trust-anchor TRUST_ANCHOR{ 
        cert "cf3:/ca.crt" { 
            format pem 
            primary-url ftp://user-name:password@10.10.10.66//user-name/logs/
fileserver-4/ca.crt 
        } 
        crl "cf3:/ca.crl" { 
            format der 
            primary-url ftp://user-name:password@10.10.10.66//user-name/logs/
fileserver-4/ca.crl 
        } 
    } 
} 
<snip> 
    download { 
      config "cf3:/ztp/ztp_dut-a.cfg" { 
        primary-url "https://10.10.10.64:81/ztp_node-2.cfg" 
        primary-trust-anchor "TRUST_ANCHOR" 
  } 

Proxy support

HTTP and HTTPS can connect to public servers using a proxy. The proxy is in URL format and the URL must be resolved using the provisioning file DNS.

The proxy can include a username and password. Proxy Auto-Configuration (PAC) is not supported.

Proxy information formatting is as follows:

http://user@hostname:file-path

https://user@hostname:file-path

proxy http://ip-or-url user@hostname:port

The HTTP (or HTTPS) proxy support information is included in file commands and in the ZTP provisioning file. The following example shows HTTP proxy information in the provisioning file.

image "cf3:/both.tim" {
    primary-url "http://200.150.40.140:81/both.tim"
    secondary-url "http://200.150.40.140:81/both.tim"
    tertiary-url "http://200.150.40.140:81/both.tim"
    primary-proxy http://132.2.3.1:8080
    secondary-proxy http://133.3.4.1:8080
  }

Day 0 configuration

To improve initial router functionality and reuse information discovered by ZTP in the configuration file, the user can include an optional day 0 configuration template within the provisioning file. This day 0 configuration template can obtain configuration details for specific modules that can be used to provision the node and establish node connectivity. Predefined symbols are used to add parameters discovered by ZTP, such as the port and VLAN, to the configuration template.

Any configuration supported by SR OS can be included in the day 0 configuration template, including configuration of port types and services. However, Nokia recommends that day 0 configuration details should be kept to the minimum necessary to ensure that basic network connectivity is available for the ZTP process to run and complete.

Caution:

Before using the configuration, verify the configuration details in the day 0 template and check for syntax, context, and other errors. The ZTP process does not verify the configuration details before implementing them.

When the provisioning file is received through the ZTP process, the day 0 configuration template section of the provisioning file is converted to a configuration file and stored on the SD card of the node, as specified by the Write cf3:/configuration-file-name.cfg entry within the template. The BOF section of the provisioning file must specify the configuration file generated from the day 0 configuration template using the primary-config cf3:/configuration-file-name.cfg entry.

Some unknown elements within the day 0 configuration template can be entered as symbols, which are then converted to discovered information as the node is provisioned; see Day 0 symbols.

See Sample day 0 configuration template for a configuration example, including the day 0 configuration template and associated BOF section of the provisioning file.

Day 0 configuration for multislot routers

On multislot routers, the discovered IOMs, MDAs, IMMs, and fabric (that is, the discovered hardware) are part of the day 0 configuration. ZTP automatically adds the CLI configuration to the correct location in the day 0 configuration in the provisioning file.

This process ensures that the nodes for different sites are populated with the correct hardware, regardless of what physical hardware is used for a specific site.

The day 0 configuration process for multislot routers is as follows:

  1. The provider creates a day 0 configuration template with the required services and interfaces.
  2. ZTP provisions the IOMs, MDAs, IMMs, and fabric.
  3. ZTP discovers the port and VLAN on which the DHCP server is connected.
  4. ZTP adds the discovered and provisioned hardware to the day 0 configuration in the provisioning file
  5. ZTP uses the day 0 configuration in provisioning file to create an initial configuration file and saves it to the specified location on the SD card of the node.

    The BOF section of the provisioning file must specify the configuration file generated from the day 0 configuration.

  6. After rebooting, the node boots up using the day 0 configuration file.

Day 0 symbols

Use symbols to generalize and reuse a single provisioning file across multiple ZTP deployments and for value substitutions and conditions in the day 0 configuration template of the provisioning files. The same symbol can appear as many times as required and can be used for both conditional statements and substitutions.

Symbol use for substitution

A day 0 configuration template can include symbols that are replaced with discovered information when the day 0 configuration is implemented. Symbols for substitution must be entered using the format $(<symbol-name>). The following example shows a supported use case of a symbol for substitution.

card $(ztp.bootstrap.slot)
    card-type $(ztp.bootstrap.card-type)
        mda $(ztp.bootstrap.mda)
            mda-type $(ztp.bootstrap.mda-type)
    exit
exit
Symbol use for conditions

A day 0 configuration template can include symbols that are replaced with discovered information when the day 0 configuration is implemented. Symbols for conditions must be entered using the format @(<symbol-name>) at the beginning of a line. If the condition is not met (that is, the symbol does not exist), the rest of the line is skipped and is not written into the day 0 configuration file on the compact flash. The following example shows a supported use case of a symbol for conditions.

@(ztp.uplink.connector)    port (ztp.uplink.connector) 
@(ztp.uplink.connector)    connector 
@(ztp.uplink.connector)    breakout $(ztp.uplink.breakout) 
@(ztp.uplink.connector)    exit 
@(ztp.uplink.connector)    exit 
Supported symbols

The following table describes the supported symbols for a day 0 configuration template.

Table 3. Supported symbols
Symbol name Description Example value Conditional Discovered
sys.platform Platform name "7750" No. Always available. Configured for the system and is exposed at system boot-up
sys.type Chassis type "SR-7" No. Always available. Configured for the system and is exposed at system bootup
sys.serial-number Serial number of the chassis “NS1234567” No. Always available. Configured for the system and is exposed at system bootup
sys.mac-address Base chassis MAC of chassis “01:01:01:01:01:01” No. Always available. Configured for the system and is exposed at system bootup
ztp.bootstrap.uplink Full uplink used for bootstrap (including VLAN). Intended to be used as interface port binding in the day 0 configuration.

“1/1/1”

“1/1/1:1000”

“A/1”

No. Always available. Discovered at VLAN discover or ZTP discovery time
ztp.bootstrap.uplink.card-type Card-type of uplink slot used for bootstrap “xcm-1s” Yes. Available when uplink is inband. Discovered at VLAN discover or ZTP discovery time
ztp.bootstrap.uplink.slot Slot of uplink used for bootstrap “1” Yes. Available when uplink is inband. Discovered at VLAN discover or ZTP discovery time
ztp.uplink.xiom Xiom identifier of uplink used for bootstrap “x1” Yes. Available when uplink is inband and has an xiom. Discovered at VLAN discover or ZTP discovery time
ztp.uplink.xiom-type Xiom-type of xiom used for bootstrap Iom2-se-6.0t” Yes. Available when uplink is inband and has an xiom. Discovered at VLAN discover or ZTP discovery time
ztp.uplink.mda The MDA number of the MDA used for bootstrap (This will either be the MDA under card or MDA under xiom if uplink has xiom) “1” Yes. Available when uplink is inband. Discovered at VLAN discover or ZTP discovery time
ztp.uplink.mda-type The MDA number of the MDA used for bootstrap (This will either be the MDA under card or MDA under xiom if uplink has xiom) “m4-sfp” Yes. Available when uplink is inband. Discovered at VLAN discover or ZTP discovery time
ztp.bootstrap.uplink.port Uplink port without encapsulation value (VLAN) 1/2/c1/1 No. Always available. Discovered at VLAN discover or ZTP discovery time
ztp.bootstrap.uplink.vlan Uplink VLAN (encapsulation value) “1000” Yes. Available when uplink has a vlan. Discovered at VLAN discover or ZTP discovery time
ztp.bootstrap.connector Uplink connector ID 1/1/c1 Yes. Available when uplink is a connector-port. Discovered at VLAN discover or ZTP discovery time
ztp.bootstrap.breakout Connector breakout type c1-10g Yes. Available when uplink is a connector port. Discovered at VLAN discover or ZTP discovery time
ztp.bootstrap.rs-fec Connector RS-FEC mode setting Yes. If connector has a non-default rs-fec mode setting. Discovered at VLAN discover or ZTP discovery time
ztp.bootstrap.uplink.rs-fec Uplink port RS-FEC mode setting Yes. If uplink port has a non-default rs-fec mode setting. Discovered at VLAN discover or ZTP discovery time
ztp.bootstrap.uplink.speed Uplink port speed setting Yes. If uplink port has a non-default speed setting Discovered at VLAN discover or ZTP discovery time
Ztp.bootstrap.ip IP address used during bootstrap (IPv4 or IPv6)

1.2.3.4

1::344:2

No. Always available. Discovered via DHCP offer
Ztp.bootstrap.prefixlen The prefix length of the IP address used under interface during bootstrap No. Always available. Discovered via DHCP offer

Sample day 0 configuration template

The following is a sample of a day 0 configuration template included in a provisioning file.

# Generate Day-0 Configuration
# ----------------------------
Write "cf3:/config-template.cfg" {
#########################
# !!DAY0 CONFIG START!! #
#########################
exit all
configure
#--------------------------------------------------
echo "System Configuration"
#--------------------------------------------------
    system
        name "chassis-name"
        snmp
        exit
        login-control
            idle-timeout disable
        exit
        time
            ntp
                server 192.168.194.202
                no shutdown
            exit
        exit
        thresholds
            rmon
            exit
        exit
    exit
#--------------------------------------------------
echo "System Security Configuration"
#--------------------------------------------------
    system
        security
            telnet-server
            ftp-server
            snmp
                community "private" rwa version both
                community "public" r version both
            exit
        exit
    exit
#--------------------------------------------------
echo "Log Configuration"
#--------------------------------------------------
    log
        snmp-trap-group 90
            trap-target ‟”
        exit
        log-id 90
            from main change
            to snmp
        exit
    exit
exit all
configure
    router
#--------------------------------------------------
echo "IP Configuration"
#--------------------------------------------------
        interface "IF-1/1/c1/1"
            port $(ztp.bootstrap.uplink)
            address 192.168.0.1/31
            ipv6
            exit
            no shutdown
        exit
    exit
exit all
#########################
# !!DAY0 CONFIG END!!   #
#########################
}
# Generate New BOF File
# ---------------------
bof {
  primary-image  cf3:/image.both
  primary-config cf3:/config-template.cfg
  autonegotiate
  duplex full
  speed 100
  wait 3
  persist off
  console-speed 115200
}

Logs and events

ZTP displays detailed events about all stages of the auto-boot and auto-provisioning processes. All events are saved in a log file on the SD card at the end of the ZTP process.

SZTP

The SR OS implementation of SZTP is a partial application of RFC 8572 and is evolving to meet all RFC 8572 aspects. SZTP is an extension of ZTP as follows:

  • The provisioning file and the node discovery of the MDAs, IOMs, and ports with links up are supported in both ZTP and SZTP.
  • The ports that are ZTP-capable are also SZTP-capable.

SZTP securely bootstraps the node and provides it with the information required to boot up the node in an operational mode; this information includes all the initial artifacts required to create a mutual trust relationship between the node and the bootstrap server. After the node boots, it discovers the bootstrap server IP address, communicates with the server, and authenticates both the server and itself. Finally, the node securely downloads the encrypted boot image and initial configuration information.

SR OS uses different bootstrapping methods to obtain the required TLS certificates, trust anchors, and redirect information to connect securely to the server and download all the necessary information to boot in an operational mode.

Figure 4. SZTP process

In the example shown in the preceding figure, one of the following methods can be used to bootstrap the node securely.

  • The operator stages the node at their own site and bootstraps it using ZTP through a secure or private network. The node obtains the TLS certificates, trust anchors, and keys from a conveyed information file, which must be copied into the compact flash (CF). The Uniform Resource Identifier (URI) of this file is included in the ZTP provisioning file.
  • If the node has CF, the operator copies manually to the CF the certificates, trust anchors, and conveyed information file. Optionally, the operator can also include redirect information in the conveyed information file.

After the node is bootstrapped securely, it is shipped to the installation site, where it boots.

If the node has redirect information, it tries to connect the bootstrap server specified in the redirect information and establish a TLS session to create mutual trust between the node and the server.

If the node does not have redirect information, it performs a DHCP discovery and tries to obtain the redirect information using DHCP option 143 (IPv4) or 136 (IPv6). After obtaining the redirect information, the node tries to connect to the bootstrap server using TLS.

The node uses option 67 from the DHCP server or the URI from the file field of the redirect information to locate the conveyed information from the bootstrap server. The conveyed information provides the node with one of the following:

  • more redirect information for a new file server and other required resources to connect to the file server to download all the required information and files
  • onboarding information containing the URI of the boot image and the initial configuration
  • both redirect information and onboarding information, in which case the node executes the onboarding information first and then executes the redirect information

Staging the secure environment

The following artifacts are required:

  • node client certificates and keys
  • bootstrap server certificates for the first redirect
  • security artifacts file, which contains the trust anchor definitions and import instructions. Optionally, this file can also contain conveyed information, which consists of redirect, if applicable, and onboarding information.
The staging options are the following.
  • Copy the artifacts to a CF that can be installed in cf1:, cf2:, or cf3: when the node is at the installation site.
  • Alternatively, use ZTP to pre-stage the node and download the root security artifacts using a trusted DHCP server and provisioning file.

Bootstrapping methods

The following bootstrapping methods are supported.
  • Use DHCP option 143 (IPv4) or 163 (IPv6), as described in RFC 8572. Optionally, the operator can obtain the specific node URI (server and directory) by providing the DHCP server option 61 for the DHCP server, which in turn provides option 67 for the file directory, or option 143 (IPv4) or 163 (IPv6) with the server IP and file directory information. In this case, the TLS certificates, trust anchors, and keys must be installed on the node at the operator premises.
  • Copy the following information to the CF:
    • redirect information for the bootstrap server
    • TLS certificates and trust anchors, and private keys
    • onboarding information
  • Use ZTP to provide the following information to the node:
    • redirect information for the bootstrap server
    • TLS certificates and trust anchors, and private keys
    • onboarding information
  • Redirect the node from the first bootstrap server to consecutive bootstrap servers. The bootstrap server can provide the node with additional redirect information in a secure encrypted manner. The redirect and onboarding information are provided in the conveyed information file.
    • redirect information to another bootstrap server
    • required TLS certificates and trust anchors, and private keys
    • onboarding information

Installation site process

At the installation site, the auto-boot flag in the BOF signals the ZTP process. The presence of a conveyed information file on the node signals to the node that it is a secure ZTP procedure.

The following figure shows the SZTP process at the installation site.

Figure 5. Installation site SZTP process

After staging, the port that has the link up is selected and SZTP is executed on it.

The node loads the security artifacts to install the TLS certificates and trust anchors. DHCP discovery messages are sent out on each port in sequence. If no DHCP offer is received, SZTP moves to the next port with the link up. The OOB port is examined first, followed by the untagged in-band ports. If no DHCP offer is received, VLAN discovery is performed on the in-band ports only by flooding VLAN 0 to 4196 with DHCP discovery.

After DHCP discovery completes, the node obtains an IP address and can optionally obtain option 143 (IPv4) or option 136 (IPv6) for redirect information. If the redirect information is present in the conveyed information file, it is preferred over the DHCP redirect information.

The node is connected to the bootstrap server as indicated by the redirect information and a TLS mutual authentication is established using the certificates. The bootstrap server must have the correct certificates, keys, and trust anchors to create the mutual TLS trust.

After the node authenticates the server and authenticates itself to the server, it downloads the conveyed information file from the server using HTTPS. The node obtains the server location of the conveyed information from DHCP option 67 or the file field in the redirect information.

If the conveyed information file contains redirect information, the node tries to connect to the new bootstrap server indicated in the new redirect information. The node can download the new certificates indicated in the conveyed information.

If the conveyed information file contains only onboarding information, the node downloads the onboarding file.

If the conveyed information file contains both onboarding and redirect information to the next bootstrap server, the node executes the onboarding information first, then the redirect information.

The process is successful if the node executes the onboarding information without errors.

Initial conveyed information file

The conveyed information file (also referred to as conveyed-info.ztp file) contains the certificates, keys, and trust anchors required to establish the TLS connection. This is the minimum information that the node requires to start SZTP after staging at the installation site. The initial file must be added to cf3: by copying it on the CF manually or using regular ZTP procedures and the provisioning file.

The following example shows the contents of a conveyed information file.

import {
   client {
      cert "cf3:/artifacts/node.cert"
      key "cf3:/artifacts/node.key" {
         format der
      }
   }
   trust-anchor BOOTSERVER {
      cert "cf3:/artifacts/bootserver.cert"
   }
}
The certificates, keys, and trust anchor information can be encrypted using the encrypt command, as shown in the following example. When the encrypt keyword is present, the information is downloaded from the URI and encrypted using AES256.
import {
   client {
      encrypt
      cert "cf3:/artifacts/node.cert"
      key "cf3:/artifacts/node.key" {
         format der
      }
   }
   trust-anchor BOOTSERVER {
      encrypt
      cert "cf3:/artifacts/bootserver.cert"
   }
}

Optionally, the file can contain the redirect information as shown in the following example. It is not mandatory to include the redirect information in the file because the preliminary redirect information can be obtained using DHCP.

Note: The redirect information in the file is preferred over the DHCP redirect information because it is trusted.
import {
   client {
      encrypt
      cert "cf3:/artifacts/node.cert"
      key "cf3:/artifacts/node.key" {
         format der
      }
   }
   trust-anchor BOOTSERVER {
      encrypt
      cert "cf3:/artifacts/bootserver.cert"
   }
}

redirect-information {
   boot-server "https://mybootserver.com/" {
      port 50
      trust-anchor BOOTSERVER
      file "conveyed.info"
   }
   boot-server "https://backupserver.com/" {
      port 50
      trust-anchor BOOTSERVER
      file "conveyed.info"
   }
}

The following example shows a file containing the entire conveyed information, including redirect and onboarding information. See Onboarding information.

import {
   client {
      encrypt
      cert "cf3:/artifacts/node.cert"
      key "cf3:/artifacts/node.key" {
         format der
      }
   }
   trust-anchor BOOTSERVER {
      encrypt
      cert "cf3:/artifacts/bootserver.cert"
   }
}

redirect-information {
   boot-server "https://mybootserver.com/" {
      port 50
      trust-anchor BOOTSERVER
      file "conveyed.info"
   }
   boot-server "https://backupserver.com/" {
      port 50
      trust-anchor BOOTSERVER
      file "conveyed.info"
   }
}
onboarding-information {
   boot-image
      download-uri https://images.com/$(sys.platform).zip
   pre-configuration-script "https://config.com/provisioning.cfg"
}

Onboarding information

The onboarding information is required to obtain all critical resources to boot the node in the normal mode of operation with the latest boot image and configuration. When processing the onboarding information, the device must first process the boot image information (if any), then execute the preconfiguration script (if any).

The onboarding information is present in the conveyed information file only. See Conveyed information. The following example shows onboarding information.

onboarding-information {
   boot-image
      download-uri https://images.com/$(sys.platform).zip
   pre-configuration-script "https://config.com/provisioning.cfg"
}

The download-uri is the URI to the boot image in ZIP format only. A URI list can exist, each pointing to the primary, secondary, or tertiary images.zip file. SR OS has multiple images, for example, CPM image and IOM image, and these images can be downloaded in a ZIP file. The URI can point to the ZIP file bundle to download all the images from a primary source. If the image is downloaded using download-uri, the destination of the image is always cf3:.

The following example shows the download-uri information.

onboarding-information {
   boot-image {
      # Download-URI(Mandatory): URL to ZIP file of images. Up to 3 for primary, secondary, tertiary
      # -> Base directory is "cf3:/"
      download-uri "https://server.download.com/images.zip"
      download-uri "https://server2.download.com/images.zip"
      download-uri "https://server3.download.com/images.zip"
      # VERIFICATION (Optional): File within ZIP file to verify images
      image-verification {
         hash-algorithm sha256
         hash-value "53473e2727caf55f3a38fa466622af2147762e26a8587e9248240a572cdee849"
      }
   }

   # Another provisioning file that can be loaded. Downloaded as "cf3:/autoboot.cfg.1,2,3" based on chaining
   pre-configuration-script "https://server.file.com/someotherprovisioningfile.txt"
}

Optionally, the node can run a checksum on the downloaded ZIP file using a hash to ensure there are no download errors. The hash algorithm and the hash value are noted in the onboarding information, as shown in the previous onboarding information example. The supported hash algorithms are SHA256 and MD5.

The preconfiguration script can be used to download the provisioning file. The provisioning file and the ZTP provisioning file have the same format. The provisioning file has to be executed to completion for the ZTP process to be successful. The provisioning file can also contain the location of the image. The image can be downloaded using the download URI or the provisioning file. When downloading the image using the provisioning file, the destination of the image can be dictated. The BOF must be configured accordingly to boot from the image destination. The image destination must always be cf3: or a folder in cf3:.
Note: The preconfiguration script is always required to clear the auto-boot flag from the BOF. A minimal BOF configuration is required in the provisioning file.
Preconfiguration script

The preconfiguration script is the actual ZTP provisioning file. SZTP supports all features of the ZTP provisioning file.

The preconfiguration script and provisioning file must be executed by the onboarding information to update the BOF configuration and remove the auto-boot flag. This ensures that the node comes back up in a normal mode of operation. For examples of the preconfiguration script and provisioning file information included in the onboarding information, see Onboarding information.

Additional capabilities in the ZTP provisioning file

The following optional capabilities of the provisioning file are supported for both ZTP and SZTP:

  • checksum for file download
    SHA256 and MD5 are supported. The hash algorithm and hash value can be specifically configured for the file as shown in the following example. The file checksum is checked against the hash algorithm and hash value.
    # List of Configuration Files to download
    config "$(BOOT-PATH)/somefile.txt" {
     primary-url "$(FILESERVER)/somefile.txt"
            verification {
                    hash-algorithm sha256
                              hash-value
    "53473e2727caf55f3a38fa466622af2147762e26a8587e9248240a572cdee849"
            }
    }
  • file encryption using AES256
    When a file is downloaded and if the file has the encrypt keyword enabled in the provisioning file, the file is encrypted using AES256 and placed on the CF. This is useful when downloading certificates, keys, and trust anchors for TLS. The following example shows an excerpt from the provisioning file. In this example, in the certificate import the keyword encrypt is used to encrypt each file on the CF after the file was downloaded. In addition, the checksum is calculated on each file and checked to ensure the files are downloaded without errors.
    import {
        client {
             cert "$(CERT-PATH)/device.crt" {
                 primary-url "$(FILESERVER)/device.crt"
                     encrypt
                        verification {
                            hash-algorithm sha256
                                hash-value
    "53473e2727caf55f3a38fa466622af2147762e26a8587e9248240a572cdee849"
                                     }
               }
               key "$(CERT-PATH)/device.key" {
                  format pem
                  primary-url "$(FILESERVER)/device.key"
                           encrypt
                           verification {
                              hash-algorithm sha256
                                     hash-value
    "53473e2727caf55f3a38fa466622af2147762e26a8587e9248240a572cdee849"
                           }
        }
    }
    trust-anchor "NokiaSvcs" {
        cert "$(CERT-PATH)/owner-ca.crt" {
            format pem
            primary-url "$(FILESERVER)/owner-ca.crt"
                     encrypt
                      verification {
                          hash-algorithm sha256
                                 hash-value
    "53473e2727caf55f3a38fa466622af2147762e26a8587e9248240a572cdee849"
                  }
        }
        crl "$(CERT-PATH)/owner-ca.crl"
        format der
        primary-url "$(FILESERVER)/owner-ca.crl"
                 encrypt
                  verification {
                   hash-algorithm sha256
                        hash-value
    "53473e2727caf55f3a38fa466622af2147762e26a8587e9248240a572cdee849"
                  }
         }
        }
    }
  • downloading the image files in ZIP file format

    The files can be downloaded using the provisioning file with an optional checksum. The ZIP file is automatically unzipped and each individual file is placed on the CF. The checksum is checked across the entire ZIP file before it is unzipped.

    Note: The specified directory path must end with a forward slash (/).
    image "$(BOOT-PATH)/images.zip" {
      primary-url "$(FILESERVER)/images.zip"
         unzip {
           directory "cf3:/ztp/"
    }
         verification {
                 hash-algorithm sha256
           hash-value
    "53473e2727caf55f3a38fa466622af2147762e26a8587e9248240a572cdee849"
            }
    }
  • downloading a SHA256 or MD5 checksum file

    The user can download a SHA256 or MD5 checksum file from Nokia servers for the ZIP image files. After the image file is unzipped, each *.tim file has its checksum checked against these checksum files.

    The following are examples of checksum files.

    17717f13ecf19179e367d990277e943993d53d771b44d19fddf5d349b1e7e7c4 cf3:/ztp/cpm.tim
    616656b2224e65e29d71355ea41d9dc548c281e9f729c97fe46f3a5c643acb09 cf3:/ztp/iom.tim
    dd9455158dc2dfbf937eb372bbef73ebab97f951efa742eec16a4ed4edd3ca9b cf3:/ztp/support.tim

Checksum or file decryption errors cause the failure of the ZTP or SZTP procedure, in which case the node generates an error and logs the event.

Conveyed information

After SR OS authenticates successfully to the bootstrap server, the node can download the conveyed information using HTTPS. The operator can choose the name of the conveyed information file.

The SR OS conveyed information is trusted and does not require an additional signature verification.

The following conveyed information file example contains only onboarding information.

Onboarding information for conveyed information file
onboarding-information {
   boot-image
      download-uri https://images.com/$(sys.platform).zip
   pre-configuration-script "https://config.com/provisioning.cfg"
}

The conveyed information can also contain redirect information, in which case a recursive redirect can happen to another bootstrap server. If the conveyed information contains onboarding information and redirect information, the node executes the onboarding information first, then the redirect to the next bootstrap server.

The following conveyed information file example contains onboarding and redirect information, and the certificates required for the second redirect.

Onboarding information, redirect files, and certificates for second redirect
onboarding-information {
   boot-image
      download-uri https://images.com/$(sys.platform).zip
   pre-configuration-script "https://config.com/provisioning.cfg"
}
import {
   client {
      cert "cf3:/artifacts/node.cert"
      key "cf3:/artifacts/node.key" {
         format der
      }
   }
   trust-anchor BOOTSERVER {
      cert "cf3:/artifacts/bootserver.cert"
   }
}

redirect-information {
   boot-server "https://mybootserver.com/" {
      port 50
      trust-anchor BOOTSERVER
      file "conveyed.info"
   }
   boot-server "https://backupserver.com/" {
      port 50
      trust-anchor BOOTSERVER
      file "conveyed.info"
   }
}

After the conveyed information is executed successfully, the BOF is loaded in the provisioning file to which the preconfiguration script is pointing and the auto-boot flag is cleared.