https://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol --- Cisco informed the OpenBSD <https://en.wikipedia.org/wiki/OpenBSD> developers that it would enforce its patent on HSRP. Cisco's position may have been due to their lawsuit with Alcatel. As Cisco's licensing terms prevented an open-source VRRP implementation, the OpenBSD developers began developing CARP instead. OpenBSD focuses on security. They designed CARP to use cryptography <https://en.wikipedia.org/wiki/Cryptography>. This made CARP fundamentally different from VRRP and ensured that CARP did not infringe on Cisco's patent. CARP became available in October 2003.[3] <https://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol#cite_note-3> Later, it was integrated into FreeBSD <https://en.wikipedia.org/wiki/FreeBSD> (first released in May 2005 with FreeBSD 5.4),[4] <https://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol#cite_note-4> NetBSD <https://en.wikipedia.org/wiki/NetBSD> and Linux <https://en.wikipedia.org/wiki/Linux> (ucarp).[1] <https://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol#cite_note-ucarp_manpage-1> While Cisco's US patent expired in 2014, the two incompatible protocols continue to coexist. daniel On Thu, Mar 19, 2026 at 8:12 PM Owen DeLong via NANOG <nanog@lists.nanog.org> wrote:
Disagree strongly here.
CARP is an abomination that should never have been inflicted on the world. CARP is an act of arrogance wherein the BSD developers went to the IETF and demanded a port allocation for a service that was largely duplicative of existing functionality provided by VRRP. They refused to go through the internet-draft process or work with the relevant working group(s) and instead ended up just overloading the port assignments for VRRP such that CARP becomes a huge PITA for any network engineer who encounters it on a network running or deploying VRRP.
The BSD team lost a lot of my previous respect when they did this. Yes, BSD routing is also a viable candidate, but CARP just shouldn’t be.
Owen
On Mar 19, 2026, at 11:07, Owen DeLong <owen@delong.com> wrote:
Yes, systemd-networkd is very capable (if arcane and unfriendly at times) for static configuration persistence. NetworkManager is more geared toward and indeed seems better for systems that are using lots of runtime dynamic configuration (DHCP, 802.1x, etc.) and also provides better desktop environment integration.
Agree to disagree here. The ability to control DHCP and 802.1x in systemd-networkd is far more mature and capable than NetworkManager. The one and only place where network manager shines is if you are traversing many different wireless networks with different but basic configurations and limited IPv6 concerns. (It’s great for a normal laptop user who can manage it entirely within the GUI).
I would never use it on anything doing any sort of routing or bridging. Not even like a mobile hotspot.
I mostly use systemd-networkd on my generic-Linux-distro-as-a-router and adjacent (local DHCP/DNS, for example) systems.
I’ve decided that it’s the best Swiss Army knife for my needs and rather than try to stay up on the idiosyncrasies of multiple packages, I try to just use it wherever I can.
YMMV.
Owen
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FHSFXQ44...