Re: [dhcwg] Load Balancing for DHCPv6
Bud Millwood <budmillwood@gmail.com> Fri, 21 September 2012 13:32 UTC
Return-Path: <budmillwood@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD4F21F845C for <dhcwg@ietfa.amsl.com>; Fri, 21 Sep 2012 06:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISIQHDKBlIKV for <dhcwg@ietfa.amsl.com>; Fri, 21 Sep 2012 06:32:58 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C2BF521F87F3 for <dhcwg@ietf.org>; Fri, 21 Sep 2012 06:32:46 -0700 (PDT)
Received: by iec9 with SMTP id 9so6192831iec.31 for <dhcwg@ietf.org>; Fri, 21 Sep 2012 06:32:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nqjoHltghy5pvi19eSPqLolUpsPDvNUi9beExzXib6k=; b=GvElZJ+7LCWIR/5gz2X/UMNWpkws9bt579S/MShbah0tGKdV+aOSeqafjLcdrWsPrL yhhnlYs9on0oN0lqY23Q1yjzYlaGGseCLrtRPWabpPfLah6w9KCJvsS6YTiPD/eCfCvy TzklQDPNpf49pjLJcpuCGJDBZ0hpQQ6TrvU/nNP2hhBdjLBsSXS9Jm3jHLs3nT50Ugj0 U/+5HcKM28Qg/+V5+OW0nWzjLtKkyYMz9eX4KvSQ0bCpqc8QzN4egC2yajgV9Ig02SXV jQ9oTOtz4BX/jXdGpwjjuJd6uIkKec0quaiLFx3I007iIwmO3fNHwiLximzuqQ9+WATY G03A==
MIME-Version: 1.0
Received: by 10.50.190.197 with SMTP id gs5mr1658453igc.32.1348234365897; Fri, 21 Sep 2012 06:32:45 -0700 (PDT)
Received: by 10.64.35.198 with HTTP; Fri, 21 Sep 2012 06:32:45 -0700 (PDT)
In-Reply-To: <CAL10_BpPKCocKM1rzcxwv8LXQHxXUw9rOEfycRWyiRMLTsGsaw@mail.gmail.com>
References: <CAL10_BqbUrhzYJMSLBGsFDR_kFth2SbdC9AOHyOfyKdhNyzNkw@mail.gmail.com> <CC7E13F1.2549%volz@cisco.com> <CAL10_BpPKCocKM1rzcxwv8LXQHxXUw9rOEfycRWyiRMLTsGsaw@mail.gmail.com>
Date: Fri, 21 Sep 2012 15:32:45 +0200
Message-ID: <CAOpJ=k2wKfnVswbjT2Rf43Dnk=xBqWkbr=Az5--8tE=ca3XxHA@mail.gmail.com>
From: Bud Millwood <budmillwood@gmail.com>
To: Andre Kostur <akostur@incognito.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>, Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [dhcwg] Load Balancing for DHCPv6
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Sep 2012 13:32:59 -0000
Andre: I think the only reasonable way to move clients back to server A is what you suggest. You are essentially doing the same thing as the failed server A did when it failed - going offline - but you're just doing it administratively, and just for a subset of clients. It causes a degraded performance mode on your network, but you have to balance that against the desire to split the load after server A has come back online. It's not a failover problem so much as it's a load balancing problem. For example, suppose you wanted to change the load balancing split to 70/30 instead of 50/50 on a running network - you'd use the same mechanism. Bernie: > However, it does complicate Request packets because failover doesn't > usually exchange tentative bindings from a Solicit and so you really would > only want the server that Solicited to respond to the Request (this could > be done by looking to see if you had a tentative binding - but if neither > server does, the client has to suffer a Request timeout to get back to the > Solicit phase). Is this a problem because under normal circumstances, the server could allocate a lease on the spot in response to the Request (i.e., without having seen a Solicit)? It seems like a reasonable tradeoff - to disallow a failover partner from short-circuiting the full lease transaction. - Bud On Tue, Sep 18, 2012 at 6:42 PM, Andre Kostur <akostur@incognito.com> wrote: > On Tue, Sep 18, 2012 at 9:24 AM, Bernie Volz (volz) <volz@cisco.com> wrote: >> First, I think this would be a rather bad change to DHCPv6 operation. >> Client may be checking the server-identifier option they get back and so >> you would have to lie about that in the response which just seems like a >> very bad thing to do. (I don't believe RFC 3315 actually ever states the >> clients should be checking the server-identifier, but I could be wrong -- >> section 15 does say they check for the presence of the option, but do not >> check the contents). One could also think of situations where a relay >> agent might forward the packet to explicit destinations based on the >> server identifier (though again, I doubt anyone does this) -- much like >> switches limit traffic based on mac-addresses. > > Note that I didn't suggest that server A preemptively answer the Renew > coming in from the client (or impersonate server B). Under my > suggestion, the Renew would arrive at both servers A and B. B would > ignore it due to load balancing, and A would also ignore it due to the > server ID. The client continues to retry the Renews for the > appropriate time, until it is time to Rebind. At that point server B > is still ignoring the client, but now A can answer the client as the > Rebind isn't carrying a Server ID. (And if we are talking about a > Failover pair, then server A would already have a lease record for > this client, and can extend that same lease.) > > For the relay piece, it would still need to forward the Rebind to both servers. > > [snip] > >> Anyway, I think this needs to be thought through much more carefully as to >> the potential consequences and I think the best is to keep it simple - >> once a client has 'bound' to a server, it stays with that server until it >> issues a request message which does not contain a server-identifier option. > > My scenario doesn't result in a client switching servers except under > already defined RFC 3315 behaviour when the client has transitioned > into Rebind. > > One piece that may have funny consequences is if the pair of DHCP > servers aren't in some sort of cooperation mode, and this scenario > would result in the client possibly changing IP addresses. Client has > to rebind, and server A does the DHCPv6 equivalent of a NAK and forces > the client to come back to get a new IP. Perhaps a server MAY skip > the load balancing if the packet contains a Server ID (or even > limiting it to the server's Server ID)? > > -- > Andre Kostur > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Load Balancing for DHCPv6 Bernie Volz (EUD)
- [dhcwg] Load Balancing for DHCPv6 Andre Kostur
- Re: [dhcwg] Load Balancing for DHCPv6 Bernie Volz (volz)
- Re: [dhcwg] Load Balancing for DHCPv6 Andre Kostur
- Re: [dhcwg] Load Balancing for DHCPv6 Ted Lemon
- Re: [dhcwg] Load Balancing for DHCPv6 Ted Lemon
- Re: [dhcwg] Load Balancing for DHCPv6 STARK, BARBARA H
- Re: [dhcwg] Load Balancing for DHCPv6 Andre Kostur
- Re: [dhcwg] Load Balancing for DHCPv6 Ted Lemon
- Re: [dhcwg] Load Balancing for DHCPv6 Bernie Volz (volz)
- Re: [dhcwg] Load Balancing for DHCPv6 Bud Millwood
- Re: [dhcwg] Load Balancing for DHCPv6 Andre Kostur
- Re: [dhcwg] Load Balancing for DHCPv6 Ted Lemon
- Re: [dhcwg] Load Balancing for DHCPv6 Bernie Volz (volz)
- Re: [dhcwg] Load Balancing for DHCPv6 Tomek Mrugalski
- Re: [dhcwg] Load Balancing for DHCPv6 Bernie Volz (volz)
- Re: [dhcwg] Load Balancing for DHCPv6 Donald Eastlake
- Re: [dhcwg] Load Balancing for DHCPv6 Ted Lemon
- Re: [dhcwg] Load Balancing for DHCPv6 Donald Eastlake
- Re: [dhcwg] Load Balancing for DHCPv6 Ted Lemon
- Re: [dhcwg] Load Balancing for DHCPv6 Donald Eastlake
- Re: [dhcwg] Load Balancing for DHCPv6 Ted Lemon
- Re: [dhcwg] Load Balancing for DHCPv6 Andre Kostur
- Re: [dhcwg] Load Balancing for DHCPv6 Donald Eastlake
- Re: [dhcwg] Load Balancing for DHCPv6 Bernie Volz (volz)
- Re: [dhcwg] Load Balancing for DHCPv6 Andre Kostur
- Re: [dhcwg] Load Balancing for DHCPv6 Bernie Volz (volz)
- Re: [dhcwg] Load Balancing for DHCPv6 Andre Kostur
- Re: [dhcwg] Load Balancing for DHCPv6 Bernie Volz (volz)
- Re: [dhcwg] Load Balancing for DHCPv6 Donald Eastlake
- Re: [dhcwg] Load Balancing for DHCPv6 Bernie Volz (volz)
- Re: [dhcwg] Load Balancing for DHCPv6 Bud Millwood
- Re: [dhcwg] Load Balancing for DHCPv6 Bernie Volz (volz)
- Re: [dhcwg] Load Balancing for DHCPv6 Andre Kostur
- Re: [dhcwg] Load Balancing for DHCPv6 Andre Kostur
- Re: [dhcwg] Load Balancing for DHCPv6 Bernie Volz (volz)
- Re: [dhcwg] Load Balancing for DHCPv6 Andre Kostur
- Re: [dhcwg] Load Balancing for DHCPv6 Andre Kostur