RE: active-active for private IP?

From: Herring Dave - dherri <>
Date: Mon, 30 Nov 2009 17:58:14 -0600
Message-ID: <>

Folks, I'm looking for recommendations on bonded NIC pairs used for RAC private interconnects, in terms of their configuration - active-active vs. active-backup.  Take the switch out of the equation and assume that we can obtain the hardware and configure it properly for either configuration.  Does the issue just come down to the client deciding on throughput vs. stability and which they're willing to risk?  My (limited) understanding is that active-active will give you more throughput at the expense of potential outage.  If the switch side link fails, then potentially both interconnection connections will fail.

I'm getting internal responses saying Oracle recommends active-active for private interconnects, but they (the internal folks) don't provide any proof.  I've checked a bit and found references to configurations for Solaris, but my situation is with Linux RHEL 4.

I'm checking on this because in our existing environments we've got a mixture of both active-active and active-backup for the private interconnects.  I've come into the game late, so now I've got to support what we have and potentially make recommendations on any future changes.  I'd prefer to have a recommended method and use that for all configs, as I hate having inconsistencies and then be told that this inconsistency is a problem but no proof.  If I've got all configs the same and they follow documented recommendations, I've at least got a few things on my side to work with on future issues.


David C. Herring  | DBA, Acxiom Database Services

630-944-4762 office | 630-430-5988 cell | 630-944-4989 fax 1501 Opus Pl | Downers Grove, IL, 60515 | U.S.A. |

The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged.

If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.

If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system.

Thank You.

Received on Mon Nov 30 2009 - 17:58:14 CST

Original text of this message