<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFCC" text="#000000">
<br>
<div class="moz-cite-prefix">On 19/09/13 16:32, Christian Marg
wrote:<br>
</div>
<blockquote cite="mid:523B0AE9.8090108@rz.tu-clausthal.de"
type="cite">Hello,
<br>
<br>
On 19.09.2013 11:34, Sten Carlsen wrote:
<br>
<blockquote type="cite">You have put the host declaration inside
the subnet declaration.
<br>
When you do that, it has the side effect that it will get its
router and
<br>
some other settings from that subnet.
<br>
</blockquote>
<br>
We actually rely on that - we have about 70 different subnets with
about 4500 host declarations. I don't like the idea to define
"option routers" etc. per host...
<br>
<br>
man dhcpd.conf says:
<br>
====8<====8<====8<====8<====
<br>
When a client is to be booted, its boot parameters are determined
by
<br>
consulting that client's host declaration (if any), and then
consulting
<br>
any class declarations matching the client, followed by the pool,
sub-
<br>
net and shared-network declarations for the IP address assigned to
the
<br>
client.
<br>
====8<====8<====8<====8<====
<br>
<br>
So the problem is not the placement of the host declarations but
the fact that the class declaration ties the host to a pool, which
in turn is called more "specific" than a subnet declaration...
<br>
</blockquote>
The MAN page is unfortunately not always as clear and precise as one
might wish it to be.<br>
<blockquote cite="mid:523B0AE9.8090108@rz.tu-clausthal.de"
type="cite">
<br>
Maybe a workaround would be using "group" statements to group the
hosts that belong to a subnet, and define routers etc. in that
group.
<br>
<br>
It seems that group-specific statements would count as
"host-specific" in the above line from the manpage...
<br>
<br>
<blockquote type="cite">The general advice is to have all
<br>
host declarations outside all subnet declarations as they are
global in
<br>
scope no matter where they are placed, inheritance is from where
they
<br>
are placed.
<br>
</blockquote>
<br>
So a host declared globally will inherit the subnet parameters
because it's IP adress belongs to the subnet? I think we went for
host declarations inside of subnet declarations because it's a
little more intuitive.
<br>
</blockquote>
Well, yes. Host declarations ARE global no matter where you place
them in the text, EXCEPT that they will inherit routers etc. from
the place you declare them. In other cases we have seen that hosts
inherit parameters from the subnet where the host declaration was
actually placed, not from where it got the address from, even if one
might expect differently.<br>
<br>
I still suggest to declare the hosts outside any subnet or other
block, they will take routers from where they belong. This is the
reason for the warning you should see in the output from dhcpd.<br>
<blockquote cite="mid:523B0AE9.8090108@rz.tu-clausthal.de"
type="cite">
<br>
<blockquote type="cite">It could also look like the class and
subclass declarations inherit form
<br>
the subnets they are placed in. I suggest to move them to
outside all
<br>
subnets, they are global anyway.
<br>
</blockquote>
<br>
I already moved the class and subclass declaration out of the
subnet - no change in behaviour. Of course the pool was still in
the subnet, but where else would it be.
<br>
</blockquote>
The pool must be in the subnet, correct.<br>
<br>
You may want to try to deny members of the class from the subnet
192.168.65.0? If you do not deny them, they are allowed though the
only address seems to be the fixed address in the host declaration.<br>
<br>
From the looks of it, I believe there is a match on both the host
and the class declarations, in the subnet where the host belongs,
there are no ranges, so no available address, except that it also
has a fixed address statement.<br>
<br>
My guess is that it first matches the host declaration, then later
in the file it matches the class statement, overriding the host
statement and finally gets the fixed address because there is no
range in that subnet, bringing the router etc from the subnet where
the class is declared.<br>
<br>
I will agree this is not very intuitive but we have seen a few
"interesting cases" based on things like this. I don't know the code
well enough to know whether this is exactly what happens.<br>
<br>
My advice is still to remove both host declarations and class
declarations out of any subnet declaration and use allow / deny to
control whether members of any specific class may have an address in
any pool / range / subnet.<br>
<br>
Removing them should remove wrong inheritance problems and allow /
deny should make sure they only get addresses where you want them to
have one.<br>
<blockquote cite="mid:523B0AE9.8090108@rz.tu-clausthal.de"
type="cite">
<br>
kind regards,
<br>
<br>
Christian Marg
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
dhcp-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
</pre>
</body>
</html>