What are the limitations of ip_hash ?

[Grzegorz Nosek]

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