On Wed, Feb 21, 2024 at 5:06 PM Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:

Sorry, I'm also completely confused and lost right now.

How did you end up with `15672` port in the haproxy configuration? As
in the first output it was `15671`?
`15672` is indeed used for non-TLS traffic. However, you everywhere in
config do have TLS (SSL) enabled - both in haproxy checks and in
rabbitmq management config. So expected one would be 15671 when
rabbitmq_management_ssl: True

Also can you please clarify, what is "the latest version"? As starting
with 2023.2 (Bobcat) the haproxy should be using http-check syntax, so
instead of
option httpchk HEAD / HTTP/1.0\r\nUser-agent:\ osa-haproxy-healthcheck
it will be
option httpchk
http-check send hdr User-Agent "osa-haproxy-healthcheck" meth HEAD

ср, 21 февр. 2024 г. в 06:07, Gk Gk <ygk.kmr@gmail.com>:
>
> This is the config in the haproxy:
>
> backend rabbitmq_mgmt-back
> mode http
> balance leastconn
> stick-table type ipv6 size 256k expire 10s store http_err_rate(10s)
> http-request track-sc0 src
> http-request deny deny_status 429 if { sc_http_err_rate(0) gt 20 } !{ src 192.168.0.0/16 } !{ src 172.16.0.0/12 } !{ src 10.0.0.0/8 }
> option forwardfor
> option httpchk HEAD / HTTP/1.0\r\nUser-agent:\ osa-haproxy-healthcheck
>
>
> server rabbit_mq_container-962bf7ee 10.91.31.227:15672 check port 15672 inter 12000 rise 3 fall 3 ssl check-ssl verify none
> server rabbit_mq_container-d800c10f 10.91.32.111:15672 check port 15672 inter 12000 rise 3 fall 3 ssl check-ssl verify none
> server rabbit_mq_container-dc9fb45e 10.91.32.239:15672 check port 15672 inter 12000 rise 3 fall 3 ssl check-ssl verify none
>
> I dont see any TLS connection here as well:
>
> ----
> # Management plugin configuration
>
> management.ssl.ip = 10.90.31.206
> management.ssl.port = 15672
> management.ssl.certfile = /etc/rabbitmq/rabbitmq.pem
> management.ssl.keyfile = /etc/rabbitmq/rabbitmq.key
> management.ssl.honor_cipher_order = true
> management.ssl.honor_ecc_order = true
> management.ssl.client_renegotiation = false
> management.ssl.secure_renegotiate = true
> management.ssl.versions.1 = tlsv1.2
> management.ssl.ciphers.1 = ECDHE-ECDSA-AES256-GCM-SHA384
> management.ssl.ciphers.2 = ECDHE-RSA-AES256-GCM-SHA384
> management.ssl.ciphers.3 = ECDH-ECDSA-AES256-GCM-SHA384
> management.ssl.ciphers.4 = ECDH-RSA-AES256-GCM-SHA384
> management.ssl.ciphers.5 = DHE-RSA-AES256-GCM-SHA384
> management.ssl.ciphers.6 = DHE-DSS-AES256-GCM-SHA384
> management.ssl.ciphers.7 = ECDHE-ECDSA-AES128-GCM-SHA256
> management.ssl.ciphers.8 = ECDHE-RSA-AES128-GCM-SHA256
> management.ssl.ciphers.9 = ECDH-ECDSA-AES128-GCM-SHA256
> management.ssl.ciphers.10 = ECDH-RSA-AES128-GCM-SHA256
> management.ssl.ciphers.11 = DHE-RSA-AES128-GCM-SHA256
> management.ssl.ciphers.12 = DHE-DSS-AES128-GCM-SHA256
> management.ssl.verify = verify_none
> management.ssl.fail_if_no_peer_cert = false
>
> So how is the health check succeeding ?
>
> On Wed, Feb 21, 2024 at 10:33 AM Gk Gk <ygk.kmr@gmail.com> wrote:
>>
>> So, does this port 15671, is it not the same as TLS ? If so, why are we using it as backend for health check ? It is being generated by openstack-ansible automatically..
>>
>> On Wed, Feb 21, 2024 at 12:17 AM Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:
>>>
>>> Actually what I've spotted is that you're trying to do CURL through basic TCP, while HAProxy does check-ssl, which means there's likely a TLS connection with the backend. And also 15671 port is SSL port for RabbitMQ management.
>>> But I wouldn't expect "Connection refused" though - more an empty reply or some protocol mismatch...
>>>
>>> Also can you kindly clarify - 172.21.152.187 is IP/port of the backend or haproxy internal VIP? I assume the backend? What do you receive when you try to curl that haproxy frontend then?
>>>
>>>
>>> вт, 20 февр. 2024 г. в 19:31, Michael Johnson <johnsomor@gmail.com>:
>>>>
>>>> Hi there,
>>>>
>>>> From the configuration snippet, I see you have "inter 12000" (12 seconds between health checks), and "fall 3" configured. This means that HAProxy will not consider the backend member failed until after roughly 36 seconds. Because of that "fall 3" (which is also the default) configuration, HAProxy will consider the member "up", even though it may not be, during this 36 second window.
>>>>
>>>> Maybe this is the behavior you are observing?
>>>>
>>>> Michael
>>>>
>>>> On Tue, Feb 20, 2024 at 8:50 AM Gk Gk <ygk.kmr@gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> We have the latest version of openstack setup. The rabbitmq backend health check is getting successful even though the curl to its ssl url is failing as shown below:
>>>>>
>>>>> ----
>>>>>
>>>>> backend rabbitmq_mgmt-back
>>>>> mode http
>>>>> balance leastconn
>>>>> stick-table type ipv6 size 256k expire 10s store http_err_rate(10s)
>>>>> http-request track-sc0 src
>>>>> http-request deny deny_status 429 if { sc_http_err_rate(0) gt 20 } !{ src 192.168.0.0/16 } !{ src 172.16.0.0/12 } !{ src 10.0.0.0/8 }
>>>>> option forwardfor
>>>>> option httpchk HEAD / HTTP/1.0\r\nUser-agent:\ osa-haproxy-healthcheck
>>>>>
>>>>>
>>>>> server rabbit_mq_container-527affef <ip>:15671 check port 15671 inter 12000 rise 3 fall 3 ssl check-ssl verify none
>>>>> server rabbit_mq_container-68b39094 <IP>:15671 check port 15671 inter 12000 rise 3 fall 3 ssl check-ssl verify none
>>>>> server rabbit_mq_container-83661288 <IP>:15671 check port 15671 inter 12000 rise 3 fall 3 ssl check-ssl verify none
>>>>>
>>>>> ------
>>>>>
>>>>> But the ssl curl to its ip and port 15671 is failing:
>>>>>
>>>>> 1
>>>>> 2
>>>>> 3
>>>>> 4
>>>>> 5
>>>>> 6
>>>>> 7
>>>>>
>>>>> curl -vvv 172.21.152.187:15671
>>>>> * Trying 172.21.152.187:15671...
>>>>> * TCP_NODELAY set
>>>>> * connect to 172.21.152.187 port 15671 failed: Connection refused
>>>>> * Failed to connect to 172.21.152.187 port 15671: Connection refused
>>>>> * Closing connection 0
>>>>> curl: (7) Failed to connect to 172.21.152.187 port 15671: Connection refused
>>>>>
>>>>> How then, the haproxy is still able to detect it as green and status ok in the haproxy stats page ?