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. Matt ________________________________ 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 Michael, 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 problems. 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.