CARP is probably my most favorite innovation from OpenBSD. It is a direct competitor to the closed Cisco VRRP and I find it to be easier to use than Linux' Keepalived (I'm assuming this came out post-VRRP licensing?).
> This is a Cisco HSRP patent document with the word "Cisco" crossed out and the word "IETF" written in crayon.
That one got me.
When the first CARP release hit I immediately set it up on a pair of SUN Ultra1 pizza boxes I had gotten on eBay after the .com crash (with a third cold-spare) and ran that way for years. My ISP even called me at one point to find out what "those weird mac addresses" were on the SUN hardware.
They, of course, ended up being too power hungry and I moved to PC-Engines Alix boxes. When I wanted more horsepower as my internet speed increased, I moved first to a pair of PC-Engines APU boxes, and now to one APU and one virtualized OpenBSD firewall.
CARP has always been rock solid throughout, both on the internal and external interfaces of my firewalls. Rolling reboots for patches, updates, OS upgrades or hardware failures are a non-issue. No one in my family ever notices. Combine that with multi-homed ISPs and the internet at my house is more solid than a lot of enterprises and there's no expensive hardware or software involved.
I guess that was a long-winded way to say: Home consumers CAN benefit from high availability! It just isn't packaged in an easy to use or cheap enough form factor for them.
I used CARP for HAProxy in lab environments, but that is as 'close to home' as it got.
CARP is useful for any time you need to take a service down residing behind CARP. Updating an HAProxy box, for example. Failover/disable the node you'll be performing maintenance on, which is >0.1% of the year.
It's one of those problems that don't happen often enough for me to really spend time debugging, but is annoying nonetheless.
Long story short pay extra close attention when when mixing vrrp and carp on the same network segment.
https://queue.acm.org/detail.cfm?id=2090149
Key paragraph:
"The OpenBSD team, led as always by their Glorious Leader (their words, not mine), decided that a RAND license just wasn't free enough for them. They wrote their own protocol, which was completely incompatible with VRRP. Well, you say, that's not so bad; that's competition, and we all know that competition is good and brings better products, and it's the glorious triumph of Capitalism. But there is one last little nit to this story. The new protocol dubbed CARP (Common Address Redundancy Protocol) uses the exact same IP number as VRRP (112). Most people, and KV includes himself in this group, think this was a jerk move. "Why would they do this?" I hear you cry. Well, it turns out that they believe themselves to be in a war with the enemies of open source, as well as with those opposed to motherhood and apple pie. Stomping on the same protocol number was, in their minds, a strike against their enemies and all for the good. Of course, it makes operating devices with both protocols in the same network difficult, and it makes debugging the software that implements the protocol nearly impossible."
"As a final note of course, when we petitioned IANA, the IETF body regulating "official" internet protocol numbers, to give us numbers for CARP and pfsync our request was denied. Apparently we had failed to go through an official standards organization. Consequently we were forced to choose a protocol number which would not conflict with anything else of value, and decided to place CARP at IP protocol 112. We also placed pfsync at an open and unused number. We informed IANA of these decisions, but they declined to reply."
https://www.openbsd.org/lyrics.html#35
Obviously the correct thing to do is get numbers via IANA but what is the least wrong thing to do when your project is too small to do this. Camp on unused numbers? If your project is successful enough they will eventually be granted. Use whatever number matches the closest fit? Pick some screwball assignment that failed to gain any actual use?