Clusterware 和 RAC 中的域名解析的配置校验和检查 (文档 ID 1945838.1)

适用于:

Oracle Database - Enterprise Edition - 版本 10.1.0.2 到 12.1.0.1 [发行版 10.1 到 12.1]
Oracle Database - Standard Edition - 版本 11.2.0.4 到 11.2.0.4 [发行版 11.2]
Generic Linux
Generic UNIX

用途

Cluster Verification Utility（简称 CVU，命令式 runcluvfy.sh 或者 cluvfy）是个非常实用的检查网络和域名解析的工具，但是它也可能无法捕获到所有的问题。如果网络和域名解析在安装之前没有正常的配置，通常直接导致安装的失败。如果网络或者域名解析出现故障，通常会导致 clusterware 或者 RAC 会出现错误。本文的目的在于列出一些和网络以及域名相关的检查项目来检验网络和域名解析对 Grid Infrastructure（clusterware）和 RAC 的配置是否是正确的。

适用范围

本文提供给 Oracle Clusterware/RAC 数据库管理员和 Oracle 的技术支持工程师参考。

详细信息

A. 必要条件

无论是公网或者私网，通过 network ping 的方式通过网卡传输 MTU 大小的数据包能够正常工作。并且ping的时间非常短。

IP 地址 127.0.0.1 需要映射到 localhost 或者 localhost.localdomain 上。

不要把任何网卡的地址配置成 127.*.*.*。

公网网卡的名称在所有节点上都必须是相同的。

私网网卡的名称在 11gR2 的版本上，推荐使用相同的，在 11.2 之前的版本必须是相同的。

无论是公网还是私网，都不能使用本地的子网（169.254.*.*），公网和私网应该分布在不同的子网中。

MTU 的设置在所有的节点的网络配置中都应该是相同的。

Network size 的配置在所有的节点的网络配置中也都应该是相同的。

由于私有网络连接的实效性，traceroute 需要能够在网卡的 MTU 设置上没有碎片的传输或者在所有节点的路由表中通过一“跳”完成。

私网之间的防火墙必须是关闭的状态。

对于 10.1 到 11.1 的版本，域名解析需要对公共名称（public name），私有名称（private name），虚拟名称（virtual name）都生效。

对于 11.2 的版本，如果没有 Grid Naming Service (简称 NS)，域名解析需要对公共名称（public name），私有名称（private name），虚拟名称（virtual name），SCAN 名称都生效。而且如果 SCAN 是通过 DNS 配置的，那么 scan name 就不能包含在本地的 host 文件中。

对于 11.2.0.2 以及以上的版本，多播群 230.0.1.0 需要能够在私网的网络配置中工作；如果打了补丁 9974223 230.0.1.0 和 224.0.0.251 是都支持的。如果打了补丁 10411721 （问题在 11.2.0.3 的版本上做了修复），广播会被支持。详细请参考 Multicast/Broadcast 的验证部分。

对于 11.2.0.1 到 11.2.0.3 的版本，安装的过程中，如果您没有配置正确 pubic IP, node VIP, and SCAN VIP ，OUI 安装的过程中会提示 warning。这个 bug9574976 在版本 11.2.0.4 中做了修复，warning 的信息将不再提示。

11.2.0.2 之前，Oracle 推荐您使用 OS 级别的网卡绑定功能，根据操作系统平台的不同，您可以能布置不同的绑定方式，如：Etherchannel, IPMP, MultiPrivNIC 等等，您需要咨询 OS 的管理员来做网卡的绑定功能。从 11.2.0.2 之后，私网冗余和 HAIP 被引入来支持本地的多个私网网卡的冗余功能，详细信息，请查看考文档 note 1210883.1。
 
如果您的网络中启用了 jumbo frames，您也可以通过命令来进行检查，关于 jumbo frames 的详细信息，请参考文档 note 341788.1。

B. 正常配置的案例

以下例子中是验证网络配置的过程中我们期望看到的正常的结果。由于 11.2 和 11.1 之前的版本，在网络配置上稍有不同，我们这里提供了两个例子。11gR1 中或以下 11gR2 中之间的区别是 11gR1 中，我们需要公共的名称，VIP 的名称，私有的名称，我们依赖于私有的名称来找出集群的私网的 IP 地址。从 11.2 开始我们将不再依赖于私网，当集群启动时私网的配置将建立在 GPNP profile 上。假设我们有一个 3 个节点的集群，我们看到的信息是如下显示：

11gR1 or below cluster:

Nodename |Public IP |VIP name |VIP        |Private |private IP1 |private IP2           

         |NIC/MTU   |         |           |Name1   |NIC/MTU     |

---------|----------|---------|-----------|--------|----------------------

rac1     |120.0.0.1 |rac1v    |120.0.0.11 |rac1p   |10.0.0.1    |

         |eth0/1500 |         |           |        |eth1/1500   |

---------|----------|---------|-----------|--------|----------------------

rac2     |120.0.0.2 |rac2v    |120.0.0.12 |rac2p   |10.0.0.2    |

         |eth0/1500 |         |           |        |eth1/1500   |

---------|----------|---------|-----------|--------|----------------------

rac3     |120.0.0.3 |rac3v    |120.0.0.13 |rac3p   |10.0.0.3    |

         |eth0/1500 |         |           |        |eth1/1500   |

---------|----------|---------|-----------|--------|----------------------

11gR2 cluster

Nodename |Public IP |VIP name |VIP        |private IP1 |           

         |NIC/MTU   |         |           |NIC/MTU     |

---------|----------|---------|-----------|------------|----------

rac1     |120.0.0.1 |rac1v    |120.0.0.11 |10.0.0.1    | 

         |eth0/1500 |         |           |eth1/1500   |

---------|----------|---------|-----------|------------|----------

rac2     |120.0.0.2 |rac2v    |120.0.0.12 |10.0.0.2    |

         |eth0/1500 |         |           |eth1/1500   |

---------|----------|---------|-----------|------------|----------

rac3     |120.0.0.3 |rac3v    |120.0.0.13 |10.0.0.3    |

         |eth0/1500 |         |           |eth1/1500   |

---------|----------|---------|-----------|------------|----------

SCAN name |SCAN IP1   |SCAN IP2   |SCAN IP3   

----------|-----------|-----------|--------------------

scancl1   |120.0.0.21 |120.0.0.22 |120.0.0.23 

----------|-----------|-----------|--------------------

以下是每个节点上都应该验证的，我们给出的例子是 Linux 平台的示例：

1. 找到 MTU 设置：
/bin/netstat -in
Kernel Interface table
Iface       MTU Met    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0       1500   0   203273      0      0      0     2727      0      0      0 BMRU

# 以上示例中 MTU 的设置是 eth0 设置的是 1500

2. 找到 IP 地址和子网，比对所有节点上的 broadcast 和 netmask 的信息：
/sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:16:3E:11:11:11
          inet addr:120.0.0.1  Bcast:120.0.0.127  Mask:255.255.255.128
          inet6 addr: fe80::216:3eff:fe11:1111/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:203245 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2681 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:63889908 (60.9 MiB)  TX bytes:319837 (312.3 KiB)
..

在以上示例中，eth0 的 IP 地址配置是 120.0.0.1，broadcast 是 120.0.0.127，子网掩码是 255.255.255.128，它的子网是 120.0.0.0，这里最多可以配置 126 个 IP 地址。更多详细信息，请参考“子网的基础信息”部分。

注意：每一个被激活的网卡必须具备“UP”和“RUNNING”的标识。在Solaris平台，"PHYSRUNNING"表示物理网卡是否运行。

3. 通过运行两次 ping 的命令来确保和以下结果是一致的：

以下是 ping 的例子（从节点 1 public name 到节点 2 的 public name）。

PING rac2 (120.0.0.2) from 120.0.0.1 : 1500(1528) bytes of data.
1508 bytes from rac1 (120.0.0.2): icmp_seq=1 ttl=64 time=0.742 ms
1508 bytes from rac1 (120.0.0.2): icmp_seq=2 ttl=64 time=0.415 ms

--- rac2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.415/0.578/0.742/0.165 ms

请注意丢包和时间。如何丢包不是0%，或者不是sub-second，那说明网络有问题，请联系网络管理员检查。

3.1 在本地通过 public 的 ip 地址，来 ping 所有节点的 public node names，同时使用 MTU 大小的包，来确保网络的连通性。
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 rac1
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 rac1
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 rac2
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 rac2
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 rac3
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 rac3

3.2.1 通过本地的私网 IP 地址，使用 MTU 大小的包，检查所有节点的私网连通性
# 适合 11gR2 的案例，私网名称是可选的
/bin/ping -s <MTU> -c 2 -I 10.0.0.1  10.0.0.1
/bin/ping -s <MTU> -c 2 -I 10.0.0.1  10.0.0.1
/bin/ping -s <MTU> -c 2 -I 10.0.0.1  10.0.0.2
/bin/ping -s <MTU> -c 2 -I 10.0.0.1  10.0.0.2
/bin/ping -s <MTU> -c 2 -I 10.0.0.1  10.0.0.3
/bin/ping -s <MTU> -c 2 -I 10.0.0.1  10.0.0.3

3.2.2 通过本地的私网名称，使用 MTU 大小的包，检查所有节点的私网IP的连通性
# 适用于 11gR1 和之前的版本。
/bin/ping -s <MTU> -c 2 -I 10.0.0.1  rac1p
/bin/ping -s <MTU> -c 2 -I 10.0.0.1  rac1p
/bin/ping -s <MTU> -c 2 -I 10.0.0.1  rac2p
/bin/ping -s <MTU> -c 2 -I 10.0.0.1  rac2p
/bin/ping -s <MTU> -c 2 -I 10.0.0.1  rac3p
/bin/ping -s <MTU> -c 2 -I 10.0.0.1  rac3p

4. Traceroute 私有网络

以下例子，演示了通过 traceroute 从节点 1 的私网 IP 到节点 2 的私有名称的过程。

# MTU包大小 - 在Linux平台 包长度需要减去28字节，否则出错：Message too long is reported.
# 例如，MTU值是1500，那么我们应该使用1472：

traceroute to rac2p (10.0.0.2), 30 hops max, 1472 byte packets
 1  rac2p (10.0.0.2)  0.626 ms  0.567 ms  0.529 ms

MTU 大小的包，通过1跳完成，没有透过路由表，输出中没有出现故障信息，如："*" or "!H" 的存在表示有故障。

注意：traceroute 中的选项”-F” 在RHEL3/4 OEL4 的版本上由于 OS 的 bug 是不支持的，详细信息，请参考 note: 752844.1 。

4.1 通过本地的私网 IP 地址，traceroute 所有节点的私网 IP 地址
# 11gR2 版本及更高版
/bin/traceroute -s 10.0.0.1  -r -F 10.0.0.1  <MTU-28>
/bin/traceroute -s 10.0.0.1  -r -F 10.0.0.2  <MTU-28>
/bin/traceroute -s 10.0.0.1  -r -F 10.0.0.3  <MTU-28>

如果 "-F" 选项不能工作，那么不使用"-F" 选项，但是包大小设置为3倍MTU值

/bin/traceroute -s 10.0.0.1  -r  10.0.0.1  <3 x MTU>

4.2 通过本地的私网 IP 地址，traceroute 所有节点的私网 IP 地址
# 11gR1 和之前的版本
/bin/traceroute -s 10.0.0.1 -r -F rac1p <MTU-28>
/bin/traceroute -s 10.0.0.1 -r -F rac2p <MTU-28>
/bin/traceroute -s 10.0.0.1 -r -F rac3p <MTU-28>

5. Ping VIP hostname
# Ping 所有 VIP nodename 确保可以解析成正确而的 ip 地址。
# 在 clusterware 之前，ping 的命令需要可以解析所有的 VIP 的节点名字，但是 vip 的地址会失败，因为 vip 是由 clusterware 来管理的。
# Clusterware 启动之后，ping 的命令应该会成功：
/bin/ping -c 2 rac1v
/bin/ping -c 2 rac1v
/bin/ping -c 2 rac2v
/bin/ping -c 2 rac2v
/bin/ping -c 2 rac3v
/bin/ping -c 2 rac3v

6. Ping SCAN name
# 1gR2 版本
# Ping SCAN name 应该可以解析到正确的 IP 地址
# 和 VIP 一样，当在 clusterware 安装之前，ping 的命令仅仅能够解析出来 SCAN name，但是会失败。但是当 clusterware 启动后，ping 的命令式能够正常解析并运行的：
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 scancl1
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 scancl1
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 scancl1

7. Nslookup VIP hostname 和 SCAN name
# 11gR2 版本：
# 检查 VIP 的 nodename 和 SCAN name 是否正常的在 DNS 中进行了配置。
/usr/bin/nslookup rac1v
/usr/bin/nslookup rac2v
/usr/bin/nslookup rac3v
/usr/bin/nslookup scancl1

8. 检查域名解析的顺序：
# Linux，Solaris 和 HP-UX，请检查 /etc/nsswitch.conf，Aix，请检查 /etc/netsvc.conf
/bin/grep ^hosts /etc/nsswitch.conf
hosts:      dns files

9. 检查本地的 host 文件配置
# 如果本地的域名解析是配置在交换机上（nsswitch.conf），请确保解析文件中没有任何笔误或者错误的配置信息，通过 grep 检查所有的 hostname 和 IP 地址。
# 127.0.0.1 的地址不能对应到 SCAN，public，private 或者是 VIP 的名称中。

/bin/grep rac1       /etc/hosts
/bin/grep rac2       /etc/hosts
/bin/grep rac3       /etc/hosts
/bin/grep rac1v      /etc/hosts
/bin/grep rac2v      /etc/hosts
/bin/grep rac3v      /etc/hosts
/bin/grep 120.0.0.1  /etc/hosts
/bin/grep 120.0.0.2  /etc/hosts
/bin/grep 120.0.0.3  /etc/hosts
/bin/grep 120.0.0.11 /etc/hosts
/bin/grep 120.0.0.12 /etc/hosts
/bin/grep 120.0.0.13 /etc/hosts

# 11gR2 版本例子
/bin/grep 10.0.0.1   /etc/hosts
/bin/grep 10.0.0.2   /etc/hosts
/bin/grep 10.0.0.3   /etc/hosts
/bin/grep 10.0.0.11  /etc/hosts
/bin/grep 10.0.0.12  /etc/hosts
/bin/grep 10.0.0.13  /etc/hosts

# 11gR1 和之前的版本例子：
/bin/grep rac1p      /etc/hosts
/bin/grep rac2p      /etc/hosts
/bin/grep rac3p      /etc/hosts
/bin/grep 10.0.0.1   /etc/hosts
/bin/grep 10.0.0.2   /etc/hosts
/bin/grep 10.0.0.3   /etc/hosts

# 11gR2 版本的例子
# 如果 SCAN 名称是通过 DNS 解析的，那么他们不能出现在本地的 host 文件中。
/bin/grep scancl1      /etc/hosts
/bin/grep 120.0.0.21 /etc/hosts
/bin/grep 120.0.0.22 /etc/hosts
/bin/grep 120.0.0.23 /etc/hosts

C. 语法介绍

对于不同的平台上，由于语法的不同，这里给出一些示例：

Linux:            
    /bin/netstat -in
    /sbin/ifconfig
    /bin/ping -s <MTU> -c 2 -I source_IP nodename
    /bin/traceroute -s source_IP -r -F  nodename-priv <MTU-28>
    /usr/bin/nslookup

Solaris:        
    /bin/netstat -in
    /usr/sbin/ifconfig -a
    /usr/sbin/ping -i source_IP -s nodename <MTU> 2 
    /usr/sbin/traceroute -s source_IP -r -F nodename-priv <MTU>
    /usr/sbin/nslookup

HP-UX:            
    /usr/bin/netstat -in
    /usr/sbin/ifconfig NIC
    /usr/sbin/ping -i source_IP nodename <MTU> -n 2
    /usr/contrib/bin/traceroute -s source_IP -r -F nodename-priv <MTU>
    /bin/nslookup
    
  AIX:                
    /bin/netstat -in 
    /usr/sbin/ifconfig -a
    /usr/sbin/ping -S source_IP -s <MTU> -c 2 nodename
    /bin/traceroute -s source_IP -r nodename-priv <MTU>
    /bin/nslookup 
 
  Windows:     
    MTU:  
      Windows XP:          netsh interface ip show interface
      Windows Vista/7:    netsh interface ipv4 show subinterfaces
    ipconfig /all 
    ping -n 2 -l <MTU-28> -f nodename
    tracert
    nslookup

D. 多播（Multicast）

从版本 11.2.0.2 开始，在引导启动的过程中，多播组 230.0.1.0 需要能够正常工作。patch 9974223 中介绍了关于另外一个支持的多播组 224.0.0.251。

参考 note 1212703.1 来检查多播是否正常工作。

由于 11.2.0.3 的版本中包含了 bug 10411721 的修复，在启动的过程中会尝试 230.0.1.0 和 224.0.0.251 中的任何一个组进行多播传输，如果任何一个是成功的，GI 就能够正常启动。

在 HP-ux 的平台上，如果使用 10GB 的网卡作为私网网卡，如果没有 B.11.31.1011 版本以上的驱动或者 10GigEthr-02 版本或以上的 software bundle，多播可能无法正常工作。请运行
"swlist 10GigEthr-02"命令来检查当前的驱动版本。

E. 运行过程中的网络问题

OSWatcher 或者 Cluster Health Monitor(IPD/OS) 可以用来捕获运行过程中出现的网络问题。

F. 网络故障的现象

ping 地址无法正常工作

traceroute 无法正常工作

域名解析也无法正常工作。

1 racnode1 (192.168.30.2) 0.223 ms !X 0.201 ms !X 0.193 ms !X

2010-11-21 13:00:44.455: [ GIPCNET][1252870464]gipcmodNetworkProcessConnect: [network] failed connect attempt endp 0xc7c5590 [0000000000000356] { gipcEndpoint : localAddr 'gipc://racnode3:08b1-c475-a88e-8387#10.10.10.23#27573', remoteAddr 'gipc://racnode2:nm_rac-cluster#192.168.0.22#26869', numPend 0, numReady 1, numDone 0, numDead 0, numTransfer 0, objFlags 0x0, pidPeer 0, flags 0x80612, usrFlags 0x0 }, req 0xc7c5310 [000000000000035f] { gipcConnectRequest : addr 'gipc://racnode2:nm_rac-cluster#192.168.0.22#26869', parentEn
2010-11-21 13:00:44.455: [ GIPCNET][1252870464]gipcmodNetworkProcessConnect: slos op : sgipcnTcpConnect
2010-11-21 13:00:44.455: [ GIPCNET][1252870464]gipcmodNetworkProcessConnect: slos dep : No route to host (113)

2010-11-29 10:52:38.603: [GIPCHALO][2314] gipchaLowerProcessNode: no valid interfaces found to node for 2614824036 ms, node 111ea99b0 { host 'aixprimusrefdb1', haName '1e0b-174e-37bc-a515', srcLuid 2612fa8e-3db4fcb7, dstLuid 00000000-00000000 numInf 0, contigSeq 0, lastAck 0, lastValidAck 0, sendSeq [55 : 55], createTime 2614768983, flags 0x4 }
2010-11-29 10:52:42.299: [ CRSMAIN][515] Policy Engine is not initialized yet!
2010-11-29 10:52:43.554: [ OCRMAS][3342]proath_connect_master:1: could not yet connect to master retval1 = 203, retval2 = 203
2010-11-29 10:52:43.554: [ OCRMAS][3342]th_master:110': Could not yet connect to new master [1]

2010-11-04 12:33:22.133: [ GIPCNET][2314] gipcmodNetworkProcessSend: slos op :  sgipcnUdpSend
2010-11-04 12:33:22.133: [ GIPCNET][2314] gipcmodNetworkProcessSend: slos dep :  Message too long (59)
2010-11-04 12:33:22.133: [ GIPCNET][2314] gipcmodNetworkProcessSend: slos loc :  sendto
2010-11-04 12:33:22.133: [ GIPCNET][2314] gipcmodNetworkProcessSend: slos info :  dwRet 4294967295, addr '19

2010-02-03 23:26:25.804: [GIPCXCPT][1206540320]gipcmodGipcPassInitializeNetwork: failed to find any interfaces in clsinet, ret gipcretFail (1)
2010-02-03 23:26:25.804: [GIPCGMOD][1206540320]gipcmodGipcPassInitializeNetwork: EXCEPTION[ ret gipcretFail (1) ]  failed to determine host from clsinet, using default
..
2010-02-03 23:26:25.810: [    CSSD][1206540320]clsssclsnrsetup: gipcEndpoint failed, rc 39
2010-02-03 23:26:25.811: [    CSSD][1206540320]clssnmOpenGIPCEndp: failed to listen on gipc addr gipc://rac1:nm_eotcs- ret 39
2010-02-03 23:26:25.811: [    CSSD][1206540320]clssscmain: failed to open gipc endp

2010-09-20 11:52:54.014: [    CSSD][1103055168]clssnmvDHBValidateNCopy: node 1, racnode1, has a disk HB, but no network HB, DHB has rcfg 180441784, wrtcnt, 453, LATS 328297844, lastSeqNo 452, uniqueness 1284979488, timestamp 1284979973/329344894
2010-09-20 11:52:54.016: [    CSSD][1078421824]clssgmWaitOnEventValue: after CmInfo State  val 3, eval 1 waited 0
..  >>>> after a long delay
2010-09-20 12:02:39.578: [    CSSD][1103055168]clssnmvDHBValidateNCopy: node 1, racnode1, has a disk HB, but no network HB, DHB has rcfg 180441784, wrtcnt, 1037, LATS 328883434, lastSeqNo 1036, uniqueness 1284979488, timestamp 1284980558/329930254
2010-09-20 12:02:39.895: [    CSSD][1107286336]clssgmExecuteClientRequest: MAINT recvd from proc 2 (0xe1ad870)

2009-12-10 06:28:31.974: [  OCRMAS][20]proath_connect_master:1: could not connect to master  clsc_ret1 = 9, clsc_ret2 = 9
2009-12-10 06:28:31.974: [  OCRMAS][20]th_master:11: Could not connect to the new master
2009-12-10 06:29:01.450: [ CRSMAIN][2] Policy Engine is not initialized yet!
2009-12-10 06:29:31.489: [ CRSMAIN][2] Policy Engine is not initialized yet!

2009-12-31 00:42:08.110: [ COMMCRS][10]clsc_receive: (102b03250) Error receiving, ns (12535, 12560), transport (505, 145, 0)

2011-04-16 02:59:46.943: [    CTSS][1]clsu_get_private_ip_addresses: clsinet_GetNetData failed (). Return [7]

[    CTSS][1](:ctss_init6:): Failed to call clsu_get_private_ip_addr [7]

gipcmodGipcPassInitializeNetwork: failed to find any interfaces in clsinet, ret gipcretFail (1)

gipcmodGipcPassInitializeNetwork: EXCEPTION[ ret gipcretFail (1) ]  failed to determine host from clsinet, using default

[  CRSCCL][2570585920]No private IP addresses found.

(:CSSNM00008:)clssnmCheckDskInfo: Aborting local node to avoid splitbrain. Cohort of 1 nodes with leader 2, dc4sftestdb02, is smaller than cohort of 1 nodes led by node 1, dc4sftestdb01, based on map type 2

G. 关于子网的信息

请参考 note 1386709.1 获取更多关于子网的信息。

参考

NOTE:1386709.1 - The Basics of IPv4 Subnet and Oracle Clusterware
NOTE:1507482.1 - Oracle Clusterware Cannot Start on all Nodes: Network communication with node missing for 90% of timeout interval

NOTE:1056322.1 - Troubleshoot Grid Infrastructure/RAC Database installer/runInstaller Issues
NOTE:1210883.1 - Grid Infrastructure Redundant Interconnect and ora.cluster_interconnect.haip
NOTE:1212703.1 - Grid Infrastructure Startup During Patching, Install or Upgrade May Fail Due to Multicasting Requirement

NOTE:301137.1 - OSWatcher (Includes: [Video])
NOTE:752844.1 - RHEL3, RHEL4, OEL4: traceroute Fails with -F (do not fragment bit) Argument
NOTE:341788.1 - Recommendation for the Real Application Cluster Interconnect and Jumbo Frames