MAC to IP assignment not working - dhcprelay

[Glenn Satchell]

Yes, the deny known-clients just reinforces the default behaviour and
forces it to use fixed-address only. A fixed-address will be preferred
if it is valid in that subnet or shared-network. Sounds like you don't
need the deny in your case.

regards,
-glenn

>Date: Wed, 25 Apr 2007 08:06:14 -0400
>From: Edwin Whitelaw <Edwin.Whitelaw at nrvunwired.net>
>To: dhcp-users at isc.org
>Subject: Re: MAC to IP assignment not working - dhcprelay
>
>Glenn,
>
>
>The shared-subnet comment was the key.  I'm a wireless ISP and each 
>remote access point (Voyage Linux on a single board computer) has two 
>nets per system, one NATed, for customers' routers and the other a  
>non-NATed, IP for internal network devices.  This being my first attempt 
>to use the relay approach, I'd failed to realize I still needed the 
>shared-network statement back on the central DHCP server.
>
>The small range declared allows both client routers and network bridges 
>to acquire a NATed IP automagically with a short lease pending their 
>addition to the include file for a fixed MAC-IP relationship.  It's 
>worked well in practice but needed to be consolidated via relay.
>
>Assuming my other configuration is correct, I've not had a problem with 
>clients getting range addresses if they have an entry in the included 
>host assignment file.  I assume the deny known-clients declaration 
>simply reinforces the default behavior of use the fixed assignment 
>before referring to the range?  I'd rather have the client get some 
>address, even from the range, rather than none at all.  Periodic review 
>of the leases file lets me see where I've overlooked a fixed assignment 
>since my client radios have known MAC ranges.
>
>Thanks for the insightful comments.
>
>Regards,
>
>Edwin
>> Hi Edwin
>>
>> You said the include file was copied directly from the standalone dhcp
>> server. Were the subnet definitions also copied exactly?
>>
>> The dhcp server will ignore a fixed-address statement if that address
>> is not valid for the subnet where the request came from. So your hosts
>> with 172.17.20.x address will get an address from 172.16.20.20x if the
>> relay forwards a request stating that they are coming from 172.16.20.0
>> network.
>>
>> Perhaps you need a shared-network statement around the two subnet
>> definitions if both are valid in the remote location?
>>
>> You may also want to change the dynamic subnet defintion to explicitly
>> exclude the fixed hosts, eg:
>>
>> subnet 172.17.20.0 netmask 255.255.255.0 {
>> 	pool {
>> 		deny known-clients;
>>         	range 172.17.20.201 172.17.20.250;
>>         }
>>         default-lease-time 3600;
>>         max-lease-time 3600;
>>         option routers  172.17.20.1;
>>         option broadcast-address        172.17.20.255;
>>         option subnet-mask    255.255.255.0;
>> } # End of subnet 172.17.20.0
>>
>> regards,
>> -glenn
>>   
>
>-- 
><=+=+=+==+=+=+==+=+=+=+=+=+=+=+=>
>Edwin Whitelaw, P.E.
>New River Valley Unwired, LLC
>2200 Lonesome Dove Dr
>Christiansburg, VA 24073
>540-239-0318
>
>