环境描述：机房断电后服务器和存储均正常启动，集群在硬件启动好后也启动正常，两实例均打开到open状态，grid监听状态也正常。
故障描述：客户反应有部分客户端在登录的时候报ORA-12541，有的客户端要登录好几次才能登上，客户端只要登上了不退出就一直能正常使用。
故障排查：
1.集群状态、数据库状态、监听状态都正常。
2.数据库层面，每个节点通过v$session查看，每个节点都是有客户端连接的，这一点也是比较具有误导性，这些会话可能是在监听分发连接正常的时候进来的。
3.查看数据库日志和监听日志都没什么问题
4.端口测试，服务器物理地址和vip和scanip的1521端口测试都是通的。（也不知道为什么后来从终端测试发现节点1的vip的1521端口不通了，不知道是不是时断时续的）
5.集群服务上用arp发包测试scanip连通性也是没有问题的。/sbin/arping -c 5 -I eth0 192.168.xxx.xxx (scanip的地址)
6.从远程终端sqlplus连接数据库，连接地址为节点1 vip的时候一直连接不上提示无监听，链接地址为节点2 vip时一直可以连，连接地址为scanip的时候偶尔能连上，大部分也会报错没有监听。
故障分析：
从以上分析大概率可以确定是网络问题了，最大可能就是节点1的vip地址被占用导致了地址冲突，但是长ping所有地址又不会出现丢包的情况，长tcping集群scanip加端口号都是通的。sqlplus节点1的vip连不上我们就测试节点1 vip的端口，测试下来发现1521端口不通。咨询大佬，大佬建议让网络方面查一下汇聚交换机的arp表。是不是arp表上节点1 的vip地址被占用了。
临时解决：先把节点一的监听给停掉，不要让集群把连接分发给节点1，停掉节点1监听，下面客户端连接就正常了。
网络问题处理：刷新汇聚arp表，也可以争对那个有问题的地址刷新单条，固定集群ip地址。
问题深层原因：服务器和部分终端设备共用一台汇聚交换机，并且交换机开启了DHCP，这就会导致如果有设备先开机就会有可能在arp表上占用集群的地址，导致故障。