sending options from wrong subnet in shared-network
Glenn Satchell
glenn.satchell at uniq.com.au
Tue Dec 10 13:45:14 UTC 2013
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
More information about the dhcp-users
mailing list