Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-load-balancing-00

[Andre Kostur <[e-mail]>]

Some general clarification questions (inline):


On Tue, Jun 11, 2013 at 12:28 PM, Tomek Mrugalski <
[e-mail]> wrote:

Section 3.1.2: A question about "A DHCPv6 server receiving a REQUEST or
> RENEW with the server's Server ID specified MAY answer the request even
> if the request would normally be ignored by load balancing.". Does it
> mean that the opposite is true - server MAY chose to not answer if the
> load balancing says so, even when server-id matches? That's what rest of
> the first paragraph suggests. If that is what you meant, then I strongly
> oppose. Here's why:
>

I don't think it says that.  The servers are still doing the logic of "If
the client is supplying a server ID, and it's not me, don't process this
packet."  (Not including potential logic of discarding an advertised IA as
it has seen that a different DHCP server is being chosen, or other such
logic).  Also barring server policy causing it to ignore that packet for
other reasons.

The text mentions a case of 2 servers, with the first one going offline
> and the second server taking over all clients. The text says that once
> the first server recovers and the second server ignores RENEWs,
> eventually the first server will be able to respond clients that start
> REBINDing. This will cause the clients to constantly go through
> REQUEST->failed RENEW attempts->REBIND cycles, even when both servers
> are fine. Nothing really gained, but you just introduced REBINDs to
> perfectly healthy network (with the extra processing needed for REBINDs
> and possible warnings all around, as REBIND is usually a sign of troubles).
>

This shouldn't result in a constant cycle, only one cycle (where "primary
client" == a client which should be answered by the primary server in a
LB+Failover pair, and "secondary client" == a client which should be
answered by the secondary server in a LB+Failover pair):
1) All servers are healthy
2) Primary server fails
3) A set of clients come online.  (mix of primary and secondary clients).
 The Secondary clients are perfectly happy as the secondary server is still
online.  The primary clients get serviced by the secondary server as well,
as the secondary server knows that the primary is offline.
4) Primary server is restored
5) Secondary clients can Renew as the secondary server never went away
6) Primary clients Renewing against the secondary server get ignored
7) Primary clients transition to Rebind, where the primary server then
answers them.  The clients then remember that the primary server answered
and will do future Renews to the primary.

This is only one cycle of failed RENEW -> REBIND.

Security considerations section is nice, but not sufficient. You also
> mention that by misconfiguring HBA, administrators can fail to service
> certain group of users and finding a pattern in such a group would be
> difficult. As a practical aspect, debugging off-by-1 issues would be
> tricky e.g. first server handles 1-127 and the second handles 128-255
> (who is serving bucket 0?). Some warning about it - that the sum of all
> Hash Bucket Assignments of all servers must cover the whole range -
> would be useful.
>

Are these security considerations, or just potential configuration errors?


> Another concern that security considerations is missing is
> misconfiguration between relays and servers. If you do load balancing on
> relays, then you should not do another one on servers. And if you do,
> you just increase you chances to make configuration error, because load
> balancing configuration on relays must match load balancing
> configuration on servers. It would be good to have some trade-offs
> discussed for LB done on servers vs on relays.
>

Again, are these security considerations, or just potential configuration
errors?

-- 
 *Andre Kostur*
Distinguished Software Architect & Engineer
*P:* 604-678-2864
*E:* [e-mail]
*Toll-Free:* 1-800-877-1856


*F:* 604-678-2864
*VoIP:* sip:[e-mail]

[image: Incognito Software Inc.] <http://www.incognito.com>

 <http://www.incognito.com/company/events>