RE: [dhcwg] load balancing RFC - what happens if you insert a new server?

"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Fri, 07 September 2001 02:22 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14653; Thu, 6 Sep 2001 22:22:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15046; Thu, 6 Sep 2001 22:21:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15021 for <dhcwg@ns.ietf.org>; Thu, 6 Sep 2001 22:21:38 -0400 (EDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14636 for <dhcwg@ietf.org>; Thu, 6 Sep 2001 22:20:10 -0400 (EDT)
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f872Lbp10807 for <dhcwg@ietf.org>; Thu, 6 Sep 2001 21:21:37 -0500 (CDT)
Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f872Lb029394 for <dhcwg@ietf.org>; Thu, 6 Sep 2001 21:21:37 -0500 (CDT)
Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Sep 06 21:21:36 2001 -0500
Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <P4MQL359>; Thu, 6 Sep 2001 21:21:36 -0500
Message-ID: <66F66129A77AD411B76200508B65AC697B3554@eambunt705.ena-east.ericsson.se>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: 'Lisa Guo' <lguo@tahoenetworks.com>, dhcwg@ietf.org
Subject: RE: [dhcwg] load balancing RFC - what happens if you insert a new server?
Date: Thu, 06 Sep 2001 21:21:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13743.D1886D00"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

Hi:

It all depends on how the server works. If the server only applies the load balancing to NEW clients and not to renewals, then there really is no problem. That really was the intent of the protocol. Also, only broadcast packets are an issue as unicast datagrams are set to the server in question.

Section 3 of RFC 3074 says:

   Because DHCP clients use UDP broadcasts to contact DHCP servers, a
   client DHCPDISCOVER message may be received by more than one server.
   All servers receiving such a broadcast may respond to the client,
   letting the client choose which server it will use.

There likely will be a revision of this RFC shortly when the DHCPv6 DUID is defined to support load balancing for DHCP for IPv6 as well. Perhaps during that revision (new Internet-Draft), we can be a bit clearer as to the proper use of this.

- Bernie Volz

PS: Note also that for IPv6, while most client generated packets are multicast, the target server is specified when the message is destined for a particular server and that server should process that message regardless of what the load balancing says.

-----Original Message-----
From: Lisa Guo [mailto:lguo@tahoenetworks.com]
Sent: Thursday, September 06, 2001 9:31 PM
To: dhcwg@ietf.org
Subject: [dhcwg] load balancing RFC - what happens if you insert a new server?


Hi,

  I was looking for discussion on this on the archive website but
couldn't find any, so if this has been discussed before, I apologize.

  The load balancing RFC (3074) describes a hashing algorithm that
is used by servers and relay agents to serve the clients in a deterministic
way. I assume that the purpose is that the same server always serve
the same client, from the initial discover/offer/request/ack to subsequent
messages, such as renew, release, etc. What happens if a new server
is added to the pool of servers that share the load? In order to use the
new server, some of the hash bucket should be assigned to this new
server now. But if one does that, messages related to an existing lease
would be forwarded to the new server instead of the one that actually
allocated the IP address in the first place.

  Does anyone have a workaround on this?

Thanks,
Lisa 
-----------------------
Lisa Guo
Tahoe Networks, Inc.