From: P729 (p729@xxxxxxx)
Date: Wed Jul 24 2002 - 03:34:23 GMT-3
Whoops, I meant "two IOS-based DHCP servers..."
Regards,
Mas Kato
https://ecardfile.com/id/mkato
----- Original Message -----
From: "P729" <p729@cox.net>
To: "Anthony Pace" <anthonypace@fastmail.fm>; <ccielab@groupstudy.com>
Sent: Tuesday, July 23, 2002 10:40 PM
Subject: Re: DHCP back up
> 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