ng_one2many v.s. AFT (NIC Fault Tolerance/Fail Over/Redundancy Revisited) (fwd)

Brian A. Seklecki lavalamp at spiritual-machines.org
Wed Feb 15 18:03:49 PST 2006


---------- Forwarded message ----------
Date: Wed, 15 Feb 2006 20:11:49 -0500 (EST)
From: Brian A. Seklecki <lavalamp at spiritual-machines.org>
To: jks at clickcom.com, Jonathan Donaldson <donaldson at cisco.com>,
     Brian J. Creasy <bcreasy at collaborativefusion.com>
Cc: Chad Ziccardi <ziccardi at digitalfreaks.org>,
     Danny Howard <dannyman at toldme.com>, Brad Bendy <brad at shockwebhost.com>
Subject: Re: ng_one2many v.s. AFT (NIC Fault Tolerance/Fail Over/Redundancy
     Revisited) (fwd)

On Thu, 12 Jan 2006, Brian J. Creasy wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Brian A. Seklecki wrote:
> |
> | Johnathan's comments suggest that we may need to move to 6.x on the
> | production cluster.
> |
> | 6.x has been upgraded from a technology release to stable, and our goal
> | is stability.
> |
> | Brian:  What are you thoughts so far on the 6.x experience?
> 
> no complaints here.. though, i have it running only on my laptop and

....Okay.

  | <jonathan> As of Freebsd 6_0 (which is at RC1 now), the NG_ONE2MANY does
  | support the failure of a link which does not end up with 50% packet
  | loss. There is new code in the One2Many module that xmits a layer 2 "I'm
  | alive" broadcast out all links, as long as this is picked up on the
  | other links, then all interfaces are considered alive. If one of the
  | packets is not received, then after 2 x heartbeat duration that link is
  | considered "down". I have tested this in the 6.0 code and it works with
  | one caveat. When the server is brought up, both interfaces must be
  | connected and live, or for some reason, the failure algorithm never
  | seems to kick in. I saw exactly what you saw in 5.4 and newer with
  | regards to the 50% packet loss.</jonathan>

Jonathan:

I'm not sure where you got the info about this.  Accoring to the NG_ONE2MANY(4) 
page in CVS -rHEAD (-CURRENT):

"Currently, the valid settings for the xmitAlg field are 
NG_ONE2MANY_XMIT_ROUNDROBIN (default) or NG_ONE2MANY_XMIT_ALL.  The only valid 
setting for failAlg is NG_ONE2MANY_FAIL_MANUAL; this is also the default 
setting."

I have 6.1-BETA1 on a box right now and I've got my config setup for 
NG_ONE2MANY_XMIT_ROUNDROBIN + NG_ONE2MANY_FAIL_NOTIFY and I don't see any 
layer2 heartbeat related traffic (watching via tcpdump(8) on another machine in 
the same segment)

Can you share what you saw?

~lava

> |> mission critical environment).
> |> - Xmit-All causes twice as much load on to be placed on the switch
> |> /fabric and switch CPU.
> |>
> |
> | <jonathan> As of Freebsd 6_0 (which is at RC1 now), the NG_ONE2MANY does
> | support the failure of a link which does not end up with 50% packet
> | loss. There is new code in the One2Many module that xmits a layer 2 "I'm
> | alive" broadcast out all links, as long as this is picked up on the
> | other links, then all interfaces are considered alive. If one of the
> | packets is not received, then after 2 x heartbeat duration that link is
> | considered "down". I have tested this in the 6.0 code and it works with
> | one caveat. When the server is brought up, both interfaces must be
> | connected and live, or for some reason, the failure algorithm never
> | seems to kick in. I saw exactly what you saw in 5.4 and newer with
> | regards to the 50% packet loss.</jonathan>
> |
> |
> |> What ng_one2many needs is a "Active-Standy" XMIT algorithm (STP BOFH's
> |> will think BLOCKING/FORWARDING).  It could even be used on top of
> |> other NetGraph nodes like ng_fec or possibly (hopefully) ng_802.3ad >:}
> |>
> |
> 
> - --
> Brian J. Creasy
> Collaborative Fusion, Inc.
> 412.422.3463 x4020       bcreasy at collaborativefusion.com
> 
> pgp public key:
> ~  http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5F94E004
> 
> ****************************************************************
> IMPORTANT: This message contains confidential information
> and is intended only for the individual named. If the reader of
> this message is not an intended recipient (or the individual
> responsible for the delivery of this message to an intended
> recipient), please be advised that any re-use, dissemination,
> distribution or copying of this message is prohibited. Please
> notify the sender immediately by e-mail if you have received
> this e-mail by mistake and delete this e-mail from your system.
> E-mail transmission cannot be guaranteed to be secure or
> error-free as information could be intercepted, corrupted, lost,
> destroyed, arrive late or incomplete, or contain viruses. The
> sender therefore does not accept liability for any errors or
> omissions in the contents of this message, which arise as a
> result of e-mail transmission.
> ****************************************************************
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (FreeBSD)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFDxmXvDgwDm1+U4AQRAr3GAJ42+HcJFO595aZvljztWCkd+NWgvACeMQiu
> ILXLchBGR90TZTZHjn6DVCY=
> =68DY
> -----END PGP SIGNATURE-----


More information about the freebsd-questions mailing list