What are the limitations of ip_hash ?

[Mark Swanson]

Grzegorz Nosek wrote:
> On śro, gru 31, 2008 at 02:58:30 -0500, Mark Swanson wrote:
>> 1. IP 1.1.1.1 -> ip_hash -> server A
>> 2. IP 2.2.2.2 -> ip_hash -> server B
>> 3. IP 1.1.1.1 -> ip_hash -> server A
>>
>> so far so good. 1.1.1.1 always goes to server A just like the docs
>> state. Until ...
>>
>> 4. IP 1.1.1.1 -> ip_hash -> server B
>>
>> This should never happen if I understand ip_hash correctly, yet this it
>> seems to happen about 10% of the time (not useful to anyone needing
>> sticky sessions).
> 
> If I understand the source correctly, this happens when one of your
> backends is down (as determined by Nginx). The IP address is then
> rehashed and the connection retried until it succeeds or you run out of
> backends.
> 
>> Btw, modulo? If you have the source handy would you mind posting the
>> code for this? I was really hoping the class C address would be used as
>> a key into a hash table and the value was the previously used server ID.
> 
> The two functions starting from here:
> 
> http://emiller.info/lxr/http/source/http/modules/ngx_http_upstream_ip_hash_module.c#L92
> 
>> I was also really hoping this hash table would be preserved after
>> sending a HUP signal to nginx.
> 
> There's no hash table in ip_hash, there's a hash _function_ which maps
> incoming IP to a server id. It isn't remembered anywhere. But the
> backend up/down status and failure count is indeed reset upon SIGHUP
> (AFAIK).
> 
> Best regards,
>  Grzegorz Nosek
> 
> 
Ok, thank you for the info.