RE: RAC private network IP's - 169.254.x.x

From: D'Hooge Freek <Freek.DHooge_at_uptime.be>
Date: Fri, 6 Apr 2012 12:29:25 +0200
Message-ID: <4814386347E41145AAE79139EAA398981CBE5CD655_at_ws03-exch07.iconos.be>


Dimitre,

How can you assign a different vlan on network ports that are part of the same bond? I would think this would break your bonding, meaning you tested on a bond that has only 1 working network port to begin with.

The reason why you need to use separate subnets when using HAIP with multiple nics is the os routing. When you have multiple ip addresses in the same subnet on a server, it is the routing table which determines the interface to be used for outgoing traffic. If that interface fails, the routing table will not be changed and thus all communications break.

This is also the reason why one should not use ifdown to test network failures. It does things to cleanly, like removing the entry for that interface from the routing table.

Kind regards,  

Freek D'Hooge
Uptime
Oracle Database Administrator
email: freek.dhooge_at_uptime.be
tel +32(0)3 451 23 82
http://www.uptime.be
disclaimer: www.uptime.be/disclaimer

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Radoulov, Dimitre Sent: vrijdag 6 april 2012 12:05
To: goran bogdanovic
Cc: krishna.setwin_at_gmail.com; oracle-l Subject: Re: RAC private network IP's - 169.254.x.x

Thanks Goran!
One of our customers is using bonding for the private Interconnect (every node has 4 NICs - 2 in bond for the public and 2 for the private network, GI sees bond0 and bond1). Initially separate private vlans were used for the Interconnect and, during an HA test, disabling one of the NICs in bond on one of the nodes completely broke the communication. After that we configured all interfaces used
for the Interconnect in the same pvlan and after rebooting the nodes, all worked well.

This issue is of course different as the customer is using bonding and not GI's HAIP directly
for Interconnect redundancy.

Regards
Dimitre

On 06/04/2012 11:24, goran bogdanovic wrote:
> pay attention on
> *
> *
> *Bug 10389682: HAIP INTERCONNECT DOES NOT WORK IF IP ADDRESSES ARE IN
> THE SAME SUBNET*
>
> if you use more than one NIC for interconnect ...
>
> goran
>
>
>
> On Fri, Apr 6, 2012 at 10:10 AM, Radoulov, Dimitre
> <cichomitiko_at_gmail.com <mailto:cichomitiko_at_gmail.com>> wrote:
>
> Hi Krishna,
> as already stated, the 169.254.*.* is used by GI automatically:
>
> 11gR2 Grid Infrastructure Redundant Interconnect and
> ora.cluster_interconnect.haip [ID 1210883.1]
>
> Grid automatically picks free link local addresses from reserved
> 169.254.*.* subnet for HAIP. According to RFC-3927, link local subnet
> 169.254.*.* should not be used for any other purpose. With HAIP, by
> default, interconnect traffic will be load balanced across all active
> interconnect interfaces, and corresponding HAIP address will be failed
> over transparently to other adapters if one fails or becomes
> non-communicative. .
>
>
> Dimitre
>
>
> On 06/04/2012 09:57, D'Hooge Freek wrote:
> > I think the 169.254.0.0/16 <http://169.254.0.0/16> subnet is
> used for autoconfiguration ip addresses.
> > Which are addresses that are self assigned after verifying that
> no one else is using it by sending out an arp ping (for instance,
> in case when the dhcp server is not giving out an address).
> >
> > You should not use them when statistically assigning an ip address.
> >
> > Oracle is using ip addresses in this range for the private
> network as part of the high available ip address (HAIP)
> functionality (which is also the reason multicast's must be
> allowed between the different nodes).
> >
> [...]
> > Can we use 169.254.1.11& 169.254.1.12 as private IP's for RAC 2
> node
> > cluster?
> > (basically any 169.254.x.x )
> >
> > we just have 1 private NIC for each node.
> >
> > version: 11.2.0.3 rac
> > RHEL 5.8
> >
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l
Received on Fri Apr 06 2012 - 05:29:25 CDT

Original text of this message