Subject: RE: Load (re)balancing for renewals.

From: Steve Gonczi <[email-masked]>
Date: Fri, 11 Feb 2000 14:23:36 -0500

If we stay within the framework fo the failover protocol, the address would
not
change.  If I am reading your post correctly, you are forcing the clients 
to start over (DISCOVER) hence get a new address.

My suggestion would not involve NAK-ing any client. We would merely ignore
some of them, so that they get to t2 and start broadcasting their renewal
request.

Because of the 2 failover servers having identical lease databases,
at this point they would be able to renew their addresses, ( and get the
same address) but from the other server.

I should have been clearer on this point.

sG

-----Original Message-----
From: Diana Lane [mailto:[email-masked]]
Sent: Friday, February 11, 2000 2:14 PM
To: [email-masked]'
Subject: RE: Load (re)balancing for renewals.

Steve,

For what it's worth, we have been known to deactivate the leases to get
Server B to NAK requests from some of the clients so that they switch back
to Server A.  I like your renewal ignoring idea better, though, because one
would not have to remember to go reactivate the leases.  The problem with
either approach is that some applications do not take it kindly when their
IP address suddenly changes out from under them.

Diana Lane
Sr. Network Engineer
IP Research & Development
Wal-Mart Stores, Inc.
501/277-3177
- WAL*MART CONFIDENTIAL -

---

From: Bernie Volz <[email-masked]>
Date: Fri, 11 Feb 2000 14:23:41 -0500

>Hm.  What about sending the other server's IP address back in the
>server identifier option once it comes back up, if you receive a
>request for an address for which you're not the primary?  We could
>then use your strategy to account for clients that don't notice the
>switch.  We could also strategically send a short T2 (t1 == t2, for
>example) to clients to which we are responding because the server that
>is primary for them is down.
>
>			       _MelloN_

Yes, I like that far better than Steve's suggestion of waiting until
T2's broadcast.

Also, doing nothing likely isn't that big a deal. Eventually the
clients will get redistributed (of course the secondary server
will need to be down at a renewal or the client will have to have
the lease expire - such as if it is removed from the network).

- Bernie

---

From: Steve Gonczi <[email-masked]>
Date: Fri, 11 Feb 2000 14:39:59 -0500

Yes, I like Ted's suggestion too. I was primarily concerned with 
pointing out the issue, and my solution was to some degree, improvised.

I believe this issue is worth solving. It is clearly possible that clients
get spontaneously redistributed but (IMHO) it is not probable.

---

From: Bernie Volz <[email-masked]>
Date: Fri, 11 Feb 2000 16:15:31 -0500

Can we get some indication from DHCP Client implementors as to what
checking they do on the server-identifier field?

Can we really change this or will clients reject the renewal?

----
Kim Kinnear wrote:

I feel like this isn't a big deal, and what experience
we have in practice seems to bear that out.

Though using the server-identifier to "change" the DHCP server is
a neat trick if you know the other one is up.  I believe that is
what Ted was suggesting.  (Though not, I think, what Steve
thought Ted was suggesting.  There is no NAKing involved in this
approach.)

If we want to solve this "problem", that is the solution that I
think we should use.

I don't think shortening the renewal interval is necessary or
useful in this case partly, I suppose, since I don't think having
the secondary renew leases is in general a big problem.

I'm thinking too that increasing the load on the secondary
(sooner than necessary) is not a good idea.  Remember that over
time, the renewal times will get shorter and shorter until they
equal the MCLT, and then they will be the MCLT until the primary
comes up or someone tells the secondary that the primary is down.

Cheers -- Kim