Discussion:
[haproxy] HAProxy always send RST packet to real server in TCP handshakes
zhi
2016-12-10 03:35:07 UTC
Permalink
Hi, all.

I build a HAProxy environment with one real server in backend. Also, I use
TCP transparent feature in HAProxy by following [1]. My HAProxy configure
file shows like this:

global
daemon
user root
group root
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
stats socket
/var/lib/neutron/lbaas/v2/b2cc2363-b50d-4489-bde0-40dd94b7fc24/sock mode
0666 level user
maxconn 500000

defaults
log global
retries 3
option redispatch
timeout connect 5000
timeout client 50000
timeout server 50000

frontend fac1082d-ebbf-48fd-a471-d30935533114
option tcplog
maxconn 5000
bind 0.0.0.0:222 transparent
mode tcp

default_backend 39ca866e-cadd-4915-bf80-cfc4a43d4591

backend 39ca866e-cadd-4915-bf80-cfc4a43d4591
source 0.0.0.0 usesrc clientip
mode tcp
balance roundrobin
timeout check 5000
server 6bd4198e-baf5-4c28-84f9-db395ab8982b 192.168.0.175:111 weight 2
check inter 10s fall 3


Then I visit the HAProxy service and catch packets in HAProxy's interface.
I find so many RST packets like this:

[image: 内嵌囟片 1]

192.168.0.186 is HAProxy service and 192.168.0.175 is real server.

In TCP three handshakes,
handshake 1: 192.168.0.186 -> 192.168.0.175 [syn]
handshake 2: 192.168.0.175 -> 192.168.0.186 [syn, ack]
handshake 3: 192.168.0.186 -> 192.168.0.175 [rst, ack]

Then HAProxy service try to connect real server again like this:
handshake 1: 192.168.0.186 -> 192.168.0.175 [syn]
handshake 2: 192.168.0.175 -> 192.168.0.186 [syn, ack]
handshake 3: 192.168.0.186 -> 192.168.0.175 [rst, ack]


again and again...


My question is, why HAProxy service send real server a rst packet in
handshake3?
Which scenario will happen this?


Hope for your reply ;-)

Thanks
Zhi Chang


[1]: https://www.kernel.org/doc/Documentation/networking/tproxy.txt
Willy Tarreau
2016-12-10 09:42:49 UTC
Permalink
Hi Zhi,
Post by zhi
backend 39ca866e-cadd-4915-bf80-cfc4a43d4591
source 0.0.0.0 usesrc clientip
mode tcp
balance roundrobin
timeout check 5000
server 6bd4198e-baf5-4c28-84f9-db395ab8982b 192.168.0.175:111 weight 2 check inter 10s fall 3
Then I visit the HAProxy service and catch packets in HAProxy's interface.
[image: ???????????? 1]
192.168.0.186 is HAProxy service and 192.168.0.175 is real server.
In TCP three handshakes,
handshake 1: 192.168.0.186 -> 192.168.0.175 [syn]
handshake 2: 192.168.0.175 -> 192.168.0.186 [syn, ack]
handshake 3: 192.168.0.186 -> 192.168.0.175 [rst, ack]
handshake 1: 192.168.0.186 -> 192.168.0.175 [syn]
handshake 2: 192.168.0.175 -> 192.168.0.186 [syn, ack]
handshake 3: 192.168.0.186 -> 192.168.0.175 [rst, ack]
These are TCP health checks performed by you "check" directive on
the server line. The purpose is to check if the port is opened. We
take care of closing with an RST so as not to wake up the application
then close and pollute its logs with protocol errors.

When you know the application protocol you can instead use an
application level check, but here it seems you're sending to a
portmapper and there's no such health check.

You don't have to worry about this, this is a totally normal behaviour.

Cheers,
Willy

Loading...