From: André Bersvendsen (an-bersv@xxxxxxxxx)
Date: Tue Jul 23 2002 - 04:50:33 GMT-3
I am sorry to say that I do not agree.
The model of operation described in RFC2131 enables multiple,
independent DHCP servers on a network. It require that a DHCP client is
prepared to receive multiple responses to its broadcast messages. I
described this last part in an earlier e-mail to this group when I wrote
that the first reply received from a server will be handled other
replies from other servers will be discarded.
In my example I used a shared DHCP database for the two DHCP servers but
in fact they do not have to share any database at all - and they do not
have to communicate together.
A DHCP server is supposed to test if IP address is in use or not when it
chooses an IP address that it will use for a client. This is normally
done with PING.
So if you have two DHCP servers with the same scope then the two servers
might/possibly want to give out a IP address that the other server
already have given out to a client, but it will not be done because the
PING will see that the address is in use. A new address is then used
until it find one that is available.
So the RFC say that you can have multiple independent DHCP servers with
the same scope. And it works in real life networks.
I do not find a solution with two (or more) DHCP servers with different
scopes as a optimal solution. The reason is that this will waste IP
addresses, and it will force the clients to change IP address if the
DHCP server that provided its address go down.
You must make the scopes on the servers large enough to handle all the
clients. So two servers must use twice as many IP addresses than one.
Lets say that server #1 provided the client a address. Now server #1 is
down.
The client want to renew its leasing time for the IP address but get no
answer from server #1.
It will get a DHCPNAK from server #2 because the address requested is
out of the scope.
Then the client have to start the DHCP process with DHCPDISCOVER. The
result is that the client will get a new IP address. This is not optimal
if the client was doing a FTP session or a video conference etc. You
loose the sessions.
If they had the same scope server #2 would have looked at the request
from the client and the address would not have been marked as used in
its DHCP database (not shared database) so the server would then have
sent out a DHCPACK and updated its database.
If they had a shared database server #2 would have found the clients MAC
address in the database and if the requested IP address is the same as
in the database it will send out a DHCPACK.
>Another thing to consider about the 2 DHCP servers with mutually
>exclusive address rages is that they are truly fault tollerant as they
>are not communicating or depending on each other for any thing. Any
>DHCP solutions where the two need to "share" ranges or communicate run
>the risk of having that process "break down"
>
>Anthony Pace
>
>
>
>On Mon, 22 Jul 2002 12:55:47 +0200, "Andri Bersvendsen"
><an-bersv@online.no> said:
>
>
>>This is how the DHCP database stored on the TFTP server looks like.
>>This sample is from my network at home and it have two routers that is
>>set up as DHCP servers.
>>
>>*time* Jul 22 2002 11:36 AM
>>*version* 1
>>!IP address Type Hardware address Lease expiration
>>192.168.13.101 id 0100.d0ba.846a.4e Jul 23 2002 08:25 PM
>>192.168.13.103 id 0100.50da.5a39.6f Jul 24 2002 11:32 AM
>>192.168.13.116 id 0100.3080.62ab.b7 Jul 23 2002 08:25 PM
>>192.168.13.124 id 0100.40d0.1432.26 Jul 22 2002 09:42 PM
>>192.168.13.125 id 0100.3080.62ab.19 Jul 23 2002 10:02 PM
>>
>>
>>!IP address Interface-index Lease expiration Server IP
>>address Vrf
>>*end*
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:36:40 GMT-3