Bug #14385
closed
Unicast CARP VIPs do not communicate using IPv6 Link Local Addresses
Added by Jim Pingle over 1 year ago.
Updated over 1 year ago.
Affected Plus Version:
23.05
Description
Configuring an IPv6 CARP VIP with a link local sync peer address does not appear to function properly. I've tried with and without a scope added to the address and in either case it does not appear to communicate with the peer. I made sure both peers were using the LL address of the other peer, but both claim MASTER status. If I change the peer to a non-LL address it works immediately.
Users can use non-LL sync peer addresses as a workaround, even if the VIP itself is LL.
If this is expected or not a valid use case, if that is the case we can document it as such.
I think I see why this doesn't work. Mostly because I forgot to consider link-local addresses.
It doesn't look very hard to fix so I will, but we should document this limitation for 23.05.
- Status changed from New to Feedback
- Target version changed from 23.09 to 23.05.1
- % Done changed from 0 to 100
- Subject changed from Unicast CARP VIPs do not communicate using IPv6 Link Local Addresses to Unicast CARP VIPs do not communicate using IPv6 Link Local Addresses
I tested against the latest Plus DEVELOPMENT built.
The behavior is consistent with the explanation provided. It appears that the solution has not yet been implemented.
So the fix was already in 2.7 BETA, and was also cherry-picked to the plus-RELENG_23_05 branch in case of future point releases, but it wasn't in plus-devel-main for 23.09 snapshots.
It would have made it in the next time we did a merge from upstream, but I've now cherry-picked it so it'll be in tomorrow's snapshot build.
23.05.1 fixes the issue
tested on:
Version 23.05.1-RC (amd64)
built on Wed Jun 21 19:31:48 UTC 2023
FreeBSD 14.0-CURRENT
- Status changed from Feedback to Resolved
Confirmed fixed here as well. I can set an LL on the VIP peer and it communicates as expected and reflects the proper CARP status as the other VIPs do.
There is still a potential issue with the address it chooses when doing XMLRPC sync but that's covered by #14392.
Also available in: Atom
PDF