RE: rac network question

  • From: "Matthew Zito" <mzito@xxxxxxxxxxx>
  • To: <ganstadba@xxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 10 Jan 2008 17:07:31 -0500

Actually, just so's we're all clear, with the VLAN support that the
gentleman described originally, the interfaces will appear separate -
eth0.1 and eth0.2 (note: different than eth0:1 and eth0:2).  The traffic
will be shared, but as long as the bonding works as it should, it just
means that if a card is lost, both the interconnect and the VIP will
fail over to the other link.  IMHO, while this is suboptimal, it should
work fine.





From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Michael McMullen
Sent: Thursday, January 10, 2008 12:01 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: rac network question


That's what he's done, combined the both so public & private traffic is
combined. I'm assuming it's not supported and as such as this will be a
very high profile, critical database, he'll have to change.


-----Original Message-----
From: Dan Norris [mailto:dannorris@xxxxxxxxxxxxx] 
Sent: January 10, 2008 11:06 AM
To: ganstadba@xxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: Re: rac network question



I see a huge problem and very likely a support issue as well. Basically
what he's saying is that the host will have a *single* logical network
interface. That *single* interface will need to serve as the private and
public interface and that's where Oracle Support may have some major

If these blades only support 2 NICs (and you have no opportunities to
expand them), then I'd elect to leave the redundancy aside and take a
NIC failure as a whole node failure. Since the only other choice is to
combine public and private networks over a single logical interface,
removing redundancy so you have 2 separate logical/physical interfaces
would be a favorable choice. 

Other related posts: