一个rac只能启动一个节点crs的问题，目前怀疑是多播问题造成。

前几日在历史库测试PSU升级，在完成一个节点软件升级后对第二节点GI进行升级时，CRS可以正常成功关闭，之后报出了Error : The opatch Applicable check failed，于是尝试重新启动CRS，但很明显CRS无法正常启动。


通过日志查看，发现CRS-5818:Aborted command 'start' for resource 'ora.cssd'.在启动CSSD 资源无法成功，并且从当前的进程情况可以确认CSS存在问题。


于是从当时的CSSD日志可以看出，CSSD在启动时，在准备与远程节点的过程中创建本地通信接口时失败了，具体的日志分析如下：

从gpnp profile中获取集群的私网信息。



2.以下开始准备和远程节点通信，并created local interface for node 'nghis-db2',但在进行绑定endpoint (localAddr 'mcast://224.0.0.251:42424/192.169.1.40')失败了，该本地地址为一个mcast地址。


当时看到No buffer space available (74)，认为是怀疑是udp_sendspace和udp_recvspace不够大，查询发现分别为65536和655360，这实际应用是足够了。不出意料，将该两个参数调大之后重启CRS依然无法解决，而在MOS上关于该错误的大部分都指向了BUG,11gR2 Grid Infrastructure Node May not Join the Cluster After Evicted With Error sgipcnUdpSend "No buffer space available (74)" (文档 ID 1352887.1)。

但当前的现象与该文档描述不符合，

当前的操作是sgipcnMctBind


文档中的是sgipcnUdpSend


3.更新接口状态，依然无法创建本地接口，即无法与远程节点通信，于是执行了disable interface 并clean disabled insterface


4.重新开始add interface ，但仍然失败。


5.之后连续每隔1分钟报出了 has a disk HB, but no network HB，说明此时私网上应该出现了联通性的故障。


于是我们测试了私网地址的联通是否有问题，使用traceroute 检查，然而并没有联通性问题。


于是就很不理解了，在心跳网卡既然没有问题，为何无法检测到网络心跳。此时问题应该还是出现在以上出现No buffer space available (74)的gipcmodNetworkProcessBind的过程，对比了节点1正常启动 gipchaWorkerCreateInterface的过程，一共添加了4个地址：

1.udp://192.169.1.39:13034 ------私网地址

2.mcast://224.0.0.251:42424/192.169.1.39 -----多播地址

3.mcast://230.0.1.0:42424/192.169.1.39 -----多播地址

4.udp://192.169.1.127:42424 -------广播地址


很明显节点2在以上的过程中应该是在添加第二个地址，多播地址mcast://224.0.0.251:42424/192.169.1.40时出现了问题。

通过多播检测工具检测私网网卡的多播地址联通性，发现都是检测失败，而测试节点1的是成功的，于是怀疑问题应该是出现在节点2的多播地址上。



有怀疑是HAIP问题，于是尝试将HAIP disable掉，并将私网网卡上的169 ip 依然无法解决。

禁止haip命令：

oracle/app/11.2.0.4/grid/bin/crsctl modify res ora.cluster_interconnect.haip -attr "ENABLED=0" -init

最后同事提议使出杀手锏---重启主机，由于这套库是历史库，没有实时的业务，确定无影响后就进行了重启主机，重启主机后CRS能正常启动，CSS也正常通过过了gipchaWorkerCreateInterfac步骤。


再次检测私网网卡的多播地址联通性，这次是成功了。


至此，问题解决了，但因为是通过重启主机解决，始终感觉这并不是最终的原因。多播检测不通，是否意味着网络确实是存在问题？这点也不敢断论。