ZTP DHCP configuration Option 43

Infrastructure & Networking Switches and Gateways Ethernet Switches
1

Hi Community,

I currently implement ZTP for ONYX mellanox switches. It is well working for matching DHCP Option 60 and pushing configuration and firmware.

But, to distinguish between firmware Versions and providing the correct upgrade path, the switches need to tell the DHCP server its current version. From the documentation, this is done via DHCP Option 43:

https://docs.mellanox.com/display/MLNXOSv381000/Getting+Started#GettingStarted-ZTP

But there is no real-life example how to configure this on a (Linux-ISC-) DHCP server (-> match model and firmware version). What I read was that Option 43 is used to push vendor specific configuration TO the device but not to receive Information FROM it.

Any help is appreciated!

Thank you, :-)

Sebastian

2

Hi Minh,

thank you, I’ve attached the files as requested.

Best Regards,

Sebastian

3

The thing I don’t get is: The Mellanox documentation says that the DHCP server identifies the client based on option 60 and option 43. But based on the RFC for DHCP, only 60 is used for identity and 43 is used to push information back to the client:

“Configuring the DHCP option 60 helps in identifying the incoming DHCP client. If the vendor class identifier (VCI) advertised by the DHCP client matches with the DHCP server, the server makes a decision to exchange the vendor-specific information (VSI) configured as part of DHCP option 43.”

4

could you please provide an example on how to read from Option 43 information with an isc-dhcp-server? The documentation does not seem to be very clear. It only states that there are “corresponding subtypes defined” but not how to use or match them.

Thanks,

Sebastian

5

Hi Sebastian,

I found KB about it, please let me know it works for you:

ZTP:

Zero Touch Provisioning

Zero Touch Provisioning (ZTP) automates initial configuration of Mellanox switches at boot time. It helps minimize manual operation and reduce the customer’s initial deployment cost. ZTP allows you to automatically upgrade the switch with a specified OS image, set up an initial configuration database, and load and run a container image file.

The initial configuration is applied by using a regular text file containing valid cli configuration commands.

Running DHCP-ZTP:

There is no explicit command to enable ZTP. It is enabled by default. Disabling it is performed by a user-initiated configuration save

(using the command “configuration write”). The only way to re-enable ZTP would be to run a “reset factory” command, clearing the

configuration of the switch and rebooting the system.

ZTP is based on DHCP. For ZTP to work, the software enables DHCP by default on all its management interfaces. The switch OS

requests option 66 (tftp-server-name) and 67 (bootfile-name) from the DHCPv4 server or option 58 (bootfile-url) from the DHCPv6

server, and waits for the DHCP responses containing file URLs. The DHCP server must be configured to send back the URLs for the

software image, configuration file, and docker container image via these two options. Option 66 would contain the URL prefix to the

location of the files, option 67 would contain the name of files, and option 58 would contain the complete URLs of files. The format

of these two options is a string list separated by commas. The list items are placed in a fixed order:

, ,

The item value can be empty, but the comma shall not be omitted.

To have the DHCP server discern the proper files based on switch-specific information, the OS must provide some sort of identity

information for the server to classify the switches. Besides the aforementioned options, the OS attaches option 43 (vendor specific

information) and option 60 (vendor class identifier) in DHCPv4 requests, and option 17 (vendor-opts) in DHCPv6. Option 60 is set as

string “Mellanox” and options 17 and 43 contain the following Mellanox-specific sub-options:

• System Model

• Chassis Part Number

• Chassis Serial Number

• Management MAC

• System Profile

• Mellanox Onyx™ Release Version

The corresponding subtypes respectively are defined as:

DHCP_VENDOR_ENCAPSULATED_SUBOPTION_TLV_TYPE_MODEL 1

DHCP_VENDOR_ENCAPSULATED_SUBOPTION_TLV_TYPE_PARTNUM 2

DHCP_VENDOR_ENCAPSULATED_SUBOPTION_TLV_TYPE_SERIAL 3

DHCP_VENDOR_ENCAPSULATED_SUBOPTION_TLV_TYPE_MAC 4

DHCP_VENDOR_ENCAPSULATED_SUBOPTION_TLV_TYPE_PROFILE 5

DHCP_VENDOR_ENCAPSULATED_SUBOPTION_TLV_TYPE_RELEASE 6

Upon receiving such DHCP requests from a client, the server should be able to map the switch-specific information to the target file

URLs according to predefined rules.

Once the OS receives the URLs from the DHCP server, it executes ZTP as follows:

  1. If the software image URL is not specified, this step is skipped. Otherwise:

a. Perform disk space cleanup if necessary and fetch the image if it does not exist locally

b. Resolve the image version:

i. If it is already installed on an active partition, proceed to step 2

ii. If it is installed on a standby partition, switch partition and reboot

iii. If it is not installed locally, install it and switch to the new image and then reboot

iv. If a reboot occurs, ZTP performs step 1 again and no image upgrade will occur

  1. If the configuration file URL is not specified, skip this step. Otherwise:

a. Fetch the configuration file

b. Apply the configuration file

  1. Skip these steps if a docker image file URL is not specified. Otherwise:

a. Fetch the docker image file

b. Load the docker image

c. Clean up the docker images with the same name and different tag.

d. Start the container based on the image

e. Remove the downloaded docker image file

If some sort of failure occurs, the switch waits a random number of seconds between 1 and 20 and reattempts the operation. The

switch attempts this up to 10 times.

ZTP progress is printed to terminals including console and active SSH sessions

DHCPv4 Configuration Example (Linux dhcpd)

The below dhcpd.conf configuration has 3 items in the tftp-server-name option (option 66) and 3 items in the bootfile-name option (option 67) and it’s only sent when the dhcp client has “Mellanox” in it’s Vendor-Class identified (Option 60)

class “Vendor-Class” {

match option vendor-class-identifier;

}

class “Model” {

match option onyx_vendor_specific.model;

}

subnet 192.168.100.0 netmask 255.255.255.0 {

range 192.168.100.100 192.168.100.200;

subclass “Vendor-Class” “Mellanox” {

option tftp-server-name “tftp://192.168.100.22/, tftp://192.168.100.22/, tftp://192.168.100.22/”;

option bootfile-name "image-X86_64-3.8.1208.img, basic_mgmt_config.txt, init_Docker.tgz,";

option host-name “3700” ;

}

}

See the switch console output when 3 items where provisioned below:

Software image, text configuration file and a docker image

[2019-08-07 12:56:38.345] Mellanox Onyx Switch Management

[2019-08-07 12:56:38.350] switch-0b42d4 login:

[2019-08-07 12:56:51.727] Initializing zero-touch

[2019-08-07 12:56:57.245]

[2019-08-07 12:56:57.245] Waiting for zero-touch start

[2019-08-07 12:57:27.375]

[2019-08-07 12:57:27.375] Fetching configuration basic_mgmt_config.txt

[2019-08-07 12:57:27.401]

[2019-08-07 12:57:27.401] Applying configuration basic_mgmt_config.txt

[2019-08-07 12:57:31.181]

[2019-08-07 12:57:31.181] Fetching docker image mft_4.12.3-14_Docker.tgz

[2019-08-07 12:58:24.219]

[2019-08-07 12:58:24.219] Loading docker image from mft_4.12.3-14_Docker.tgz

[2019-08-07 12:58:37.287]

[2019-08-07 12:58:37.287] Docker image mft:4.12.3-14 is loaded

[2019-08-07 12:58:37.291]

[2019-08-07 12:58:37.291] Starting docker container ‘ztp_containter’ from image mft:4.12.3-14

[2019-08-07 12:58:37.640]

[2019-08-07 12:58:37.640] Zero-touch is finished

3700 [standalone: master] # show zero-touch

Zero-Touch status:11.106]

[2019-08-07 13:01:11.108] Active: yes

[2019-08-07 13:01:11.112] Status: Zero-touch is finished

[2019-08-07 13:01:11.119] Suppress-write: yes

[2019-08-07 13:01:11.124] Configured by zero-touch: yes

[2019-08-07 13:01:11.128] Configuration changed after zero-touch: no

DHCP offer packet from the switch:

DHCP Offer from the DHCP server:

6

Hi,

I know this article, but there is not described how to read from Option 43 information with an isc-dhcp-server. The documentation (this KB article) does not seem to be very clear. It only states that there are “corresponding subtypes defined” but not how to use or match them.

7

Hi Sebastian,

I also needed to push specific images and configs via ztp and needed to differentiate the devices beyond the vendor-class-identifier. Below is a snippet from my isc-dhcp server config.
I’m specifying the ztp deployed image and config based on the switch model (in my case MQM8700). You should be able to do the same for the current switch firmware level with suboption 6 (release). I have an example of that below that is commented out.

# Create option space for switch info
option space NVSWZTP;
option NVSWZTP.model code 1 = text;
option NVSWZTP.partnum code 2 = text;
option NVSWZTP.serial code 3 = text;
option NVSWZTP.mac code 4 = text;
option NVSWZTP.profile code 5 = text;
option NVSWZTP.release code 6 = text;
option NVSWZTP-43 code 43 = encapsulate NVSWZTP;
class “NVZTP” {
#match if option NVSWZTP.release = “3.10.1000”;
match if option NVSWZTP.model = “MQM8700”;
option tftp-server-name = “http://1.1.1.1/install/mlnx-os/,http://1.1.1.1/install/mlnx-os/”;
option bootfile-name “image-X86_64-3.1.1.img, switch.conf,”;
}

1 Like
8

Thank you, this worked pretty good and was exactly what I was looking for!

9

Hello How to apply to host with serial to ip?