Ethan Quach wrote: > > > Ethan Quach wrote: >> >> >> Dave Miner wrote: >>> dambi wrote: >>>> Hi Ethan, >>>> >>>> based on our recent discussion, I have been investigating >>>> if Sun DHCP server can limit scope of particular macro based >>>> on client's platform making sure that macro as a whole is only >>>> processed for the client with matching client class. >>>> >>>> Looking at the official documentation (please see the excerpt >>>> below), it doesn't seem to be available - it seems to me that >>>> the only way to take 'client class' into account during server >>>> side decision making process is to create macro with the same >>>> name, i.e. "SUNW.Sun-Blade-100" (the approach suggested in recent >>>> email thread discussing how to configure DHCP server for >>>> x86 & Sparc platform w/o need for creating client specific macros). >>>> >>>> But to be honest, I am not 100% sure if this implication is >>>> correct. >>>> >>>> Dave, since you are more familiar with this area, could I please >>>> ask you if you might help us to clarify if this observation >>>> might be correct or where could I take a look to further >>>> investigate ? >>>> >>> >>> You have it essentially right. The one aspect that's not covered >>> below is that vendor options are restricted to being used only with >>> a client that presents a matching client class, but I don't think >>> that is particularly useful here. 4187666 suggested extending that >>> to the standard options, but hasn't been implemented. There was >>> also discussion at one time about supporting wild-carding for client >>> classes, but that wasn't implemented. >>> >>> The main thing one can do is to use the Include pseudo-option with >>> the client class macros so that all SPARC systems, for example, get >>> the same data by placing it in something like a "sparc" macro and >>> then including that in the client class macros. >> >> So if we include this client class macro inside of what we >> create today for AI, which is a macro mapped to an IP address, >> I would hoping this would work because the macro mapped >> to an IP address is more specific than just the client class macro. > > Though this could be my misconception here -- I may be looking > at this backwards. If the macros we create for AI today are not > macros mapped to an IP address, then what I'm thinking doesn't > work.
We currently create service specific DHCP macros for each service created and those are mapped to each IP address in pool of IP addresses created for particular service. The problem is that we don't know in advance, which IP address will be assigned to the particular client as we use dynamic allocation (it simplifies DHCP configuration). So AI client could be assigned with IP address from any pool mapped to any service specific macro - I think it would not be guaranteed that Sparc is provided with Sparc NBP. Thank you, Jan > > > -ethan > >> >> >> -ethan >> >>> >>> Dave >>> >>>> Thank you very much, >>>> Jan >>>> >>>> ... >>>> >>>> Macro Processing by the DHCP Server >>>> ----------------------------------- >>>> >>>> When the DHCP server processes a macro, it places the network >>>> options and values defined in >>>> the macro in a DHCP message to a client. The server processes some >>>> macros automatically for >>>> clients of a particular type. >>>> For the server to process a macro automatically, the name of the >>>> macro must comply with one >>>> of the categories shown in the following table. >>>> >>>> Macro Category Description >>>> ------------------------------------------- >>>> Client class The macro name matches a class of client, indicated by >>>> the client machine type, >>>> operating system, or both. For example, if a server has a macro named >>>> SUNW.Sun-Blade-100, any client whose hardware implementation is >>>> SUNW,Sun-Blade-100 automatically receives the values in the >>>> SUNW.Sun-Blade-100 macro. >>>> Network address The macro name matches a DHCP-managed network IP >>>> address. For example, >>>> if a server has a macro named 10.53.224.0, any client connected to the >>>> 10.53.224.0 network automatically receives the values in the >>>> 10.53.224.0 >>>> macro. >>>> Client ID The macro name matches some unique identifier for the >>>> client, usually derived >>>> from an Ethernet or MAC address. For example, if a server has a >>>> macro named >>>> 08002011DF32, the client with the client ID 08002011DF32 (derived >>>> from the >>>> Ethernet address 8:0:20:11:DF:32) automatically receives the values >>>> in the >>>> macro named 08002011DF32. >>>> A macro with a name that does not use one of the categories listed >>>> in Table above can be >>>> processed only if one of the following is true: >>>> >>>> * The macro is mapped to an IP address. >>>> * The macro is included in another macro that is processed >>>> automatically. >>>> * The macro is included in another macro that is mapped to an IP >>>> address. >>>> >>>> ... >>>> >>>> Order of Macro Processing >>>> ------------------------- >>>> >>>> When a DHCP client requests DHCP services, the DHCP server >>>> determines which macros >>>> match the client. The server processes the macros, using the macro >>>> categories to determine the >>>> order of processing. The most general category is processed first, >>>> and the most specific category >>>> is processed last. The macros are processed in the following order: >>>> >>>> 1. Client class macros ? The most general category >>>> 2. Network address macros ? More specific than Client class >>>> 3. Macros mapped to IP addresses ? More specific than Network address >>>> 4. Client ID macros ? The most specific category, pertaining to one >>>> client >>>> >>>> A macro that is included in another macro is processed as part of >>>> the container macro. >>>> If the same option is included in more than one macro, the value >>>> for that option in the macro >>>> with the most specific category is used because it is processed last. >>>> ... >>>> >>> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
