failover and load balancing

[pat]

Hi Experts,

   From RFC 3074 it is mentioned that for every computation it requires an
array lookup and a xor function and an array table is also given for mixed
table of 256 distinct values.

Is this array table random so that each time the clients receives response
from the different server ??
can anyone explain how this lookup is done and from the clients MAC address
can we arrive which server will be responsive for the clients request.

Regards
Pat

On Thu, Jun 25, 2009 at 11:13 PM, pat <patkumar82 at gmail.com> wrote:

> Hi,
>
>   As per my knowledge failover protocol uses MAC hashing using Pearson
> algorithm, for MAC 00:00:00:00:00:01 output of algorithm should be 110(6E)
> which is less than your split value (i assume your split is  defalut  128) ,
> hence Primary shall respond your DISCOVER with offer.
>
> Experts please confirm if iam wright or wrong.
>
> Regards
> Pat
>
>
>
>   On Thu, Jun 25, 2009 at 10:32 PM, loganathan Govindaraj <
> loganosc at gmail.com> wrote:
>
>>   Hi
>>
>>        We are testing failover and load balancing our setup is like this
>>
>>
>> Dhcp server primary-------------|
>>                                           |
>>                                           | -------------------
>> Router/Relay agent----------------- DHCP clients
>> Dhcp secondry -------------------|
>>
>>
>> The router/relay agent is configured to forward the broadcast to both the
>> servers.
>> When i send a client with a mac-address of 00:00:00:00:00:00:01 the router
>> forwards the packet to both primary and secondry.
>> On recipt of a discover the i get a offer from the primary server once and
>> in another instance the mac address is offered by the secondry .
>> I am not able to get how the hashing works. Can any one explain how the
>> hasing works
>>
>> Another behaviour which i would like to mention here . Some times we get
>> offers from both the servers as the discover is reaching the servers .As per
>> the protocol after hashing primary or secondry should send an update to the
>> peer and then provide an offer .The behaviour is contradicting
>>
>> Logan
>>
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090628/6d1cd93f/attachment.html>