[prev in list] [next in list] [prev in thread] [next in thread]
List: dhcp-users
Subject: Re: sending options from wrong subnet in shared-network
From: Sten Carlsen <stenc () s-carlsen ! dk>
Date: 2013-12-10 21:58:20
Message-ID: 52A78E7C.4010507 () s-carlsen ! dk
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On 10/12/13 22.20, Brian J. Murrell wrote:
> On Wed, 2013-12-11 at 00:45 +1100, 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.
> Right. But I guess logically, should a host match a class declaration
> whose scope is inside a subnet declaration that it cannot get an IP
> address from? I would have thought that the inability to get an IP
> address from a subnet would scope that subnet and anything inside it
> right out play.
Remember host declarations and class declarations are always global
regardless of where they are written. Scope only has influence on
inheritance.
>
>> Apart from the next-server setting, these two classes look the same.
> Yes. This did occur to me at one time also. But I really didn't want
> to send the next-server (and filename) option(s) to non-PXE booting
> clients.
>
>> 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.
> I guess that depends on what the non-PXE boot is and is doing. There's
> no reason that a non-PXE boot might not use a next-server option if it
> were given.
>
> Ultimately what it seems like here is that one cannot have different
> classes matching depending on which subnet the node will get it's
> address from, even if one scopes the class into the subnets. I'm really
> not sure if that's intended behavior or not. It does seem like a
> violation of the scoping rules, but I'm far from an expert on those
> within the dhcpd configuration.
>
> Cheers,
> b.
>
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
[Attachment #5 (text/html)]
<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 10/12/13 22.20, Brian J. Murrell
wrote:<br>
</div>
<blockquote cite="mid:1386710442.11483.25.camel@pc.interlinx.bc.ca"
type="cite">
<pre wrap="">On Wed, 2013-12-11 at 00:45 +1100, Glenn Satchell wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Right. But I guess logically, should a host match a class declaration
whose scope is inside a subnet declaration that it cannot get an IP
address from? I would have thought that the inability to get an IP
address from a subnet would scope that subnet and anything inside it
right out play.</pre>
</blockquote>
Remember host declarations and class declarations are always global
regardless of where they are written. Scope only has influence on
inheritance.<br>
<blockquote cite="mid:1386710442.11483.25.camel@pc.interlinx.bc.ca"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Apart from the next-server setting, these two classes look the \
same. </pre>
</blockquote>
<pre wrap="">
Yes. This did occur to me at one time also. But I really didn't want
to send the next-server (and filename) option(s) to non-PXE booting
clients.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
I guess that depends on what the non-PXE boot is and is doing. There's
no reason that a non-PXE boot might not use a next-server option if it
were given.
Ultimately what it seems like here is that one cannot have different
classes matching depending on which subnet the node will get it's
address from, even if one scopes the class into the subnets. I'm really
not sure if that's intended behavior or not. It does seem like a
violation of the scoping rules, but I'm far from an expert on those
within the dhcpd configuration.
Cheers,
b.
</pre>
<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>
_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic