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. -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
