Cisco Catalyst 9500X Zero-Touch Provisioning (ZTP) Configuration Guide PDF (EN)

Zero-Touch Provisioning Overview

Zero-Touch Provisioning To address network provisioning challenges, Cisco introduces a zero-touch provisioning model. This module describes the Zero-Touch Provisioning feature. The Zero-Touch Provisioning feature is enabled automatically; no configuration is required. Note Restrictions for Zero-Touch Provisioning, on page 1 Information About Zero-Touch Provisioning, on page 1 Sample Zero-Touch Provisioning Configurations, on page 10 Additional References for Zero-Touch Provisioning, on page 38 Feature Information for Zero-Touch Provisioning, on page 39 Restrictions for Zero-Touch Provisioning • Zero-touch provisioning is not supported on Cisco Catalyst 9200L SKUs.

Information About Zero-Touch Provisioning This section provides information about the DHCP server configuration, DHCPv6 support, Secure ZTP, bootstrapping information, and so on. Zero-Touch Provisioning Overview Zero-touch provisioning (ZTP) provides open bootstrap interfaces to automate network device provisioning in heterogeneous network environments. When a device that supports ZTP starts up, and does not find the startup configuration (during initial installation), the device enters the zero-touch provisioning mode. The device searches for a DHCP server, bootstraps itself with its interface IP address, gateway, and Domain Name System (DNS) server IP address, and enables Guest Shell.

The device then obtains the IP address or URL of an HTTP or a TFTP server, and downloads the Python script from an HTTP or a TFTP server to configure the device. Zero-Touch Provisioning 1

Стр. 1

DHCP Server Configuration for Zero-Touch Provisioning

ZTP is supported through data ports on all supported platforms; however, on Cisco Catalyst 9500X Series Switches it is not supported through data ports. Guest Shell provides the environment for the Python script to run. Guest Shell runs the downloaded Python script and applies an initial configuration to the device. After initial provisioning is complete, Guest Shell remains enabled. For more information, see the Guest Shell chapter. If ZTP fails, the device falls back on AutoInstall to load the configuration file. For more information, see Using AutoInstall and Setup .

Note DHCP Server Configuration for Zero-Touch Provisioning In ZTP, a DHCP server must be running on the same network as the new device that is being provisioned. ZTP is supported on both management ports and in-band ports. When the new device is switched on, it retrieves the IP address information of the HTTP or TFTP server where the Python script resides, and the folder path of the Python script from the DHCP server. For more information on Python Scripts, see the Python API chapter. The DHCP server responds to DHCP discovery events with the following options: • Option 150:

(Optional) Contains a list of IP addresses that point to the HTTP or TFTP server in the management network that hosts the Python scripts to be run. • Option 67: Contains the Python script file path in the HTTP/TFTP server. After receiving these DHCP options, the device connects to the HTTP or TFTP server, and downloads the Python script. At this point, because the device does not have a route to reach the HTTP or TFTP server, it uses the default route provided by the DHCP server.

DHCP Client Behavior From Cisco IOS XE Amsterdam 17.2.1 release onwards, the device product identification (PID), Cisco Network Plug and Play (PnP), the serial number, and the MAC address is set in the DHCP client options. These client options can be used as variables at the DHCP server. The DHCP client options can be used to identify the device and send a unique Python file through option 67 or boot filename. Table 1: DHCP Client Options Zero-Touch Provisioning DHCP Server Configuration for Zero-Touch Provisioning Device Information DHCPv4 DHCPv6 Product ID 124 16/toggles Serial number 61/toggles 16/toggles MAC address 61/toggles 1 Cisco Network PnP 60 15 Zero-Touch Provisioning 2

Стр. 2

Secure ZTP

DHCPv6 Support In Cisco IOS XE Fuji 16.9.1, DHCP Version 6 support is added to the Zero-Touch Provisioning feature. DHCPv6 is enabled by default, and will work on any device that boots without a startup configuration. DHCPv6 is only supported on Catalyst 9300 and 9500 Series Switches. Note DHCPv6 is supported by both TFTP and HTTP download of Python scripts. If this download fails, the device reverts to the initial or factory settings (without any configuration). For both DHCPv4 and DHCPv6 to work, the correct HTTP or TFTP file path must be available in the DHCP configuration.

There can be scenarios where the same interface can have both IPv4 and IPv6 addresses, or two different interfaces in a network—one can receive IPv4 traffic and the other, IPv6 traffic. We recommend that you use either the DHCPv4 or DHCPv6 option in your deployment. The following is a sample DHCPv4: {/etc/dhcp/dhcpd.conf:} host { hardware ethernet xx:xx:xx:xx:xx:xx; option dhcp-client-identifier "xxxxxxxxxxxxxx"; option host-name " ".

option log-servers x.x.x.x; fixed-address x.x.x.x; if option vendor-class-identifier = "..." { option vendor-class-identifier "..."; if exists user-class and option user-class = "iPXE" { filename "http://x.x.x.x/…/ "; } else { filename "http://x.x.x.x/…/ "; } } } The following is a sample ISC DHCPv6 server configuration: option dhcp6.bootfile-url "http://[2001:DB8::21]/sample_day0_script.py"; Secure ZTP As per RFC 8572, Secure ZTP is a technique to securely provision a device, while it is booting in a factory default state. The provisioning updates the boot image, commits an initial configuration, and runs customer-specific scripts.

The existing ZTP can download a configuration script from an HTTP or a TFTP server, and run it on the device, but it does not securely provision a device. To securely provision a device, the following requirements must be met: • The management system must validate that it is provisioning a valid device. • The device must validate that it is being deployed in the correct network. • The device must validate that the provisioning data has not been tampered with. • Provisioning must use a secure transport protocol for data communication. Zero-Touch Provisioning DHCPv6 Support Zero-Touch Provisioning 3

Стр. 3

Secure ZTP Workflow

The Secure ZTP feature is enabled by default, and it cannot be disabled. The feature coexists with the classic ZTP. Based on the response that comes from the DHCP server, either ZTP or Secure ZTP is enabled. Option 67 triggers ZTP, and Option 143 or 136 triggers Secure ZTP. To use Secure ZTP, users must get an ownership voucher from a Cisco Manufacturer Authorized Signing Authority (MASA) server. Secure ZTP supports only Python scripts. Note Secure ZTP Workflow This section describes the Secure ZTP workflow: 1. When a device that supports the Secure ZTP boots up and does not find the startup configuration, it enters the ZTP mode, and triggers the Plug-n-Play (PnP) agent. 2.

The PnP agent locates a DHCP server, obtains an IP address from the server, and checks the response for Options 143 (DHCPv4) or 136 (DHCPv6). If either of these options is available, Secure ZTP is started. The DHCP server must already be configured. Note 3. The device starts a recursive algorithm of iterating over the bootstrapping servers, trying to get valid bootstrapping data. The algorithm is recursive because a bootstrapping server can return redirect data, in which case, new bootstrapping servers are added to the top of the list.

The algorithm stops when either the bootstrapping data is received and successfully applied, or when the list of servers is exhausted after not receiving any bootstrapping data. A bootstrapping server is a RESTCONF server, and the data transport protocol is HTTPS. Note 4. The server validates and provisions the device. The device presents its Cisco Secure Unique Device Identifier (SUDI) certificate to the bootstrapping server during TLS handshake. The device can accept the server certificate either by verifying it against a server-trust anchor that the device learned previously, or without verification. 5.

The device requests bootstrapping data from the server through a RESTCONF POST request by using the ietf-sztp-bootstrap-server:get-bootstrapping-data RPC. The bootstrapping server can provide either redirect or onboarding data in the response message. The onboarding information that is received from the bootstrapping server will be signed data. 6. The device checks the headers of the CMS structures that contain the bootstrapping artifacts to decide whether decrypting is required, and the format (JSON or XML) of the data used. If required, decryption is performed by using the device’s private SUDI key. Zero-Touch Provisioning Secure ZTP Workflow Zero-Touch Provisioning 4

Стр. 4