> > > Contrary to what everyone else says, with a bit of customization dhcpd
> > > can run zones just fine. Solaris 10 update 3 and later (I forget
> > > which Nevada build) have all the required bits in place.
> > >
> > >
> > http://mail.opensolaris.org/pipermail/install-discuss/2007-March/004266.html
> > Yep, it can be made to work, though I don't think it's officially
> > supported. When I last looked at this issue, the changes needed to the
> > source to make it work without any special tweaks was straightforward.
> If you offer up hints, I make take this on in the future. I've got a
> couple other things I want to work on before this one, though.
It's been a while, but the main things I recall are:
* The DHCP server used to open /dev/ip rather than using a UDP
socket to do some control operations, which forced it to require
more privileges than it really needed. This was fixed via
6357132 in Nevada build 36.
* The DHCP server is generally designed to work with physical IP
interfaces. Some work would be needed to allow it to work with
logicals (if that's even desirable); 5030697 touches on this.
* The DHCP server doesn't support different IP subnets on the
same IP interface, which constrains the way things could work
with zones. This is covered by 5010613.
* The DHCP server populates the ARP table so that it can unicast
DHCP responses to the client before the client has agreed to
use the IP address (this is basically due to the same DHCP RFC
braindamage I described in PSARC/2007/571). If it can't install
an ARP entry, it will broadcast the response instead, which will
work fine. So it may be sufficient to simply lower the log
level of those failures.
zones-discuss mailing list