Several ip-addresses to the same MAC address.
Glenn Satchell
Glenn.Satchell at uniq.com.au
Fri Apr 28 14:08:49 UTC 2006
>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
More information about the dhcp-users
mailing list