Hi Burkhard,

Please provide the following additional information to help clarify the
uncertainty regarding the IPv4 address and the impact of the warning
message:

Could you please provide:

   1. The exact output of the "dump of configuration" you mentioned,
   specifically the section showing the public_network setting on the
   monitors and OSDs. This will help us understand the current configuration.
   2. Confirmation of whether you are experiencing any real problems beyond
   the warning message you are seeing regarding the public address and the
   subnet.
   Specifically, are you seeing any issues with:


   - OSD availability?
   - Network connectivity?
   - Data replication or recovery?
   - Client access to the Ceph cluster?

Understanding the actual impact, beyond just the warning, will help us
prioritize and address the issue effectively.

Please open a tracker if you believe this is a bug.

Regards,

Prashant


On Mon, Apr 14, 2025 at 4:08 AM Burkhard Linke <
burkhard.li...@computational.bio.uni-giessen.de> wrote:

> Hi,
>
> On 4/11/25 18:33, Stephan Hohn wrote:
> > Ok the two issues I see with reef release v18.2.5
> >
> > - Subnet check seems to be ipv4 only which leads to e.g "public address
> is
> > not in 'fd01:1:f00f:443::/64' subnet" warnings on ipv6 only clusters.
>
>
> I'm just updating to 18.2.5 and encountered the same problem in a
> IPv4-only cluster.
>
> One mon and one mgr are running on a machine in a different network, and
> it sets public_network locally in ceph.conf to its own ip range. All
> other hosts have a different values in ceph.conf. There was no value
> stored in the mon config database.
>
> The error popped up after the mgr debian package was updated (which for
> some probably undesired reason also restarts the service...). It refers
> to the ip range of the single extra machine. Setting a global value in
> ceph.conf did not solve the problem, so I disabled first the mon and
> then the mgr on the host. With the later step the error was gone. So I
> assume the either the mgr is assuming that all services are in its
> configured public_network, or the other mons took some time after
> disabling the mon to reconcile the problem.
>
> No containers involved, everything running on Debian 12, only public
> network for all services.
>
> I'll update the remaining services and afterwards run some tests on the
> single machine for further investigations.
>
>
> Best regards,
>
> Burkhard Linke
>
> _______________________________________________
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
>
>
_______________________________________________
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Reply via email to