Re: [dhcwg] Load Balancing for DHCPv6

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