Martin, in case this is still an issue (apparently it is april already...): I am assuming here you have your /32 on lo and run IS-IS/openfabric/eBGP unnumbered on your eth[0-9]. In this case, i faced a similar issue a while back and, while i was not able to identify the actual root cause, my gut feeling told me that ceph would simply look which interface the default route would point to, and then take that interface's IP address. Which might be entirely wrong in setups like these... You might want to try putting the same /32 (same for /128 v6 if applicable) on both lo and your eth[0-9]. This probably feels entirely wrong (it does to me!), but i was successful in resolving this exact issue in this way. I came to think about this solution, as i vaguely remember the proxmox folks documenting a full-mesh / routed setup where the same IP + /24 (in their example) mask would be put on multiple interfaces at the same time. This might have had the same idea in mind, but i cannot find it anymore (and, just in case, shame on me, not them..). Be careful however, if you do eBGP unnumbered, your next-hops might get signalled w/ LLA + GLA as a result. This is what happened to me with PVE 9.1.5 (FRR 10.4.1) talking towards JunOS. JunOS would then erronuously pick the GLA as next-hop, resulting in the entire route becoming invalid. My interim fix is to set the next-hop to the peer address in the import policy, and carefully avoiding 24.4R1-S3 on MX (this release lets you set the next-hop to the LLA, but then still deems the next-hop to be unusable. Have not found a matching PR yet, but it works in e.g. 24.4R2-S2 and -S3). Cheers & happy Easter! Gregor P.S. (Configuring the same IP/32 on lo and eth[0-9] also helps with systemd-networksomething to behave more nicely, because it doesn't feel obligated to wait for connectivity on the eth interfaces _based on its weird (default) understanding of connectivity_. Can be fine-tuned with systemd-networkd options...) On 13.03.26 19:43, Martin Gerhard Loschwitz via ceph-users wrote:

Folks,

I have a setup here where a server has a single /32 IP from 10.1.0.0/16. It has a perfectly normal IP address and is reachable from within the local network thanks to EVPN. cephadm however only detects nonsense:

{ "fe80::/64": { "data1": [ "fe80::425b:7fff:fec8:c956" ], "loopback0": [ "fe80::1c54:fbff:fe6a:51e7" ] } }

How can I set the networks the machine has manually so that it becomes usable for MON placement? At this time, ceph-mgr does not deploy additional MONs, for instance, because it claims that the host network does not match the public network, while I assume the host network is directly read from the „cephadm list-networks“ output.

Thank you very much in advance Martin