host statement scope rules (ISC DHCP 3.0.5b1)

Simon Hobson dhcp1 at
Wed Aug 2 14:51:19 UTC 2006

kalyanasundaram S wrote:

>It is better to see with some examble.
>I dont understand something here.
>(I have changed IP address so the subnet mask will be wrong..)

Unfortunately, your subnets as written here overlap, so it is 
impossible to see properly what is going on !

>subnet netmask {   ##first subnet
>subnet netmask { ##sescond subnet

>My servers is in
>client is in same subnet.. i have no router it is standalone setup 
>connected via switch )..

So your configuration is not valid for the network. Where is the subnet if it isn't connected locally and isn't connected 
via a router ?

So here we have confusion caused by an invalid config, it's no wonder 
you can't figure out what's happening !

Looking at your first case again :

>subnet netmask {   ##first subnet
>   range;
>	default-lease-time 50;
>	max-lease-time 100;
>	ddns-domainname "";
>	option domain-name "";
>     host test {
>               hardware ethernet 00:03:47:1f:3d:e2;
>	      ddns-hostname "m3";
>############  fixed-address;
>subnet netmask { ##sescond subnet
>	range;
>	default-lease-time 67;
>	max-lease-time 77;
>	ddns-domainname "";
>	option domain-name "";
>from the client side:
>CLASSID='Linux 2.6.5-7.179-default i686'
>So as what Ted Lemon was saying that..
>1. IP address configuration scope: based on this it got IP address 
>from the  outter subnet.(need not stick with where it is declared)
>2. IP allocation configaration scope: it got option domain and lease 
>info from the subnet where it is declared..
>(I also found that if i remove option domain-name "" it 
>gets from other subnet like "" so options are not overridden 
>if available)

Here is an example of why I think allowing such configs should be 
deprecated. it is just plain wrong IMHO.

You have a client which should have a domain name of "" but 
it actually gets sent "" - that may or may not be correct. 
However, you have not included the routers option which is required 
for virtually any operational network, and if it behaves the same 
then your client will get the WRONG ROUTER and so will NOT be able to 
participate in the network.

I feel sure that this is the likely cause of some "my client got the 
wrong options" messages on this list.

Since the client would normally inherit the correct options when it 
is allocated to a subnet, then that should be the way things work. If 
the administrator specifically wants to apply different values, then 
he can do so by adding options to the host statement itself (or an 
enclosing group {} ) which would have the effect some people 
apparently want (but haven't spoken up to say so) but in a manner 
that is immediately obvious from a perusal of the config.

Given the number of 'rtfm' questions/problems that already come up, I 
don't think it's going to be practical to adequately document the 
behaviour of hosts statements within subnet declarations in the man 
pages. Given the pitfalls, and the fact that there is a perfectly 
workable alternative for anyone that needs it, I suggest that the 
warning already there should stay and the 'feature' should be 
considered deprecated - it's the cleanest way to handle it.


More information about the dhcp-users mailing list