DHCP option lengths

I answered a question today about DHCP option lengths on our internal DHCP support list, a question which has come up before and no doubt will again. I might as well post it here for posterity.

> > Working with a customer on their custom jumpstart environment and they 
> > ran into the 255 byte limit.  I did find the notes in the documentation 
> > confirming the length limit in our DHCP server.  The customer came back 
> > and said that they don't seem to be having the problem with their Linux 
> > (RedHat/SE Linux) DHCP servers when using longer macro parameters for 
> > their network installations.
> > 

First, it's important to get the terminology straight, because it's key 
to understand what is happening.

The DHCP specifications talk about "options".  The format of each option 
in a DHCP packet is specified in such a way that the individual option 
has a one-byte unsigned length, followed by the data.  That means that 
an individual option passed in a DHCP packet can have a length no 
greater than 255 bytes.

Solaris DHCP provides a concept of "macros", which are merely a 
configuration convenience which allows options to be grouped together. 
Macros don't have a length limit, so you can specify any number of 
options in a macro.

Generally, the problem customers encounter is that the vendor options we 
use in Solaris for automating Jumpstart installs all end up collapsed 
into one DHCP option, because that's the way the standard works, and we 
run into the 255 byte limit there.  It's highly unlikely that you'll run 
into it in any other case.  The usual workaround is to use shorter paths 
to the installation image, as those are the options which eat up most of 
the space in the packet; symlinks work well for this purpose.

> > Is there a DRAFT change to DHCP to allow longer macros?

There is an RFC, 3396, which specifies a way to pass more than 255 bytes 
for an option.  It works by passing multiple instances of the option in 
the packet, requiring the client to concatenate them together, which 
means the server has to carefully order them in order for the client to 
reconstruct them correctly.  We have not implemented this option in 
either the Solaris client or server, but CR 4867934 records the need to 
do so; adding another call record there wouldn't hurt - it's already one 
of the highest-priority RFE's we have against DHCP, but there are no 
resources currently assigned to work in that area.

> > Is the Linux-based DHCP server ignoring the standards?
> > 

No, I'm sure they're using the RFC 3396 conventions.  The maintainers of 
the most popular DHCP server on Linux are quite cognizant of remaining 
compliant with the protocol standards.

How does adding ISC's dhcpd to /usr/sfw rank in comparison to allowing greater than 255 characters? Frankly, I found it easier to get DHCP-based jumpstarts to work with ISC dhcpd than I did with Sun's dhcpd. This may be because of the quality of examples that exist for ISC dhcpd vs. Sun dhcpd.

Even after getting Sun's dhcpd to work, I continue to have problems with "boot net:dhcp" timing out several times before saying that it is restarting the dhcp process. On 15k's this cycle happens once on each network boot. On V240's (or is it V440's?) this cycle has to complete twice. No such problem with ISC dhcpd.

Posted by Mike Gerdts on April 20, 2006 at 02:58 PM EDT #

We don't have any plans to ship the ISC dhcpd as part of Solaris - making that transition would be somewhat difficult given the large differences in how the two are configured. The examples in the docs could undoubtedly be improved, we'd welcome specific suggestions. We also recommend trying JET, since it does make the setup easier for many cases, though I know some don't care for it.

I'd be interested to know more about the boot problems you're seeing, though; there was a bug, 6220012, in Solaris 10 which has been fixed in Nevada but the patch hasn't been back-ported yet which leads to behavior similar to what you describe. Drop me a note and we can see whether that's the case.

Posted by Dave Miner on April 21, 2006 at 03:59 AM EDT #

Post a Comment:
Comments are closed for this entry.

I'm the architect for Solaris deployment and system management, with a lot of background in networking on the side. I spend a lot of my time currently operating Solaris Engineering's OpenStack cloud. I am co-author of the OpenSolaris Bible (Wiley, 2009). I also play a lot of golf.


« July 2016

No bookmarks in folder


No bookmarks in folder