On 10/ 4/10 04:06 PM, [email protected] wrote:
Hi Dave,
In elaboration, I think I might be missing a clever trick of DHCP
macro ordering possible to prevent an ISIM and Multihomed collision on how
to order macros.
On Mon, 4 Oct 2010, [email protected] wrote:
The intention is that the address records we generate in create-service
should not reference a specific AI service. The principle here is to
rely on DHCP as little as possible for delivering AI information,
because of the administrative boundaries that often exist at customer
sites. We rely on two things to get the client to the right AI service:
1. The DHCP server's ability to provide configuration automatically to
all clients of a particular class (PXE, or the various SPARC classes)
via a client class macro. We configure the client class macros to
include the macro for the default service, as shown in Examples 1& 2 in
the spec.
My understanding from what Clay has described to me is this may not work with
Solaris DHCP server in a multi-homed environment.
I'll let Clay elaborate.
I agree we should certainly get things segregated on architecture (client
class), however, an issue due to multihomed servers needing to specify a
per-subnet BootSrvA/BootFile (for X86 or SPARC respectively) and the order
of the Solaris DHCP server being:
1. Client Class Macro
2. Network Macro
3. IP Address Specific Macro
4. MAC Address Specific Macro
This means that we can not resolve on both client class (e.g. is this a
SPARC or X86 machine) and network (does this machine get a network
specific BootFile or BootSrvA option). We need to do a compound operation
on both client class and network it seems.
I'm not sure if there is something I am missing some clever way to
achieve this but I question if at this time it is not possible to solve
this problem with the Solaris DHCP server?
No, you really can't do both, so the result is that the network macro
would default to one architecture and others would be handled by setting
up individual clients.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
