Re: Urgent: Query on dhclient in handling IP conflict
Please take it to the debian-user list, and don't post the question
repeatedly.
sathya sai wrote:
> Hi,
>
> Can someone please help me out on this.
>
> Thanks and regards,
> Sathya
>
> On Mon, Dec 21, 2009 at 8:09 PM, sathya sai
> <sathyasai.eshwar@gmail.com>wrote:
>
>> Hi Matt,
>>
>> Thanks for your mail.
>>
>> I had already thought on these possiblities. But the problem here is, we
>> dont have control over neither our DHCP server (it can be either Windows
>> or Linux based servers) nor the client PC which configures static IP
>> (anybody in the subnet can configure the IPs on their wish). I hope, this
>> is true with the real time deployment scenario.
>>
>> Considering all these scenario, I felt that it would be better for our
>> dhclient to do a ARP broadcast as per RFC 2131 to detect the IP conflict
>> and send DHCPDECLINE in case of it. So that the DHCP server can
>> understand the existance of duplicate address and respond with the newer
>> address accordingly.
>>
>> Could please let me know your thoughts on this, so that we can make your
>> dhclient much more better on this.
>>
>> Thanks and regards,
>> Sathya
>>
>>
>>
>> On Mon, Dec 21, 2009 at 7:22 PM, Mathieu Trudel-Lapierre <mathieu.tl@
>> gmail.com> wrote:
>>
>>> On Mon, Dec 21, 2009 at 8:22 AM, sathya sai
>>> <sathyasai.eshwar@gmail.com>
>>> wrote:
>>> > Hi Paul,
>>> >
>>> > I hope, this is a common problem with the dhclient which would occur
>>> even
>>> > on debian lenny.
>>> >
>>> > Thanks and regards,
>>> > Sathya
>>> >
>>> > On Mon, Dec 21, 2009 at 6:47 PM, Paul Wise <pabs@debian.org> wrote:
>>> >>
>>> >> On Mon, Dec 21, 2009 at 9:03 PM, sathya sai <
>>> sathyasai.eshwar@gmail.com>
>>> >> wrote:
>>> >>
>>> >> > Could you please help me out by directing this query to the
>>> appropriate
>>> >> > forum.
>>> >>
>>> >> debian-user would be the appropriate forum.
>>> >>
>>> >> Please note that Debian etch is very old and will soon lose security
>>> >> support. You should really upgrade to Debian lenny at your earliest
>>> >> convenience. I'd suggest testing for the bug on both lenny and the
>>> >> in-development release, squeeze.
>>> >>
>>>
>>> Without wanting to diminish what you've done (which certainly aims at
>>> resolving a particular issue you might have been seeing), I think
>>> there would be more elegant solutions to your problem than IP conflict
>>> detection (although it could be nice to have, it would probably be
>>> more effectively reported upstream).
>>>
>>> TL;DR: There is another way to avoid conflicts without requiring *any*
>>> development on dhcp3-server or dhcp3-client. You can use reservations
>>> or change the IP pool range to resolve this issue.
>>>
>>> Longer version:
>>>
>>> What I'd do in this case is either of two solutions:
>>>
>>> 1- Rather simply, and to retain most of what has been done already;
>>> change the DHCP range of IP addresses given out to "dynamic" clients
>>> to something that doesn't contain the IP of the machines that are
>>> statically assigned.
>>>
>>> For example, set aside 2-31 for statically assigned systems, then
>>> 32-254 for dynamic assignment.
>>>
>>> 2- Slightly change the setup: have all the systems get an IP from
>>> DHCP, but make sure that the IPs given out to the machines that should
>>> be statically assigned are always the same. You can do this easily
>>> using reservations, which is a matter of matching an IP to a
>>> particular MAC address. In dnsmasq, that's done with /etc/ethers. In
>>> dhcpd, it's done in dhcpd.conf in a special stanza.
>>>
>>> Both these options address the same issue: systems will no longer be
>>> assigned conflicting IP addresses. Additionally, there are some pretty
>>> nifty things you could do with option 2 from then on, such as
>>> dynamically building DNS information from the DHCP leases. Your
>>> "servers" which as assigned the same IP all the time are always there,
>>> and names of the "clients" (which could be new systems added from
>>> visitors or whatever), could "publish" their desired name through DHCP
>>> and have this information visible in DNS requests (just as you could
>>> also do reverse DNS).
>>>
>>> Sorry if this is rather verbose, just expressing a different way of
>>> solving the situation.
>>>
>>> With kind regards,
>>>
>>> / Matt
>>>
>>
>>
Reply to: