Configuration question..

B. Cook bcook at poklib.org
Wed Sep 13 14:38:32 UTC 2006


Glenn Satchell wrote:
>> Date: Wed, 13 Sep 2006 08:50:33 -0400
>> From: "B. Cook" <bcook at poklib.org>
>> To: dhcp-users at isc.org
>> Subject: Re: Configuration question..
>>
>> Glenn Satchell wrote:
>>>> To: dhcp-users at isc.org
>>>> Subject: Re: Configuration question..
>>>> From: Keith.Neufeld at wichita.edu
>>>> Date: Tue, 12 Sep 2006 09:20:54 -0500
>>>>
>>>>> . . .
>>>>>
>>>>> The webmin gui doesn't show us the defined hosts we have, and we can't 
>>>>> figure out where/how to add them.. so I started to think that somehow 
>>>>> our config is incorrect..
>>>>>
>>>>> . . .
>>>>>
>>>>> We use hosts in pools, b/c I have one setup for unknown clients and one 
>>>>> for known clients.. and well, in the pools I can't see the defined hosts 
>>>>> that we have in the webmin gui.
>>>> The fact that the host declarations are inside the pool declaration is 
>>>> actually irrelevant to whether they can get a lease from that pool or 
>>>> not--the determination is made (in your configuration) by whether they're 
>>>> known (listed anywhere in the configuration) or unknown.
>>>>
>>>> To demonstrate that, take the host declaration for ronlapbop [sic] and 
>>>> move it to the 10.0.0.0 "Public Network" section of your configuration, 
>>>> then try to boot it on your 192.168.1.0 subnet.  It'll still get an 
>>>> address from one of your known-host ranges, _not_ from the 192.168.1.20-25 
>>>> range for unknown clients.
>>>>
>>>> There's been a thread on the mailing list recently about proper placement 
>>>> of host declarations; but the common wisdom is to put them _outside_ of 
>>>> all blocks, in the global scope, UNLESS you specifically want them to use 
>>>> some of the options from their "home" subnet even when they're roaming to 
>>>> other subnets.  [Did I say that about right?]  Putting host declarations 
>>>> inside subnet or pool declarations can lead people to think the hosts are 
>>>> tied to getting addresses only from the subnet or pool (which isn't 
>>>> actually the case), so it's nicer to put them globally and avoid the 
>>>> confusion.
>>>>
>>>>
>>>> It may be just the way my browser is displaying the file, but I prefer 
>>>> indenting blocks visually to match their syntactic nesting--so it'd be 
>>>> easier for me to read quickly if e.g. the stuff inside the 10.0.0.65-94 
>>>> pool were indented by another tabstop, and the hosts inside it (if they 
>>>> stay there) indented two tabstops from where they appear now.
>>>>
>>>> My $.02.
>>> One other idea is to use the group { } function when you have some
>>> common options for different groups of hosts. See below.
>>>
>>> I also agree with the wisdom of moving the host declarations to the
>>> global scope. They will still pick up appropriate subnet and pool
>>> settings based on whichever subnet or pool they get assigned an address
>>> from. I would venture to say this seems to be the collective "best
>>> practice" of the mailing list.
>>>
>>> I would then move the option settings from the pool to the subnet scope.
>>>
>>> The file would start to look a bit like this:
>>>
>>> #global options
>>>
>>> group {
>>>   option routers 0.0.0.0;
>>>   host ... { }
>>>   host ... { }
>>> }
>>> host ... { }
>>> host ... { }
>>>
>>> subnet 192.168.1.0 netmask 255.255.255.0 {
>>>     option domain-name "adriance.poklib.org"; 
>>>     option domain-name-servers 192.168.1.2;
>>>     option netbios-name-servers 192.168.1.248;
>>>     option netbios-node-type 8;
>>>     #option netbios-node-type 4;
>>>     option routers 192.168.1.3;
>>>     #option routers 192.168.1.2;
>>>
>>>     pool {
>>>         deny unknown clients;
>>>         range ...
>>>         ...
>>>     } # close pool
>>> } # close subnet
>>>
>>> subnet 10.0.0.0 netmask 255.255.255.128 {
>>>     option ...
>>>     range ...
>>>     allow unknown clients;
>>> }
>>>
>>> You have authoritative in the global scope, so no need to repeat it in
>>> subnet or pool scopes.
>>>
>>> My two cents worth, hope it helps.
>>>
>>> regards,
>>> -glenn
>>> --
>>> Glenn Satchell       mailto:glenn.satchell at uniq.com.au  |  Heard about
>>> Uniq Advances Pty Ltd           http://www.uniq.com.au  |  the new Unix
>>> PO Box 70 Paddington NSW Australia 2021                 |  sports car?
>>> tel:0409-458-580   tel:02-9380-6360   fax:02-9380-6416  |  The  rwx
>>>
>>>
>> Ok,
>>
>> I'm trying to understand this.. and  thinking I'm still missing 
>> something (as I'm still getting the warning..)
>>
>> So here is the rough skeleton of what I'm doing..
>>
>>
>> # dhcpd.conf
>>
>> authoritative;
>> other_global_options;
>>
>> subnet 192.168.1.0 netmask 255.255.255.0 {
>> global_settings_for_this_subnet;
>>
>> pool {
>> 	deny unknown clients;
>> 	range 192.168.1.100 192.168.1.105;
>> 	}
>>
>> group {
>> 	option routers 0.0.0.0;
>> 	host one	{ hardware ethernet aa:bb:cc:dd:ee:f1; fixed-address 
>> 192.168.1.99; }
>> 	}
>>
>> host two	{ hardware ethernet aa:bb:cc:dd:ee:f2; fixed-address 
>> 192.168.1.98; }
>> host three	{ hardware ethernet aa:bb:cc:dd:ee:f3; }
>>
>> pool {
>> 	allow unknown clients;
>> 	range 192.168.1.20 192.168.1.25;
>> 	option domain-name-servers 0.0.0.0;
>> 	}
>>
>> } # close subnet 192.168.1.0/24
>>
>>
>> # public network
>> subnet 10.0.0.0 netmask 255.255.255.128 {
>> other_options_here;
>> option router 10.0.0.87;
>>
>> pool {
>> 	allow unknown clients;
>> 	range 10.0.0.95 10.0.0.125;
>> 	}
>>
>> group {
>> 	option routers 10.0.0.62;
>> 	host something	{ hardware ethernet 11:22:33:44:55:61; fixed-address 
>> 10.0.0.5; }
>> 	}
>>
>> host another	{ hardware 11:22:33:44:55:62; }
>>
>> } # close subnet 10.0.0.0/25
>>
>>
>> This still gives me warnings:
>> WARNING: Host declarations are global.  They are not limited to the 
>> scope you declared them in
>>
>> do I need to define the hosts outside the subnets even?
> 
> Yes. Have a look at the section EXAMPLES in the dhcpd.conf man page,
> especially Figure 1. Note that the group { host { ... } ... } comes
> after the subnet definition is closed.
> 
> You want something like this:
> 
> global options
> 
> subnet {
>   subnet options
>   pool {
>     pool options
>   }
> }
> 
> group {
>   host { ... }
>   host { ... }
>   ...
> }
> host { ... }
> host { ... }
> 
>> but if I do that 
>> how will it know what hosts to apply what to?
> 
> Ok, from memory the 192.168.1.0 subnet was local and the 10.0.0.0 came
> via a relay.
> 
> The dhcp server sees the dhcp broadcast from the hosts on 192.168.1.0
> network. Also the giaddr (gateway interface address) will not be set.
> Thus the dhcp server knows they are in the local subnet and selects
> from the 192.168.1.0 definitions.
> 
> A host on the 10.0.0.0 subnet broadcasts, the dhcp relay picks up the
> broadcast and forwards it to the dhcp server as a unicastpacket. the
> dhcp relay also fills in a field in the dhcp options, the giaddr, with
> the address of the interface that the request came in on. Using the
> giaddr the dhcp server now knows which subnet the request originally
> came from. It selects an appropriate address from the 10.0.0.0 subnet
> and replies to the dhcp relay which thenm broadcasts it back onthye
> subnet for the client ot pickup.
> 
>>  how would it tell the 
>> different between hosts one, two and another? Or am I just missing 
>> something that should be glaringly obvious?
> 
> It works this way because consider if you had, say, a laptop that could
> be connected to either subnet and you wanted it to have a fixed address
> in each subnet. This would be a perfectly valid host declaration:
> 
> host bcook {
>   hardware ethernet aa:bb:cc:dd:ee:ff;
>   fixed address 192.168.1.5, 10.0.0.5;
> }
> 
> The dhcp server selects the appropriate address based on the subnet
> where the request came from. Then it applies all the options defined in
> global scope, then for that subnet and then for the pool.
> 
> You only need to use the group { ... } around the host options if you
> want to supply an option that is different to what it would otherwise
> get in the subnet.
> 
> HTH.
> 
> regards,
> -glenn
> --
> Glenn Satchell       mailto:glenn.satchell at uniq.com.au  |  Heard about
> Uniq Advances Pty Ltd           http://www.uniq.com.au  |  the new Unix
> PO Box 70 Paddington NSW Australia 2021                 |  sports car?
> tel:0409-458-580   tel:02-9380-6360   fax:02-9380-6416  |  The  rwx
> 
> 


OK :)

  /usr/local/etc/rc.d/isc-dhcpd restart
dhcpd not running? (check /var/run/dhcpd/dhcpd.pid).
Starting dhcpd.
Internet Systems Consortium DHCP Server V3.0.5rc2
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
lease 10.0.0.82: no subnet.
lease 10.0.0.84: no subnet.
lease 10.0.0.72: no subnet.
lease 10.0.0.69: no subnet.
lease 10.0.0.85: no subnet.
lease 10.0.0.94: no subnet.
lease 10.0.0.71: no subnet.
lease 10.0.0.86: no subnet.
lease 10.0.0.92: no subnet.
lease 10.0.0.93: no subnet.
Wrote 0 deleted host decls to leases file.
Wrote 0 new dynamic host decls to leases file.
Wrote 80 leases to leases file.
Listening on BPF/fxp0/00:e0:18:03:d0:3c/192.168.1/24
Sending on   BPF/fxp0/00:e0:18:03:d0:3c/192.168.1/24
Sending on   Socket/fallback/fallback-net

so I looked in my dhcpd.conf to see what was up w/ those hosts.. and 
they looked fine..

so I restarted..

  /usr/local/etc/rc.d/isc-dhcpd restart
Stopping dhcpd.
Starting dhcpd.
Internet Systems Consortium DHCP Server V3.0.5rc2
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Wrote 0 deleted host decls to leases file.
Wrote 0 new dynamic host decls to leases file.
Wrote 80 leases to leases file.
Listening on BPF/fxp0/00:e0:18:03:d0:3c/192.168.1/24
Sending on   BPF/fxp0/00:e0:18:03:d0:3c/192.168.1/24
Sending on   Socket/fallback/fallback-net

and it looks fine..

then I had another strange thing..

one host on the 10 could not get an ip..
Sep 13 10:23:31 isc dhcpd: DHCPDISCOVER from 00:40:96:35:17:a0 via 
10.0.0.62: network 10.0.0.0/25: no free leases

grep 17:a0 /var/log/dhcpd.log
Sep 13 08:30:48 isc dhcpd: DHCPDISCOVER from 00:40:96:35:17:a0 via 10.0.0.62
Sep 13 08:30:48 isc dhcpd: DHCPOFFER on 10.0.0.9 to 00:40:96:35:17:a0 
via 10.0.0.62
Sep 13 08:30:48 isc dhcpd: DHCPREQUEST for 10.0.0.9 (192.168.1.248) from 
00:40:96:35:17:a0 via 10.0.0.62
Sep 13 08:30:48 isc dhcpd: DHCPACK on 10.0.0.9 to 00:40:96:35:17:a0 via 
10.0.0.62
Sep 13 08:31:46 isc dhcpd: DHCPACK to 10.0.0.9 (00:40:96:35:17:a0) via fxp0
Sep 13 08:31:49 isc dhcpd: DHCPACK to 10.0.0.9 (00:40:96:35:17:a0) via fxp0
Sep 13 09:27:09 isc dhcpd: DHCPREQUEST for 10.0.0.9 from 
00:40:96:35:17:a0 via 10.0.0.62
Sep 13 09:27:09 isc dhcpd: DHCPACK on 10.0.0.9 to 00:40:96:35:17:a0 via 
10.0.0.62
Sep 13 09:32:56 isc dhcpd: DHCPACK to 10.0.0.9 (00:40:96:35:17:a0) via fxp0
Sep 13 09:32:59 isc dhcpd: DHCPACK to 10.0.0.9 (00:40:96:35:17:a0) via fxp0
Sep 13 10:23:30 isc dhcpd: DHCPREQUEST for 10.0.0.9 from 
00:40:96:35:17:a0 via 10.0.0.62: lease 10.0.0.9 unavailable.
Sep 13 10:23:30 isc dhcpd: DHCPNAK on 10.0.0.9 to 00:40:96:35:17:a0 via 
10.0.0.62
Sep 13 10:23:31 isc dhcpd: DHCPDISCOVER from 00:40:96:35:17:a0 via 
10.0.0.62: network 10.0.0.0/25: no free leases
Sep 13 10:23:35 isc dhcpd: DHCPDISCOVER from 00:40:96:35:17:a0 via 
10.0.0.62: network 10.0.0.0/25: no free leases
Sep 13 10:23:43 isc dhcpd: DHCPDISCOVER from 00:40:96:35:17:a0 via 
10.0.0.62: network 10.0.0.0/25: no free leases
Sep 13 10:23:58 isc dhcpd: DHCPDISCOVER from 00:40:96:35:17:a0 via 
10.0.0.62: network 10.0.0.0/25: no free leases
Sep 13 10:24:33 isc dhcpd: DHCPDISCOVER from 00:40:96:35:17:a0 via 
10.0.0.62: network 10.0.0.0/25: no free leases
Sep 13 10:25:33 isc dhcpd: DHCPDISCOVER from 00:40:96:35:17:a0 via 
10.0.0.62: network 10.0.0.0/25: no free leases
Sep 13 10:28:30 isc dhcpd: DHCPDISCOVER from 00:40:96:35:17:a0 via 
10.0.0.62: network 10.0.0.0/25: no free leases
Sep 13 10:29:56 isc dhcpd: DHCPDISCOVER from 00:40:96:35:17:a0 via 10.0.0.62
Sep 13 10:29:56 isc dhcpd: DHCPOFFER on 10.0.0.31 to 00:40:96:35:17:a0 
via 10.0.0.62
Sep 13 10:29:56 isc dhcpd: DHCPREQUEST for 10.0.0.31 (192.168.1.248) 
from 00:40:96:35:17:a0 via 10.0.0.62
Sep 13 10:29:56 isc dhcpd: DHCPACK on 10.0.0.31 to 00:40:96:35:17:a0 via 
10.0.0.62

I finally had to assign it a static IP..

What does that mean?

I tried to test it out w/ a laptop.. that was assigned an ip from the 
dynamic range of the 10. (10.0.0.80) I removed that, released the IP 
from the client, restarted dhcpd, saw this:

Stopping dhcpd.
Starting dhcpd.
Internet Systems Consortium DHCP Server V3.0.5rc2
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
lease 10.0.0.81: no subnet.
lease 10.0.0.80: no subnet.
lease 10.0.0.80: no subnet.
lease 10.0.0.80: no subnet.
lease 10.0.0.80: no subnet.
Wrote 0 deleted host decls to leases file.
Wrote 0 new dynamic host decls to leases file.
Wrote 78 leases to leases file.
Listening on BPF/fxp0/00:e0:18:03:d0:3c/192.168.1/24
Sending on   BPF/fxp0/00:e0:18:03:d0:3c/192.168.1/24
Sending on   Socket/fallback/fallback-net

tail'ed the log and had the laptop renew its ip and saw this:

Sep 13 10:35:35 isc dhcpd: lease 10.0.0.81: no subnet.
Sep 13 10:35:35 isc dhcpd: lease 10.0.0.80: no subnet.
Sep 13 10:35:35 isc last message repeated 3 times
Sep 13 10:35:35 isc dhcpd: Wrote 0 deleted host decls to leases file.
Sep 13 10:35:35 isc dhcpd: Wrote 0 new dynamic host decls to leases file.
Sep 13 10:35:35 isc dhcpd: Wrote 78 leases to leases file.
Sep 13 10:35:35 isc dhcpd: Listening on 
BPF/fxp0/00:e0:18:03:d0:3c/192.168.1/24
Sep 13 10:35:35 isc dhcpd: Sending on 
BPF/fxp0/00:e0:18:03:d0:3c/192.168.1/24
Sep 13 10:35:35 isc dhcpd: Sending on   Socket/fallback/fallback-net
Sep 13 10:35:46 isc dhcpd: DHCPDISCOVER from 00:14:a4:25:81:b4 via 10.0.0.62
Sep 13 10:35:47 isc dhcpd: DHCPOFFER on 10.0.0.119 to 00:14:a4:25:81:b4 
(Laptop-8) via 10.0.0.62
Sep 13 10:35:49 isc dhcpd: DHCPDISCOVER from 00:14:a4:25:81:b4 
(Laptop-8) via 10.0.0.62
Sep 13 10:35:49 isc dhcpd: DHCPOFFER on 10.0.0.119 to 00:14:a4:25:81:b4 
(Laptop-8) via 10.0.0.62
Sep 13 10:35:58 isc dhcpd: DHCPDISCOVER from 00:14:a4:25:81:b4 
(Laptop-8) via 10.0.0.62
Sep 13 10:35:58 isc dhcpd: DHCPOFFER on 10.0.0.119 to 00:14:a4:25:81:b4 
(Laptop-8) via 10.0.0.62
Sep 13 10:35:58 isc dhcpd: DHCPREQUEST for 10.0.0.119 (192.168.1.248) 
from 00:14:a4:25:81:b4 (Laptop-8) via 10.0.0.62
Sep 13 10:35:58 isc dhcpd: DHCPACK on 10.0.0.119 to 00:14:a4:25:81:b4 
(Laptop-8) via 10.0.0.62

all looked fine..

so I wonder why that other machine could not get an IP and would not..



More information about the dhcp-users mailing list