Several ip-addresses to the same MAC address.

[Glenn Satchell]

>Subject: Several ip-addresses to the same MAC address.
>Date: Fri, 28 Apr 2006 15:02:07 +0200
>From: <Staffan.Ungsgard at teliasonera.com>
>To: <dhcp-users at isc.org>
>
>Hi
>Does the isc-server support multiple ip-addresses to a single MAC. This is what 
happens for us with a home gateway that
>uses different links/interfaces (VP/VC) for different services. An unique 
option-82 information is added to each interface which then
>is used to offer addresses from different pools for different servers.
>
>In the snippet below, two different addresses are handled by the dhcp-server 
for the same MAC address.
>Everything works fine for the initial address offer as the dhcp-server uses the 
option-82 infomation to distinguish between the
>different "clients". The request is broadcasted, picked up by a relay and then 
relayed to the dhcp-server with added option-82 information.
>When the address is renewed, it's done via a unicast straight fromc each client 
to the server, and thus no option-82 information
>will be present.
>
>What I think happens here is that the dhcp-server finds the MAC address in it's 
internal database, but as there must be records
>for two different ip-addresses bound to the same MAC, and the dhcp-server 
happens to find the "other record" first, it finds out
>that the ip-address bound to the MAC is not the same as the address requested - 
and therefore NACKs the request.
>
>When finally the client does a DHCPREQUEST via the broadcast/relay again, the 
request is granted.
>
>Can anybody shine any light on this - is my description above correct, and is 
there anything I can do to get rid of the NAKs.

Hi Staffan

This setting, from the dhcpd.conf man page, would seem to be
what you need:

     The stash-agent-options statement

       stash-agent-options flag;

       If the stash-agent-options parameter is true for  a  given
       client, the server will record the relay agent information
       options sent during the client's initial DHCPREQUEST  mes-
       sage when the client was in the SELECTING state and behave
       as if those options are included in all subsequent DHCPRE-
       QUEST  messages  sent  in the RENEWING state.   This works
       around a problem with  relay  agent  information  options,
       which  is that they usually not appear in DHCPREQUEST mes-
       sages sent by the client in the  RENEWING  state,  because
       such  messages  are unicast directly to the server and not
       sent through a relay agent.

If this doesn't help, what do the two entries from the
dhcpd.leases file look like? Note that the last entry for each
IP address is the valid one, as this file is never updated,
records are only appended to it.

regards,
-glenn