US patent 5473599

[ryanshea at google.com (Ryan Shea)]

Great news about the patent age.

Paul, sounds like this outage-causing catastrophe you mention could happen
to your competitors _if_ they happened to run vrrp and carp on the same
subnet _and_ happened to have a host identifier conflict - is that right? I
just wanted to clarify.

CARP has been a great solution for me in the past and is one of the
features of BSD I think is great (along with OpenNTPd, OpenBGPd - which
probably have similar standards non-compliance). Has anyone tried to use
the userspace VRRP implementation on Linux... I recall delicacy and
kludginess from the one time I used it - so again, CARP = rad.


On Tue, Apr 22, 2014 at 9:20 AM, Paul WALL <pauldotwall at gmail.com> wrote:

> On Tuesday, April 22, 2014, Henning Brauer <hb-nanog at bsws.de> wrote:
>
> > * Nick Hilliard <nick at foobar.org <javascript:;>> [2014-04-22 10:29]:
> > > ... turns 20 today.
> > >
> > > This is the patent which covers hsrp, vrrp, many applications of carp
> and
> > > some other vendor-specific standby protocols.
> >
> > it does NOT cover carp, not at all. carp was carefully designed to
> > specifically avoid that.
> >
> >
> CARP is a nonstandard protocol that was carefully designed to cause
> outages.
>
> Its authors submitted a slide deck describing their protocol instead of an
> internet-draft, which somehow managed to not get any traction in the IETF
> (funny that). The bar is pretty low for an informational RFC but the
> CARPheads couldn't be bothered. They threw a tantrum which involved camping
> out on the IETF's OUI (rather than getting their own) and deliberately
> choosing host bytes that conflict with the VRRP standard.  This has the
> same predictable result as any duplicate MAC address, but since odds are it
> conflicts with a router, takes out the entire subnet instead of a single
> host.  Of course this is not mentioned anywhere in CARP's documentation.
>
> That's why I encourage my competitors to run it.
>
> Drive slow,
> Paul
>