Vendor-Identifying Vendor Options for DHCPv4

  • 1
  • Question
  • Updated 1 year ago

Why Cumulus NOS DHCP request header does not included option 60?

I know Cumulus uses option 239 for ZTP script, but why not also use well established DHCP options [150,66] + 67 in conjunction with unique class identifier option 60? 

thanks,

Photo of Windesson Almeida

Windesson Almeida

  • 342 Points 250 badge 2x thumb

Posted 1 year ago

  • 1
Photo of Curt Brune

Curt Brune, Employee

  • 240 Points 100 badge 2x thumb
This is a really good suggestion.  I especially like the idea of setting the vendor-class-identifier (option 60), which is currently unset.

As to why not the DHCP options [150,66] + 67 -- we wanted ZTP to be simple to use and deploy.  As such, a single DHCP string option that contains the URL of a ZTP is quite simple.  As a string the server name need not be expressed as a dotted quad IPv4 address.  Also all the information (server and path to script) is contained in a single option.

The other options require setting two options (or more), or setting dotted quads, etc.

The single option is simple and effective.

Now setting vendor-class-identifier is good idea.  What kind of information would you be looking for here?

The most robust method would be to send DHCP option 125 (Vendor Identified Vendor-
Specific Information) also known as VIVSO, scoped to the Cumulus Networks 32-bit IANA Enterprise Number, 40310.  One of the sub-options within that could be the ZTP script URL.

This is similar to what the ONIE project does for locating an installer image:
https://github.com/opencomputeproject/onie/wiki/Design-Spec-SW-Image-Discovery#vendor-identifying-ve...

While robust, we start to wander away from the goal of "simple to document and deploy"...  Adding option 60, with some platform information would be a compromise between robust and simple.
Photo of Windesson Almeida

Windesson Almeida

  • 342 Points 250 badge 2x thumb

As to "The single option is simple and effective" -- I would yes, if Cumulus was the only NOS in a given infrastructure and no, when if you have a multi-vendor environment, because any special tag provisioning (like option 239) could be in concert with a unique class id tag prefer 60, and at the moment, Cumulus have neither option 60 or 125 set.

While option 125 is most robust method, not all vendors uses it, so it is like you said, "simple to document and deploy"...  

A sub group of our DHCP department believes something along the lines of "The vendor neutral option is simple and effective, because does not require DHCP code changes every time we have a new vendor"...  

I am going to quote you here from ONIE documentation, "consider an enterprise scenario where the corporate IT department that controls the DHCP server is separate from the application development department trying to prototype new Web services. The application department wants to move quickly and prototype their new solution as soon as possible. In this case, waiting for the IT department to make DHCP server changes takes too much time." -- To be fair this was said in a different situation for ONIE partial Installer URLs, but you got the idea.

Now setting vendor-class-identifier is good idea.  What kind of information would you be looking for here? – Well...let’s see what other vendors are doing

For ONIE dell s4000_c2338-r0

  • Vendor-Class Option 60, length 38: "onie_vendor:x86_64-dell_s4000_c2338-r0"

FOR Cisco DCNM Nexus 9K

  • Vendor-Class Option 60, length 17: "Cisco N9K-C9396PX"

FOR PicOS

  • pica8-pxxxx where xxxx is the switch model.

For Cumulus:

  • Maybe cumulus-xxx where xxx is the Platform Name

I do like that Cumulus has its own option for a single full URL, but that should be a complement to the simple less robust but well-established DHCP options 66, 150 (tftp server name/IP) and 67 (tftp server file name) in conjunction with a unique class identifier option 60.

Sometimes, simple is better than robust.