Martin Man writes:
> [EMAIL PROTECTED] wrote:
> > A question for those who would like this - what other sorts of DHCP
> > information would one want to use in this case? The DNS domain name?
> > Time server information?
> Well, if I understand this correctly, zoneadmd does plumb and will
> eventually do dhcp config of the VNIC.
VNIC? I think we were discussing the use of DHCP with regular
shared-stack zones and ordinary logical interfaces.
> Zone itself has no way to control the VNIC so I don't know how
> additional information obtained via DHCP can be passed to the zone
> without going straight to its filesystem and playing there with
> /etc/resolv.conf and similar files. It would IMHO be nasty and
> non-portable (think of non-sparse zone running Nexenta or branded zone
> running some flavor of Linux, which is precisely what I'm doing now).
I think the proposal would be to make the DHCP-learned information
available within the non-global zone, not to go modify the zone's
files from the global zone.
One way to do this would be to make the /etc/dhcp/$IF.dhc file visible
in the zone, and write the raw DHCPACK there. There are probably
better ways of doing this, such as making dhcpagent's internal control
socket (used by dhcpinfo) available in the zone.
> To recap, address, netmask and gateway should be enough for now...
Address and netmask are no problem at all; that'll work today.
Gateway is more problematic. Dhcpagent intentionally does not install
any routes based on anything acquired for logical interfaces. As the
man page says:
As with physical IPv4 interfaces, the /etc/hostname.hme0:1
and /etc/dhcp.hme0:1 files must also be created in order for
hme0:1 to be automatically plumbed and configured at boot.
In addition, unlike physical IPv4 interfaces, dhcpagent does
not add or remove default routes associated with logical
There are several reasons for this. First, routes on Solaris do not
(and cannot) point at logical interfaces. Instead, they point at
physical interfaces -- the actual output path. Secondly, the
non-zones usage would likely result in a large number of duplicates.
This can probably be revisited (to allow for DHCP-acquired addresses
that happen to be on different subnets), but it's potentially tricky.
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
zones-discuss mailing list