Epiphany!
I was conflating the stick table with peers - thinking it was required in order
to not lose a connection if one of the HAProxy servers failed.
As it turns out, I can't "stick on src" as the users in the client's data
center will all present with the identical NAT address to the HAProxy servers.
So I have to use the cookies.
I do find it weird that some machines would see the SRV cookie and some not.
If I delete the following lines, will my users lose their connection if one of
the HAProxy servers fail (the HAProxy servers are protected by DNS failover)?
stick-table type ip size 20k peers mypeers
stick on src
Or does the peers section mitigate that?
peers mypeers
# include hap_servers-haproxy declarations
peer ip-10-241-1-140 10.241.1.140:1024
peer ip-10-241-1-237 10.241.1.237:1024
-----Original Message-----
From: Cyril Bonté <cyril.bo...@free.fr>
Sent: Monday, July 23, 2018 3:31 PM
To: Norman Branitsky <norman.branit...@micropact.com>
Cc: haproxy <haproxy@formilux.org>
Subject: Re: Missing SRV cookie
Hi Norman,
Le 23/07/2018 à 18:36, Norman Branitsky a écrit :
> My client's environment had 3 HAProxy servers.
>
> Due to a routing issue, my client's users could only see the old
> HAProxy
> 1.5 server when connecting from their data center.
> They could not see the 2 new HAProxy 1.7 servers.
>
> The routing issue was resolved last week and they could now see the 2
> new HAProxy servers, as well the old server.
>
> They started getting quick disconnects from their Java application -
>
> the SEVERE error indicated that they had arrived at the wrong server
> and had no current session.
> [...]
> New HAProxy servers configuration:
>
> backend ssl_backend-vr
> balance roundrobin
> stick-table type ip size 20k peers mypeers
> stick on src
Here you are using stick tables for session persistence.
> [...]
> cookie SRV insert indirect nocache httponly secure
> server i-067c94ded1c8e212c 10.241.1.138:9001 check cookie
> i-067c94ded1c8e212c
> server i-07035eca525e56235 10.241.1.133:9001 check cookie
> i-07035eca525e56235
But here, you are using cookies for the same purpose.
> I realized that the cookie mechanism was different so I shut down the
> old HAProxy server and the problem appeared to be resolved.
>
> This morning that client is complaining that the problem has returned
> - disconnects resulting in the user being kicked out to the login screen.
>
> Checking with multiple browsers, I can see both the old JSESSIONID
> cookie (with the machine name appended) and the new SRV cookie.
>
> Checking with multiple browsers, my colleagues can *NOT* see the new
> SRV cookie from any browser in this office -
>
> but they can see the SRV cookie when browsing from a virtual PC in our
> Atlanta data center!
> Even more puzzling, though my client cannot see the SRV cookie (either
> in the F12 cookies sent list, or in the browser's cookies folder) he
> *never* experiences an unexpected disconnect.
>
> Suggestions, please?
You have to make a choice, either you use stick tables, either you use cookies,
but don't mix both otherwise you'll have the situation you are describing.
--
Cyril Bonté
