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