Inconsistent IP source persistence on first two packets

Help!
1

Hi,
I’m using HAProxy 3.0.3 :

HAProxy version 3.0.3-95a607c 2024/07/11 - ``https://haproxy.org/
Status: long-term supported branch - will stop receiving fixes around Q2 2029.
Known bugs: ``http://www.haproxy.org/bugs/bugs-3.0.3.html
Running on: Linux 4.18.0-553.22.1.el8_10.x86_64 #1 SMP Wed Sep 11 18:02:00 EDT 2024 x86_64

I’m having a problem with one of my VIPs, which has source IP persistence configured.
Here is the configuration of my VIP :

peers Cluster_NET
log 127.0.0.1 local0
bind 10.12.12.3:4242 ssl crt cert.pem
server srv1 ssl verify none
server srv2 10.12.12.4:4242 ssl verify none
table TABLE-CLIENT type ip size 1m expire 1200s

frontend VIP-CLIENT
enabled
mode tcp
bind 10.125.70.32:443
no log
default_backend GR-CLIENT

backend GR-CLIENT
mode tcp
balance leastconn
stick on src table Cluster_NET/TABLE-CLIENT
server client-srv-1 10.125.1.9:443 weight 1 enabled track HC-CLIENT/client-srv-1
server client-srv-2 10.125.1.12:443 weight 1 enabled track HC-CLIENT/client-srv-2
server client-srv-3 10.125.1.14:443 weight 1 enabled track HC-CLIENT/client-srv-3
server client-srv-4 10.125.1.39:443 weight 1 enabled track HC-CLIENT/client-srv-4
server client-srv-5 10.125.1.163:443 weight 1 enabled track HC-CLIENT/client-srv-5
server client-srv-6 10.125.1.164:443 weight 1 enabled track HC-CLIENT/client-srv-6
source 0.0.0.0 interface ens161

Sometimes, if the first packets arrive within the same millisecond (or with 1ms delay), source IP persistence fails, and the packets are sent to different backend servers.
Here are the logs of the issue, filtered by accept_date

Dec 30 11:28:46 localhost haproxy[69229]: 10.50.101.54:58156 [30/Dec/2025:11:28:36.433] VIP-CLIENT GR-CLIENT/client-srv-5 1/1/9615 10578 – 986/24/23/3/0 0/0
Dec 30 11:28:39 localhost haproxy[69229]: 10.50.101.54:54722 [30/Dec/2025:11:28:36.434] VIP-CLIENT GR-CLIENT/client-srv-6 1/1/3324 91907 – 964/26/25/4/0 0/0
Dec 30 11:29:05 localhost haproxy[69229]: 10.50.101.54:49746 [30/Dec/2025:11:28:39.416] VIP-CLIENT GR-CLIENT/client-srv-6 1/1/26214 964337 – 997/24/23/8/0 0/0

I think it’s not a bug. From my understanding, packet 1 and packet 2 are received and processed while there is no entry in the stick-table so they are both sent to backend server by the leastconnection balance mode.

But this causes problems for the VIP clients, who receive 50X errors from the backend server.
I’ve identified other logs where the first packets arrive within the same millisecond but are correctly forwarded to the same backend server, so the “problem” isn’t consistent.

I’m struggling to determine the best way to handle this issue. Has anyone else encountered this problem or have any suggestions for a solution please ?

2

It does sound like a bug. At the very least if this is expected behavior we must document it, which I don’t believe it is.

With version 3.0.3 you have 430 confirmed and already fixed bugs.

I would suggest to upgrade to latest bugfix release of the 3.0 branch as per haproxy.org. If the issue is still there, please file a bug on github:

3

Thank you for your answer Lukas.

At first, I thought it wasn’t a bug but “expected behavior”, but after several tests sessions, I also think it’s a bug.

I’ll follow your advice and run my tests in version 3.3 and open a GitHub issue if I reproduce the problem. I’ll update the issue here as well, depending on the results of the tests in version 3.3.

4

I wouldn’t go with 3.3.X just yet, it’s a little fresh.

A LTS version with latest bugfix release like 3.2.10 or 3.0.14 would be ideal.