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?).
I see this when poking around on routers and such, but I always wonder if it is useful or common to see for consumers. Is this something that only ISPs will implement? Or is it closer to the acceptable self hosted solutions like running pihole? It seems only useful for like 0.1% of the year if something goes very wrong? I don't think I have understood it enough to know why I might even be interested in using it.
I'm an OG OpenBSD user (literal 386 firewall) so I've been using it at home since before CARP was released.
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.
High availability isn't 'useful' or 'common' to consumers [home equipment]; consumer-class ISP services would generally be incompatible with highly available routers (dual WAN/ISP on a single router is going to be more common).
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.
For what it's worth, I run into weird CARP issues every now and then with 7.1. Stuff like both machines thinking they're master, or a down machine not triggering failover in the secondary. Always seems to be worse with the multiprocessor kernel.
It's one of those problems that don't happen often enough for me to really spend time debugging, but is annoying nonetheless.
~5 years ago I decided to use keepalived as a simpler high availability. It's got a lot of weirdness that I've had to work through and around, largely related to services running on the nodes. In the end my conclusion was that it wasn't really simpler than corosync+pacemaker, so I'm switching back.
The openbsd project tried to get a protocol number for carp, IANA made it more difficult then the project was able to comply with. so they made an executive decision to use the vrrp protocol number as the least wrong option.
Long story short pay extra close attention when when mixing vrrp and carp on the same network segment.
"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."
It is hard to say, I am not involved in ether project. CARP was definitely created in response to perceived deficiencies(both technical and political) in VRRP. I agree it does sound like picked the same number out of not a little spite. However the openbsd project has this to say about picking the ipnumber.
"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."
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?
