sending options from wrong subnet in shared-network
Sten Carlsen
stenc at s-carlsen.dk
Tue Dec 10 15:33:32 UTC 2013
In the full config there is a CLASS declaration in EACH subnet. This
adds to the confusion as the clients get matched against both class
declarations and inheritance is even less clear as the classes have the
SAME name.
@John
There are some places in the man pages that are not perfectly clear and
I believe not entirely correct, except in the latest version(s).
On 10/12/13 16.11, John Wobus wrote:
> 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
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20131210/9ecde821/attachment-0001.html>
More information about the dhcp-users
mailing list