sending options from wrong subnet in shared-network
John Wobus
jw354 at cornell.edu
Tue Dec 10 15:11:32 UTC 2013
So if I understand correctly, like a host declaration,
a class declaration inherits the directives (e.g. option declarations)
from the surrounding configuration, but is applied to
clients based upon its own matching rules, even if the
client is on a different subnet. Seems that analogous to hosts,
classes can be confusing when declared inside a subnet declaration.
My copy of the DHCP book says classes are more specific than ranges and
subnets but less specific than hosts.
I recall in the past there were folks on this list who insisted on
seeing
the entire configuration (without ellipses or hiding edits) when trying
to explain reported behavior.
John Wobus
Cornell IT
On Dec 10, 2013, at 8:45 AM, Glenn Satchell wrote:
> Ah, I think I see it now that we have the full config. If these
> clients
> boot using PXE (and the early packet trace looked like they might)
> then
> they will be members of the at least the first pxeclients class as
> they
> match the match statement. Because the class is defined inside the
> subnet,
> it inherits values from that subnet. This is the same logic that
> arises
> from moving the host definitions into the subnet scope.
>
> Apart from the next-server setting, these two classes look the same.
> So
> define the class once, outside the shared-network, and in each
> subnet or
> host or group add a next-server statement pointing to the specific
> tftp
> server. That option shouldn't make any difference in non-PXE boots.
>
> class "pxeclients" {
> ...
> }
> shared-network ... {
> subnet ... {
> next-server ...;
> }
> subnet ... {
> next-server ...;
> }
> }
> # or like this
> group {
> next server ...;
> host1 { ... }
> host2 { ... }
> }
> host3 { ... }
>
> regards,
> -glenn
>
> On Wed, December 11, 2013 12:02 am, Brian J. Murrell wrote:
>>
>> On Mon, 2013-12-09 at 17:18 -0500, John Wobus wrote:
>>>
>>> It sounds wrong to me. Where did you move the host declaration
>>> from?
>>
>> Basically changing from a:
>>
>> shared-network ... {
>> subnet ... {
>> }
>> subnet ... {
>> }
>> }
>> host1 { ... }
>> host2 { ... }
>> host3 { ... }
>>
>> type structure to a:
>>
>> shared-network ... {
>> subnet ... {
>> }
>> subnet ... {
>> host1 { ... }
>> host2 { ... }
>> host3 { ... }
>> }
>> }
>>
>> type structure, which as I understand is not necessary nor
>> encouraged.
>>
>>> Was it within some other scope that had these 'wrong option values'
>>> defined?
>>
>> It shouldn't have been. When it was structured like the first
>> example
>> above, my clients would get an ip address from the second defined
>> subnet
>> (the only one with a range, btw -- the first subnet had no range
>> defined
>> because all hosts in it had fixed-address specifications) and their
>> options (netmask, router, etc.) from the first subnet definition.
>>
>>> The matching host declaration is the "most specific" declaration
>>> for a
>>> matching host and overrides other declarations such as subnet.
>>
>> Right. But when that host gets it's lease it should get options from
>> either the host declaration or the subnet from which it's IP
>> address was
>> assigned, not other subnets in the same shared-network declaration.
>>
>>> This
>>> includes option declarations/values inherited from the scope that
>>> surrounds the host declaration.
>>
>> And the subnet declaration from where it's IP address was assigned,
>> yes?
>>
>>> If an option is defined globally, then a host declaration in global
>>> space
>>> will pick it up, i.e., it's as if you put that option definition in
>>> that host declaration. If the host declaration resides within a
>>> group
>>> declaration, then the host declaration will pick up an option
>>> defined
>>> in that group, or if the group does not override a global
>>> declaration
>>> for the option, from the globally-defined option.
>>
>> This is a good explanation but you fail to mention the options
>> defined
>> in the subnet declaration from where the host's IP address was
>> assigned.
>>
>>> Thus, what you got could result from parts of the configuration you
>>> haven't shown us.
>>
>> There is no other parts. Here's my total configuration, obviously
>> not
>> including every single host declaration, but they are all the same:
>>
>> authoritative;
>> ddns-update-style interim;
>> ddns-domainname "foo.example.com";
>> ddns-updates on;
>> update-optimization false;
>> deny duplicates;
>>
>> allow booting;
>> allow bootp;
>>
>> ignore client-updates;
>> set vendorclass = option vendor-class-identifier;
>>
>> option pxe-system-type code 93 = unsigned integer 16;
>>
>> shared-network foo {
>> subnet 192.168.0.0 netmask 255.255.255.0 {
>> option routers 192.168.0.1;
>> server-identifier 192.168.0.1;
>> option domain-name "foo.example.com";
>> option domain-name-servers 192.168.0.4;
>> option subnet-mask 255.255.255.0;
>> default-lease-time 21600;
>> max-lease-time 43200;
>> class "pxeclients" {
>> match if substring (option vendor-class-identifier, 0,
>> 9) =
>> "PXEClient";
>> max-lease-time 10;
>> if option pxe-system-type = 00:02 {
>> filename "ia64/elilo.efi";
>> } else if option pxe-system-type = 00:06 {
>> filename "grub/grub-x86.efi";
>> } else if option pxe-system-type = 00:07 {
>> filename "grub/grub-x86_64.efi";
>> } else {
>> filename "pxelinux.0";
>> }
>> }
>> }
>> subnet 172.1.10.0 netmask 255.255.248.0 {
>> option routers 172.1.10.1;
>> server-identifier 172.1.10.1;
>> option domain-name "foo.example.com";
>> option domain-name-servers 172.1.10.8, 172.1.10.9,
>> 172.1.10.6;
>> option subnet-mask 255.255.248.0;
>> range dynamic-bootp 172.1.10.100 172.1.13.254;
>> default-lease-time 21600;
>> max-lease-time 43200;
>> class "pxeclients" {
>> match if substring (option vendor-class-identifier, 0,
>> 9) =
>> "PXEClient";
>> max-lease-time 10;
>> next-server 172.1.10.6;
>> if option pxe-system-type = 00:02 {
>> filename "ia64/elilo.efi";
>> } else if option pxe-system-type = 00:06 {
>> filename "grub/grub-x86.efi";
>> } else if option pxe-system-type = 00:07 {
>> filename "grub/grub-x86_64.efi";
>> } else {
>> filename "pxelinux.0";
>> }
>> }
>> }
>> }
>>
>> zone foo.example.com {
>> primary 127.0.0.1;
>> }
>>
>> zone 10.1.172.in-addr.arpa {
>> primary 127.0.0.1;
>> }
>>
>> zone 11.1.172.in-addr.arpa {
>> primary 127.0.0.1;
>> }
>>
>> zone 12.1.172.in-addr.arpa {
>> primary 127.0.0.1;
>> }
>>
>> zone 13.1.172.in-addr.arpa {
>> primary 127.0.0.1;
>> }
>>
>> zone 0.168.192.in-addr.arpa {
>> primary 127.0.0.1;
>> }
>>
>>
>> # Record static assignments for infrastructure here. Even if the
>> machines
>> # are not using DHCP, we should centralize the mac/ip mappings.
>> host host-1.foo.example.com {
>> hardware ethernet 00:1e:67:6d:37:17;
>> fixed-address 172.1.10.4;
>> }
>> ...
>>
>> group {
>> host host-4vm2 {
>> hardware ethernet 52:54:00:04:D9:02;
>> option host-name="host-4vm2";
>> ddns-hostname "host-4vm2";
>> }
>> host host-4vm3 {
>> hardware ethernet 52:54:00:04:D9:03;
>> option host-name="host-4vm3";
>> ddns-hostname "host-4vm3";
>> }
>> ...
>> }
>>
>> In any case, having since looked at this problem a little more
>> closely,
>> I have noticed that because my dhcpd is on a RHEL6[.4] system,
>> compared
>> to the current release stream, it's quite old and fairly heavily
>> patched. So it's entirely possible that this is an already fixed
>> (i.e.
>> upstream) bug or one of the patches has introduced it, so I really
>> should take my concern back to RH and not really bother you folks
>> here
>> with such old software.
>>
>> Cheers,
>> b.
>>
>>
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
More information about the dhcp-users
mailing list