Stuart Henderson <stu.li...@spacehopper.org> wrote: > On 2024-02-13, Samuel Jayden <samueljaydan1...@gmail.com> wrote: > > From the information provided in the link, it appears that CARP and VRRP > > protocols aren't inherently interoperable. > > They are different protocols - they *had* to be different because VRRP > was subject to patents. And if carp was changed now, it wouldn't be > interoperable with existing carp installations. > > > While Cisco may have attempted to address this by introducing a command > > like "disable-loop-detection carp" in its Nexus 1000V virtual router > > product, this solution unfortunately doesn't extend to standard router > > hardware, rendering it ineffective in many scenarios. > > That's not about interop beteeen carp and vrrp speakers, it's about > using carp (or vrrp or hsrp or similar) on a port attached to the > 'virtual switch'. See 'Information About Redundant Routing Protocols' on > https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus1000/sw/4_2_1_s_v_1_5_1/layer_2_switching/configuration/guide/n1000v_l2/n1000v_l2_7redundantroutingprot.html > > > Is it feasible to achieve CARP and VRRP interoperability through a > > user-space application? > > No. They are different protocols. For what you want to do, running VRRP > on the OpenBSD box might make some sense though. There are various > existing userland implementations of VRRP that might be able to run > on OpenBSD, probably with some work to port them - e.g. freevrrpd, > frr-vrrpd, vrrpd. Nothing already in the ports tree (if someone wanted > to try I'd suggest starting by looking at freevrrpd).
This was my experience: VRRP was the first patent-encumbered protocol squeezed through the IETF process. The backers of that change in process were employees and laywers at a few major companies, but also tightly integrated into the IETF approval process. When we objected to the VRRP situation, they circled the wagons, not just to defend the VRRP patent, but to protect a future of patent's being OK in IETF processes. In response, OpenBSD carefully developed a similar mechanism called CARP, and the acronymn actually expands to "Cisco Asshole Redundancy Protocol", because the main traitors inside IETF were Cisco employees. Then we asked IETF for numbers to make this a unique protocol. Unlike a recent threads where Tatu asked IETF for port 22 and they just gave it to him, the various number authorities inside IETF demanded that we follow the most stringent procedures for CARP. Even to this day, IETF provides the various prototol numbers to some large corporate industry members without forcing them down those stringent procedures. As a result, we simply squatted on the VRRP numbers. We gave them plenty of warning we would be doing this. Over the following years, we heard some real anger IETF decision makers internally, but none of them re-visited our request for seperate numbers. We never got numbers. So CARP will stay where it is. One major bug was in VRRP on some HP product was found in the first year. CARP packets were incorrectly parsed as VRRP packets. I don't remember the details, but I think it rebooted that HP device, probably a switch. Oh well.
