Re: [dhcwg] Load Balancing for DHCPv6

["Bernie Volz (volz)" <[e-mail]>]

Bud:

> the server could allocate a lease on the spot in response to the Request (i.e., without having seen a Solicit)?

Correct.

As this address (or prefix) is likely in other-available, the server would not be able to assign it. But with DHCPv6, it can provide an alternative -- it is the Reply that matters (this is one difference over DHCPv4 where the server would be forced to NAK - or just drop the packet).

---

However, Andre's proposal would be that if the server-duid matches but load balancing says that this is not the server that should be responding, to drop the request. This would thus force the client to return to Solicit (when the Requesting times out) or to advance to Rebind (when renewing between T1 and T2). This would work to move the client to the "correct" server but it does increase the traffic and load for those packets that are dropped.

This would generally only impact Request and Renew packets. I would think that the server should always process Release and Decline since those are limited in their retransmissions (and the client fallback is to stop sending).

So, I think when both failover partners are responsive the load balancing processing would be:
- If server-duid not represent in request (Solicit, Rebind, Confirm, Information-Request), use load balancing to determine if server responds.
- If server-duid present and doesn't match this server, drop packet (standard RFC 3315).
- (server-duid present and matches server), if Request or Renew still use load balancing to determine if server responds.
- Otherwise respond to client.

- Bernie

-----Original Message-----
From: Bud Millwood [mailto:[e-mail]] 
Sent: Friday, September 21, 2012 9:33 AM
To: Andre Kostur
Cc: Bernie Volz (volz); [e-mail]; Ted Lemon
Subject: 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 <[e-mail]> wrote:
> On Tue, Sep 18, 2012 at 9:24 AM, Bernie Volz (volz) <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg