From: P729 (p729@xxxxxxx)
Date: Wed Jul 24 2002 - 02:40:59 GMT-3
Cisco Network Registrar supports true DHCP failover by syncing the databases
and monitoring each other through heartbeats. The syncing between the
servers would be similar to another post that described two IOS-based TFTP
servers using a separate TFTP server to store the database.
Regards,
Mas Kato
https://ecardfile.com/id/mkato
----- Original Message -----
From: "Anthony Pace" <anthonypace@fastmail.fm>
To: "Andri Bersvendsen" <an-bersv@online.no>; <ccielab@groupstudy.com>
Sent: Tuesday, July 23, 2002 11:50 AM
Subject: Re: DHCP back up
> Andre,
>
> You are right that it does require twice as many addresses to have the
> DHCP servers operating independently and I would also conceed that I
> only tried 3 or 4 vendors DHCP servers which "shared the ranges" before
> giving up and falling back on the "2 server separate range" method. It
> was also several years ago that I became sold on this method. I
> remember using Checkpoint's DHCP and a couple of others that were
> supposed to work as you described below but it was problematic and
> caused workstations to be down hard; where as the 2 server method, in a
> worst case scenario required a workstation to renew the address. What
> is the DHCP server that "works in real life "? Is it the Cisco Router
> DHCP? or a How big are the networks? What happens when communication
> problems occur? I would be interested because the 2 server method is
> only feasible with private addresses due to the waste.
>
> Anthony Pace
>
> On Tue, 23 Jul 2002 09:50:33 +0200, "Andri Bersvendsen"
> <an-bersv@online.no> said:
> >
> > 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*
> > >>
> > >>
> > >>
> >
> >
> >
>
> --
> Anthony Pace
> anthonypace@fastmail.fm
>
> --
> http://fastmail.fm: send your email first class
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:36:41 GMT-3