Re: FreeVRRPd project status

From: Lars Erik Gullerud (lerik_at_nolink.net)
Date: 04/13/05

  • Next message: Claudio Jeker: "Re: FreeVRRPd project status" 
    Date: Wed, 13 Apr 2005 21:36:48 +0200 (CEST)
To: Claudio Jeker <cjeker@diehard.n-r-g.com>

    On Wed, 13 Apr 2005, Claudio Jeker wrote:

    > On Wed, Apr 13, 2005 at 05:14:52PM +0200, Lars Erik Gullerud wrote:
    >>
    >> ...and can't safely be deployed in a lot of datacenter scenarios where
    >> the providers gear is running VRRP, since the OpenBSD-folks didn't bother
    >> to read up on how the process of obtaining a protocol number works, and
    >> hence used the one assigned to VRRP after a half-baked attempt at getting
    >> one themselves. Hence making CARP pretty much useless for ISPs, no matter
    >> how good it may or may not be otherwise.
    >>
    >
    > This is not true. First of all the "OpenBSD-folks" asked IANA for protocol
    > numbers for CARP and pfsync but IANA denied it. The reason was that CARP

    Which is exactly what I said, they didn't bother to read how the process
    works and accordingly made a half-baked attempt only. You don't just fire
    off a mail to IANA and say "hi, can I get a protocol number", that's just
    not how things work, except in OpenBSD-land, obviously. :)

    > was not developped through an official standards organization.

    Which is balony, you do however need to take the PROCESS through
    the correct "organization" (i.e. the IETF and friends, although the
    protocol itself can be developed through my grandma's knitting club). So,
    I stand by my initial statement (but hey, I'm a network engineer at an
    ISP, not a BSD developer - yes, us people the OpenBSD guys don't like
    much because we like to point out the glaring problems in things like
    CARP and OpenBGPd). However, this is all very much beside the point, so
    further IETF/IANA-bashing or OpenBSD-bashing can be taken somewhere more
    appropriate than this list. (Feel free to flame me privately)

    My point is that this very unwise decision to reuse the VRRP protocol
    number, makes CARP mostly undeployable for ISP datacenter environments,
    and hence there is an obvious need for a working VRRP implementation, it
    doesn't help that CARP is now available in FreeBSD, because it is not a
    viable alternative in a lot of scenarios.

    /leg
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: Claudio Jeker: "Re: FreeVRRPd project status"

    Relevant Pages

    • Re: FreeVRRPd project status
      ... >>to read up on how the process of obtaining a protocol number works, ... Hence making CARP pretty much useless for ISPs, ...
      (freebsd-net)
    • Re: Load balancing for web servers
      ... "The master of the address sends out CARP advertisement messages via multicast using the CARP protocol on a regular basis, and the backup hosts listen for this advertisement. ... Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet! ...
      (freebsd-net)
    • Re: Spurious error from i[pf]_carp
      ... This is really the preferred way of dealing with mixed CARP and VRRP environments as the CARP packets might in turn irritate the VRRP routers, ... RELENG_6_2 at least) that because the protocol number is shared with VRRP that tcpdump tries to decode the CARP frames as VRRP frames and although the header/frame is very simple this does not provide a useful decoding of the CARP frame. ...
      (freebsd-net)
    • Re: FreeVRRPd project status
      ... >>CARP comes from OpenBSD, not NetBSD, and is already in FreeBSD. ... > the providers gear is running VRRP, ... First of all the "OpenBSD-folks" asked IANA for protocol ...
      (freebsd-net)