DHCPD issues.

[Glenn Satchell]

You also seem to be missing a definition for the default gateway on each 
subnet. This is needed so that the client can communicate with the dhcp 
server. This also means that the range should *not* include this address.

So assume that there is a router, or the dhcp server has a secondary IP 
address for each subnet, then you need

option routers 172.31.201.1;
range 172.31.201.2 172.31.201.254;

and so on in each subnet.

Classes operate at the pool level, so you need a pool for each range, 
like this:

shared subnet ...
   subnet ...
     pool {
       range ...
       allow members of "class_a"
     }
   }
   subnet ...

regards,
-glenn

On 01/11/12 08:04, Simon Hobson wrote:
> Stack KororÇ wrote:
>
>> Whenever I boot any of the VM's the IP always lands in the
>> 172.31.202.x IP address range.
>
> And if you look closely, they also probably have the wrong options (such
> as router - if you were specifying it).
>
>> subnet 172.31.201.0 netmask 255.255.255.0 {
>> default-lease-time 86400;
>> max-lease-time 86400;
>> deny unknown-clients;
>> range 172.31.201.1 172.31.201.254;
>> group "devnet" {
>> host dev001.project.local { hardware ethernet 08:00:27:11:4B:E8; }
>
> ^^^^^
> THIS DOES NOT WORK
>
> Host statement are global in scope, so any defined host statement
> "exists" in all subnets. However, what you will find is that the host
> will inherit options from the subnet where it's host statement is
> declared - even though they are invalid for wherever it happens to be.
>
> For this setup, your best bet is classes and subclasses (check the man
> page where there is a specific example of allocating devices to classes
> based on MAC).
>
> then you can do :
> shared subnet ...
> subnet ...
> range ...
> allow members of "class_a"
> }
> }
> subnet ...
> range ...
> allow members of "class_b"
> }
> }
> subnet ...
> range ...
> allow members of "class_c"
> }
> }
> }
>