sending options from wrong subnet in shared-network
Brian J. Murrell
brian at interlinx.bc.ca
Tue Dec 10 13:02:04 UTC 2013
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20131210/75d54eea/attachment.bin>
More information about the dhcp-users
mailing list