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
_______________________________________________
ceph-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
