適用於:
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 UNIXnode
用途
Cluster Verification Utility（簡稱 CVU，命令式 runcluvfy.sh 或者 cluvfy）是個很是實用的檢查網絡和域名解析的工具，可是它也可能沒法捕獲到全部的問題。若是網絡和域名解析在安裝以前沒有正常的配置，一般直接致使安裝的失敗。若是網絡或者域名解析出現故障，一般會致使 clusterware 或者 RAC 會出現錯誤。本文的目的在於列出一些和網絡以及域名相關的檢查項目來檢驗網絡和域名解析對 Grid Infrastructure（clusterware）和 RAC 的配置是不是正確的。數據庫
適用範圍
本文提供給 Oracle Clusterware/RAC 數據庫管理員和 Oracle 的技術支持工程師參考。網絡
詳細信息
A. 必要條件
不管是公網或者私網，經過 network ping 的方式經過網卡傳輸 MTU 大小的數據包可以正常工做。而且ping的時間很是短。oracle
IP 地址 127.0.0.1 須要映射到 localhost 或者 localhost.localdomain 上。dom
不要把任何網卡的地址配置成 127.*.*.*。jsp
公網網卡的名稱在全部節點上都必須是相同的。
私網網卡的名稱在 11gR2 的版本上，推薦使用相同的，在 11.2 以前的版本必須是相同的。ide
不管是公網仍是私網，都不能使用本地的子網（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 文件中。ui
對於 11.2.0.2 以及以上的版本，多播羣 230.0.1.0 須要可以在私網的網絡配置中工做；若是打了補丁 9974223 230.0.1.0 和 224.0.0.251 是都支持的。若是打了補丁 10411721 （問題在 11.2.0.3 的版本上作了修復），廣播會被支持。詳細請參考 Multicast/Broadcast 的驗證部分。url
對於 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