A question about classic peer discovery combined with IPv6

[sergey-safarov]

Describe the bug

I have upgraded RabbitMQ from 3.13.7 to 4.1.0 and found rabbit_peer_discovery_classic_config does not works properly now.
In rabbitMq logs I can see

2025-05-18 14:44:20.146141+00:00 [info] <0.269.0> Starting worker pool 'worker_pool' with 2 processes in it
2025-05-18 14:44:20.146696+00:00 [info] <0.215.0> Running boot step rabbit_registry defined by app rabbit
2025-05-18 14:44:20.146922+00:00 [info] <0.215.0> Running boot step database defined by app rabbit
2025-05-18 14:44:20.147542+00:00 [info] <0.215.0> Peer discovery: configured backend: rabbit_peer_discovery_classic_config
2025-05-18 14:44:20.148821+00:00 [notice] <0.270.0> Feature flags: attempt to enable `rabbitmq_4.0.0`...
2025-05-18 14:44:20.157472+00:00 [notice] <0.270.0> Feature flags: `rabbitmq_4.0.0` enabled
2025-05-18 14:44:20.157535+00:00 [notice] <0.270.0> Feature flags: attempt to enable `detailed_queues_endpoint`...
2025-05-18 14:44:20.167591+00:00 [notice] <0.270.0> Feature flags: `detailed_queues_endpoint` enabled
2025-05-18 14:44:20.167646+00:00 [notice] <0.270.0> Feature flags: attempt to enable `rabbitmq_4.1.0`...
2025-05-18 14:44:20.178890+00:00 [notice] <0.270.0> Feature flags: `rabbitmq_4.1.0` enabled
2025-05-18 14:44:20.178943+00:00 [notice] <0.270.0> Feature flags: attempt to enable `quorum_queue_non_voters`...
2025-05-18 14:44:20.188063+00:00 [notice] <0.270.0> Feature flags: `quorum_queue_non_voters` enabled
2025-05-18 14:44:20.188120+00:00 [notice] <0.270.0> Feature flags: attempt to enable `message_containers_deaths_v2`...
2025-05-18 14:44:20.198357+00:00 [notice] <0.270.0> Feature flags: `message_containers_deaths_v2` enabled
2025-05-18 14:44:20.198412+00:00 [notice] <0.270.0> Feature flags: attempt to enable `rabbit_exchange_type_local_random`...
2025-05-18 14:44:20.207605+00:00 [notice] <0.270.0> Feature flags: `rabbit_exchange_type_local_random` enabled
2025-05-18 14:44:20.207764+00:00 [info] <0.215.0> DB: virgin node -> run peer discovery
=PROGRESS REPORT==== 18-May-2025::14:44:20.456828 ===
    supervisor: {local,inet_gethost_native_sup}
    started: [{pid,<0.94.0>},{mfa,{inet_gethost_native,init,[[]]}}]

=PROGRESS REPORT==== 18-May-2025::14:44:20.462226 ===
    supervisor: {local,kernel_safe_sup}
    started: [{pid,<0.93.0>},
              {id,inet_gethost_native_sup},
              {mfargs,{inet_gethost_native,start_link,[]}},
              {restart_type,temporary},
              {significant,false},
              {shutdown,1000},
              {child_type,worker}]

=PROGRESS REPORT==== 18-May-2025::14:44:32.740326 ===
    supervisor: {local,inet_gethost_native_sup}
    started: [{pid,<0.94.0>},{mfa,{inet_gethost_native,init,[[]]}}]

=PROGRESS REPORT==== 18-May-2025::14:44:32.745329 ===
    supervisor: {local,kernel_safe_sup}
    started: [{pid,<0.93.0>},
              {id,inet_gethost_native_sup},
              {mfargs,{inet_gethost_native,start_link,[]}},
              {restart_type,temporary},
              {significant,false},
              {shutdown,1000},
              {child_type,worker}]

When I have disabled node discovery then RabbitMQ started without error messages

We use IPv6-only network.
Afte checking DNS request and response looks all good. RabbitMQ issues AAAA request and receive responses.

we have configured /etc/rabbitmq/erl_inetrc

%% Tells DNS client on RabbitMQ nodes and CLI tools to resolve hostnames to IPv6 addresses.
%% The trailing dot is not optional.
{inet6,true}.

Reproduction steps

Need to configure two-node cluster with enabled rabbit_peer_discovery_classic_config.
Network should be IPv6 only.

Expected behavior

two RabbitMQ nodes will be joined into cluster without error messages in the logs

Additional context

No response

[sergey-safarov]

When I started one node, I could see an unexpected DNS request

14:56:30.204682 IP 127.0.0.1.49713 > 127.0.0.1.domain: 32885+ AAAA? rmq-0a. (24)
14:56:30.204782 IP 127.0.0.1.domain > 127.0.0.1.49713: 32885 NXDomain* 0/1/0 (99)
14:56:32.636061 IP 127.0.0.1.40020 > 127.0.0.1.domain: 8452+ AAAA? rmq-0a. (24)
14:56:32.636172 IP 127.0.0.1.domain > 127.0.0.1.40020: 8452 NXDomain* 0/1/0 (99)
14:56:32.902323 IP 127.0.0.1.50138 > 127.0.0.1.domain: 59822+ AAAA? rmq-0a. (24)
14:56:32.902472 IP 127.0.0.1.domain > 127.0.0.1.50138: 59822 NXDomain* 0/1/0 (99)

Looks like RabbitMQ does not use FQDNS.
We use Docker containers and have a defined environment variable

RABBITMQ_USE_LONGNAME=true

[michaelklishin]

@sergey-safarov you haven't provided any details, any configuration files, nor logs for us to work with. An ERL_INTERC file with one

There were no classic peer discovery changes (besides the new K8S plugin), so "peer discovery is broken" only for you.

You haven't provided any details for us to work with, you are not a paying user nor your are a contributor => you will have to figure things out on your own.

In addition, you did not seem to have read a dedicated documentation guide on using IPv6 for for inter-node communication.

[michaelklishin]

Finally, RABBITMQ_USE_LONGNAME instructs booting nodes to use fully qualified domain names but it has no control over the node names lsited in rabbitmq.conf to be used by the classic peer discovery mechanism.

All those names must use a fully qualified name, and we won't guess whether that's the case. We do not guess in this community.