Zero Touch Provisioning (ZTP) saves time and resources in mass deployments since administrators do not need to physically connect to each power strip before the unit is deployed to the network. ZTP allows administrators to use an existing DHCP service, along with a TFTP server, to automate the configuration of IT devices.

ZTP is available in several models of console servers and also with several models of power strips including Server Technology PRO1 and PRO2. In the context of the deployment of the Servertech PRO1/PRO2 power strips, it is used to configure the network settings and the login credentials.

ZTP Availability on Server Technology PRO1 and PRO2

Starting on firmware version 8.0h, Server Technology has introduced the ZTP feature, with the purpose of facilitating the mass deployment of PDUs. Mirapath tested this new feature in its engineering lab. This article describes the test environment and the test results.

Available on Server Technology PRO1 and PRO2 series, Zero Touch Provisioning (ZTP) is a feature that allows system administrators to use the automated configuration methodology to bring up the Server Technology PDUs with little to no intervention. Among its benefits, ZTP allows a PDU to be provisioned and configured automatically, eliminating most of the manual work involved with adding the units to the network.

To successfully implement ZTP, you will need the following:

  • Server Technology PRO1/PRO2 running firmware version 8.0h or later
  • DHCP server, preferably a Linux native DHCPD
  • TFTP (Trivial File Transfer Protocol) server to store the configuration template
  • Both DHCP and TFTP servers must be on the same subnet as the PDUs

ZTP Flow

The communication process between the PDU and the DHCP server goes as follows:

  1. When a PDU is powered up and physically connected to the network, the PDU will look for a DHCP server to obtain an IP address
  2. Upon recognizing the MAC address or the Vendor Class Id option, the DHCP server will respond with an OFFER that includes the URL pointing to the TFTP server where the STI configuration template is located
  3. The PDU will download the configuration file from the address provided by the DHCP server, apply the configuration file, and reboot
  4. Upon boot up, the PDU will come up with the newly provisioned configuration with zero intervention

Test Environment

Mirapath’s environment for this test was relatively simple, however, configuring the DHCP server to perform its job requires some DHCP knowledge. Our environment consisted of a server running CentOS6 with DHCPD (DCHP server) and TFTPD (TFTP server). The PRO2 unit is connected to the same network subnet.

Initial Config File

The easiest way to get started with ZTP is to use one of the PDUs to create an initial configuration file that includes most of the defaults that will be used across all PDU’s. For this test, we configured the following variables:

  • Administrator password
  • SNMP community strings and trap destinations
  • SMTP for email notifications
  • LDAP setting for authentication

After the PDU has been configured to your standard, you need to export the configuration file. On the PRO2 unit we tested, this can be done under System -> Files -> Config.ini.

Test Procedures

Mirapath ran through 2 different scenarios, where each scenario is run at least twice to confirm the consistency of the results.  The first scenario used a generic configuration file that can be used by multiple PDUs. The second scenario created a more detailed configuration file that only applies to a single PDU unit.

Scenario 1

On Scenario 1, we created a single, generic configuration file that can be used by all units provisioned via ZTP. This file was saved on the TFTP server, with the name sti_config.ini. On Scenario 1, our DHCP configuration file looked like this:

The details of this configuration file are beyond the scope of this note however you can clearly see the URL for the generic configuration file at the TFTP server.

Obviously, this file omits anything that is specific to each PDU such as IP address and outlet names. We did not configure the outlet names, and we did not configure static IP address.

Scenario 2

On Scenario 2, we created a configuration file specific to each unit being provisioned via ZTP. This requires more upfront configuration work since we need to create one configuration file for each unit being provisioned via ZTP, however, it does offer us greater flexibility since it is possible to configure the IP address and the outlet names as well. And, since the most of the configuration files will be 95% identical, a simple script would be able to automate the creation of this config files with ease. When saving the configuration file to the TFTP server, we also included the MAC address of the unit on the file name.

On the DHCP configuration file, we need to tell the system to point to the correct URL for each PDU. As you can see below, our config file includes the MAC address in its name. The DHCP server will include the MAC address of the unit requesting the IP address before submitting the URL back to the unit.

Even though this Scenario 2 involves a greater deal of preparation work, Mirapath recommends it since this is how you can take full advantage of ZTP and fully automate the configuration of the Server Technology units.

Results

Both test scenarios worked as expected. On Scenario 1, the PRO2 unit received its configuration, and after rebooting, all the configuration settings (SNMP, SMTP, LDAP, etc.) were properly configured on the unit. The unit also used DHCP to obtain its network settings. On Scenario 2, the unit obtained all the generic configuration settings  (SNMP, SMTP, LDAP, etc.) plus the static network settings included in the configuration file.


Click to learn more about the Server Technology PRO2 platform or email us at solutions@mirapath.com.

ZTP