Yes, exactly. The fail-back never worked. All SAs would disappear and subsequent failover to slave dropped SAs there too. There was a story behind this from the developer somewhere in the mail archives. A while back.
On Wednesday, December 13, 2023 at 05:55:50 p.m. GMT+9, Janne Johansson <icepic...@gmail.com> wrote: Den ons 13 dec. 2023 kl 04:15 skrev All <olp...@yahoo.ca>: > > >I'd like to add sasyncd in the mix and a 2nd router for higher > availability. > Don't do it. sasyncd is known not to work properly in failover scenarios. > When I ran it it did work fine for the first fail-over, but seldom (or perhaps never?) on fail-back when the master returned, so it was ok for giving me nice redundancy if the current carp master died, then I could choose a suitable time after fixing this node when to take a the hit of a new tunnel-setup as I flipped back. Never knew why it would only work one-way for me, but we had certain issues with broadcom bnx(4) cards and multicast at the time, so it could have been related to that. > >Will gre over carp work? > I think you can just try out in a vm. Don't see the reason why it would > not. > But perhaps there are some features that CARP interface doesn't support > for gre. > Do mind that carp on software-defined switch networks might need some settings in order to allow the virtual eth cards to send out frames with "bogus" mac-addresses, since some hypervisors keep good track of which macs they have given to a VM and drop ethernet frames sent with not-those mac-addresses as source. But to add to the original reply, I would probably go for two gre's towards the non-carp ips, since you are using ospf anyhow, you might just tell ospfd that one gre has a slightly higher cost than the other, and let it deal with the new network map when one of them fails. -- May the most significant bit of your life be positive.
