Basic system configuration

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.

This section describes DHCP discovery options.

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 more information about RA support, see IPv6 DHCP/RA details. For more information about DHCP server offers, see DHCP server offer options.

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 offers do not contain an IP prefix. The IPv6 prefix is usually obtained from the IPv6 RA arriving from the upstream router. Because the SR OS router is the host for the ZTP process, the system assigns a /128 prefix to the IPv6 address obtained from the DHCP offer.

SR OS 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. SR OS does not support ECMP if the same route is advertised from multiple next hops by multiple RAs.

In accordance with RFC 4861 recommendations, SR OS 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 SR OS router) 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 SR OS router 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.

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

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 node IP via 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 optional 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. The VLAN ID can be used to specify a VLAN to use for the auto-boot process.

• IPv4, IPv6

• 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

  Specify to include Option 77.

• timeout

  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.

The auto-boot process is executed in the background and does not block the CLI. The user can enter CLI commands while the auto-boot process runs 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; as such, the user can remove or modify the auto-boot option in the BOF.

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

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.

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.

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 following command.

  tools perform system auto-node-provisioning

  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 following command while the auto-boot process is running is not allowed.

  tools perform system auto-node-provisioning

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

The provisioning file URL can be resolved using DNS, in which case the IP addresses for up to three DNS servers should be present in the DHCP offer using Option 6 (IPv4) or Option 23 (IPv6). 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.

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 the DNS server listed in the DHCP offer.

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

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.

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.

set {
    timeout {
        hours 1
   }
}

set {
    timeout {
        minutes 90
   }
}

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 primary-trust-anchor is optional when the PKI and TLS security artifacts are already downloaded and the provisioning file configures the TLS client. The hash-value must be explicitly listed.

  download {
    image "$(BOOT-PATH)/both.tim" {
      primary-url "$(FILESERVER)/both.tim"
      primary-trust-anchor "chassis_tls"
        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"
        }
    }
  }
  

This section provides examples of provisioning file information. The example provisioning file is divided into multiple stages to demonstrate the device enrollment process through EST using customer-owned (cust) X.509 certificates. The process initializes the device with customer-owned security artifacts.

###############################
# STAGE 1 (Software Upgrade)
###############################
# Download new Software image
# ------------------------------
download {
  image "cf3:/images2/both.tim" {
     primary-url "https://88.88.4.1/images/sarhmc/both.tim"
     primary-trust-anchor "chassis_tls"
     verification {
        hash-algorithm sha256
        hash-value "e06538ebf127b698934db6df275f7ae4c17126b7307eeee121c9831cd5efd258"
     }
     match-or-replace
  }
  image "cf3:/images2/kernel.tim" {
     primary-url "https://88.88.4.1/images/images/sarhmc/kernel.tim"
     primary-trust-anchor "chassis_tls"
     verification {
        hash-algorithm sha256
        hash-value "697527e98938ad5c76c795686021bc196b338c32337833fc57a664f6fb404fe4"
     }
     match-or-replace
  }
  image "cf3:/images2/support.tim" {
     primary-url "https://88.88.4.1/images/sarhmc/support.tim"
     primary-trust-anchor "chassis_tls"
     verification {
        hash-algorithm sha256
        hash-value "f6f89df550e3c3db1f70f462678349eb40e0e99c5df4a8619b8b7b41bf9a31d9"
     }
     match-or-replace
  }
}
# Update BOF to perform SW Upgrade
bof {
   primary-image    cf3:/images2/
   primary-config   cf3:/site-abcd.cfg
   wait             3
   persist          off
   auto-boot
}
# ++++++++++++++++++++++++
# ****SYSTEM REBOOTS******
# ++++++++++++++++++++++++
# SW Upgrade Complete. Remove old Image to make
# space for firmware
execute {
  file delete cf3:/images1/* force
}
# Move on to STAGE 2 - Firmware Upgrade
# (note next-provisioning-file checks active SW and reboots if needed)
next-provisioning-file cf3:\STAGE2.ztp
###############################
# STAGE 2 (Firmware Upgrade)
###############################
# Initialize cell port and download (on Eth) cellular firmware for update
# Target carrier config: Generic-PTCRB (version Generic-PTCRB 49.00.001 M0V.060001 P0V.071603)
# ZTP skips download/reboot when installed FW already matches version
#
write "cf3:/STAGE2.ZTP" {
cellular {
    carrier "Generic-PTCRB"
    # clear MDA occurs when setting carrier
    pdn-profile {
         apn "internet"
         protocol ipv6
    }
    firmware-upgrade {
        # what is displayed in show port 1/1/1 for firmware
        version "Generic-PTCRB 49.00.001 M0V.060001 P0V.071603"
        file "cf3:/FN920C04-WW_49.00.001_CUST_071603_H1S0_SIGNED_TFL.zip" {
            primary-url "http://88.88.4.1/images/sarhmc/cellular/firmwareFiles/FN920C04-WW_49.00.001_CUST_071603_H1S0_SIGNED_TFL.zip"
            verification {
                hash-algorithm sha256
                hash-value "e2f096f234a1e49afca92cabff58c24789c584c54b4b69a471bad28082af66a9"
            }
        }
    }
    # firmware is updated upon next reboot during provisioning
}
#################################
# STAGE 2b (certificate download)
#################################
download {
  # device's Root CA
  file "cf3:/custRootCA.pem" {
     primary-url "http://88.88.4.1/certs/custRootCA.pem"
     verification {
        hash-algorithm sha256
        hash-value "f6f5319b8dc83f9eb1da292ffcbefbbff068ae9a67ffc8a3f366d211774b4de5"
     }
  }
  # device's intermediary CA
  file "cf3:/custIntermediaryCA.pem" {
     primary-url "http://88.88.4.1/certs/custIntermediaryCA.pem"
     verification {
        hash-algorithm sha256
        hash-value "e0787cbe981fe8a69c9dae3928a6e79f4362e912960a8ff85fdcc817b271b8b3"
     }
  }
  # CRL for root CA
  file "cf3:/custRootCA.crl" {
     primary-url "http://88.88.4.1/certs/custRootCA.crl"
     verification {
        hash-algorithm sha256
        hash-value "e85985f695eea8408b6f27cca78cddfadf57fbd15fb7313a6f1d28c7f346d4ea"
     }
  }
  # CRL for intermediary CA
  file "cf3:/custIntermediaryCA.crl" {
     primary-url "http://88.88.4.1/certs/custIntermediaryCA.crl"
     verification {
        hash-algorithm sha256
        hash-value "17649d2c2d683d1e92da1ada6881d91b649d158fd028e45f78bda3b44e0c7695"
     }
  }
  #
  # (optional) Download server (trust anchor) CA certs and CRLs
  #----------------------------------------------------------
  # server Root CA
  file "cf3:/serverRootCA.pem" {
     primary-url "http://88.88.4.1/certs/serverRootCA.pem"
     verification {
        hash-algorithm sha256
        hash-value "f6f5319b8dc83f9eb1da292ffcbefbbff068ae9a67ffc8a3f366d211774b4de5"
     }
  }
  # server intermediary CA
  file "cf3:/serverIntermediaryCA.pem" {
     primary-url "http://88.88.4.1/certs/serverIntermediaryCA.pem"
     verification {
        hash-algorithm sha256
        hash-value "e0787cbe981fe8a69c9dae3928a6e79f4362e912960a8ff85fdcc817b271b8b3"
     }
  }
  # server Root CA CRL
  file "cf3:/serverRootCA.crl" {
     primary-url "http://88.88.4.1/certs/serverRootCA.crl"
     verification {
        hash-algorithm sha256
        hash-value "e85985f695eea8408b6f27cca78cddfadf57fbd15fb7313a6f1d28c7f346d4ea"
     }
  }
  # server intermediary CA CRL
  file "cf3:/serverIntermediaryCA.crl" {
     primary-url "http://88.88.4.1/certs/serverIntermediaryCA.crl"
     verification {
        hash-algorithm sha256
        hash-value "17649d2c2d683d1e92da1ada6881d91b649d158fd028e45f78bda3b44e0c7695"
     }
  }
}
# Move on to STAGE 3 - EST enroll over LTE
next-provisioning-file cf3:\STAGE3.ztp
}

write "cf3:/STAGE3.ZTP" {
###############################
# STAGE 3 (EST Enrollment)
###############################
execute {
  exit all
  config
    router Base
        static-route-entry ::/0 next-hop pdn1-sim1 no shutdown
    exit
    system
        file-transmission-profile "chassis_ftp" create
            no ipv4-source-address
            no ipv6-source-address
            redirection 8
            retry 100
            timeout 120
        exit
        security
            pki
                est-profile "cust_chassis_enroll" create
                    client-tls-profile "customer_tls"
                    server 2002:468:2000:2:80:10:1:142 port 8085
                    http-auth username estuser password estpwd
                    transmission-profile "chassis_ftp"
                exit
            exit
        exit
    exit
  exit

  admin certificate gen-keypair cf3:/custchassis.key curve secp384r1
  admin certificate import type key input cf3:/custchassis.key output custchassis.key format der
  admin certificate import type cert format pem input cf3:/custRootCA.pem output custRootCA.cert
  admin certificate import type crl input cf3:/custRootCA.crl output custRootCA.crl format pem
  admin certificate import type cert format pem input cf3:/custIntermediaryCA.pem output custIntermediaryCA.cert
  admin certificate import type crl input cf3:/custIntermediaryCA.crl output custIntermediaryCA.crl format pem
  admin certificate import type cert format pem input cf3:/serverRootCA.pem output serverRootCA.cert
  admin certificate import type crl input cf3:/serverRootCA.crl output serverRootCA.crl format pem
  admin certificate import type cert format pem input cf3:/serverIntermediaryCA.pem output serverIntermediaryCA.cert
  admin certificate import type crl input cf3:/serverIntermediaryCA.crl output serverIntermediaryCA.crl format pem
  config
    system
        security
            pki
                ca-profile "serverRootCA" create
                    cert-file "serverRootCA.cert"
                    crl-file "serverRootCA.crl"
                    no shutdown
                    exit
                ca-profile "serverIntermediaryCA" create
                    cert-file "serverIntermediaryCA.cert"
                    crl-file "serverIntermediaryCA.crl"
                    no shutdown
                    exit
                exit
            tls
                trust-anchor-profile "chassis_est_ta" create
                    trust-anchor "serverRootCA"
                    trust-anchor "serverIntermediaryCA"
                exit
                client-cipher-list "customer_ciphers" create
                    cipher 1 name tls-rsa-with-aes256-cbc-sha256
                    cipher 2 name tls-rsa-with-aes256-gcm-sha384
                    cipher 3 name tls-ecdhe-rsa-aes128-gcm-sha256
                    cipher 4 name tls-ecdhe-rsa-aes256-gcm-sha384
                    cipher 5 name tls-ecdhe-ecdsa-aes128-gcm-sha256
                    cipher 6 name tls-ecdhe-ecdsa-aes256-gcm-sha384
                exit
                client-tls-profile "customer_tls" create
                    trust-anchor-profile "chassis_est_ta"
                    cipher-list "customer_ciphers"
                    no shutdown
                exit
            exit
        exit
    exit
  exit
  admin certificate est enroll est-profile cust_chassis_enroll key cf3:/system-pki/custchassis.key output custchassis.cert hash-alg sha512 subject-dn C=EU,O=Customer,CN=NS1234567890 validate-cert-chain force
  config
    system
        security
            pki
                ca-profile "custRootCA" create
                    cert-file "custRootCA.cert"
                    crl-file "custRootCA.crl"
                    no shutdown
                    exit
                ca-profile "custIntermediaryCA" create
                    cert-file "custIntermediaryCA.cert"
                    crl-file "custIntermediaryCA.crl"
                    no shutdown
                    exit
                exit
            tls
                cert-profile "customer_est_cert" create
                    entry 1 create
                        cert "custchassis.cert"
                        key "custchassis.key"
                        send-chain ca-profile "custRootCA"
                        send-chain ca-profile "custIntermediaryCA"
                    exit
                    no shutdown
                exit
             exit
         exit
     exit
  exit
  #
  # chassis_tls from conveyed STAGE0 remains for bootstrap STAGE1 SW download.
  #
  file delete cf3:/custchassis.key force
  file delete cf3:/custRootCA.pem force
  file delete cf3:/custRootCA.crl force
  file delete cf3:/custIntermediaryCA.pem force
  file delete cf3:/custIntermediaryCA.crl force
  file delete cf3:/serverRootCA.pem force
  file delete cf3:/serverRootCA.crl force
  file delete cf3:/serverIntermediaryCA.pem force
  file delete cf3:/serverIntermediaryCA.crl force
}
#Move on to STAGE 4 - Configuration Download.
next-provisioning-file cf3:STAGE4.ztp
}
###############################
# STAGE 4 (Finalize System)
###############################
# STAGE4 HTTPS uses customer_tls (trust-anchor); will not attach 
# customer_est_cert here.
#
write "cf3:/STAGE4.ZTP" {
# Download Final Configuration.
download {
  config "cf3:/custConfig.cfg" {
     primary-url "https://[2002:468:2000:2:80:10:1:142]/config/custConfig.cfg"
     primary-trust-anchor "customer_tls"
     verification {
        hash-algorithm sha256
        hash-value "8949bd0c96f12c72898ba5ed26453feeace9efd5126ceb4f3b57753dbf7fa219"
     }
  }
}
bof {
   primary-image    cf3:/images2
   primary-config   cf3:/custConfig.cfg
   wait             3
   persist          off
}
}

import {
    trust-anchor TRUST_ANCHOR_12 {
        cert "cf3:/ca12.crt" {
            format pem
            tls-version "1.2"
            primary-url ftp://user-name:password@10.10.10.66//fileserver-1/ca12.crt
        }
        crl "cf3:/ca12.crl" {
            format der
            primary-url ftp://user-name:password@10.10.10.66//fileserver-1/ca12.crl
        }
    }
    trust-anchor TRUST_ANCHOR_13 {
        cert "cf3:/ca13.crt" {
            format pem
            tls-version "1.3"
            primary-url ftp://user-name:password@10.10.10.66//fileserver-1/ca13.crt
        }
        crl "cf3:/ca13.crl" {
            format der
            primary-url ftp://user-name:password@10.10.10.66//fileserver-1/ca13.crl
        }
    }
    trust-anchor TRUST_ANCHOR_ALL {
        cert "cf3:/ca-all.crt" {
            format pem
            tls-version "all"
            primary-url ftp://user-name:password@10.10.10.66//fileserver-1/ca-all.crt
        }
        crl "cf3:/ca-all.crl" {
            format der
            primary-url ftp://user-name:password@10.10.10.66//fileserver-1/ca-all.crl
        }
    }
}
download {
    config "cf3:/ztp/ztp_dut-a.cfg.12" {
        primary-url https://10.10.10.64:81/ztp_dut-a.cfg
        primary-trust-anchor "TRUST_ANCHOR_12"
    }
    config "cf3:/ztp/ztp_dut-a.cfg.13" {
        primary-url https://10.10.10.64:81/ztp_dut-a.cfg
        primary-trust-anchor "TRUST_ANCHOR_13"
    }
    config "cf3:/ztp/ztp_dut-a.cfg.all" {
        primary-url https://10.10.10.64:81/ztp_dut-a.cfg
        primary-trust-anchor "TRUST_ANCHOR_ALL"
    }
}

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
  }

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.

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 "1/2/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
}