TCP connectivity check failed for subnet "10.10.10.0"
OR
PRVF-7616 : Node connectivity failed for subnet "10.10.16.0" between "racnode1 - eth5 : 10.10.16.109" and "racnode2 - eth5 : 10.10.16.121"
Result: Node connectivity failed for subnet "10.10.16.0"
When the error happens, likely OUI will report:
[INS-41110] Specified network interface doesnt maintain connectivity across cluster nodes.
[INS-41112] Specified network interface doesnt maintain connectivity across cluster nodes.
Details
Known Issues
?bug 12849377 - CVU should check only selected network interfaces (ignore "do not use")
CVU checks network interfaces that's marked "do not use", fixed in 11.2.0.3 GI PSU1
?bug 9952812 - CVU SHOULD RETURN WARNING INSTEAD OF FATAL ERROR FOR VIRBR0
Happens on Linux if network adapter virbr0 exists, fixed in 11.2.0.3.
The fix introduces new CVU parameter (-network) to check only specified networks:
runcluvfy.sh stage -pre crsinst -n <racnode1>,<racnode2> -networks "eth*" -verbose
?bug 11903488 - affects Solaris only, fixed 11.2.0.3
As Solaris does not support the socket option SO_RCVTIMEO, TCP server fails to start:
In this example, racnode1 is nodename and 10.1.0.11 is the IP to test connectivity:
/tmp/CVU_<version>_<user>/exectask.sh -runTCPserver racnode1 10.1.0.11
<CV_ERR>location:prvnconss1 opname:free port unavailable category:0 DepInfo: 99</CV_ERR>
<CV_LOG>Exectask:runTCPServer failed</CV_LOG>
..
<CV_ERR>Error running TCP server</CV_ERR>
bug 11903488 also remove the port range of 49900-50000 to use the first available
exectask.sh -chkTCPclient <server> <server-IP> <server-port> <client> <client-IP>
?bug 12353524 - affects hp-ux only, fixed in 11.2.0.3
<CV_ERR>location:prvnconcc3 opname:client to server connection fail
category:0 otherInfo: Client to server connection failed, errno: 227
DepInfo: 227</CV_ERR> <CV_VAL>-1</CV_VAL>
<CV_LOG>Exectask:chkTCPClient failed</CV_LOG> <CV_VRES>1</CV_VRES>
<CV_ERR>Error checking TCP communication</CV_ERR>
<CV_ERES>1</CV_ERES>
?bug 12608083 - affects Windows only, fixed in 11.2.0.3
When more than one network interface are on the same subnet, it is possible that the wrong interface is used to verify TCP connectivity.
?bug 10106374 - affects Windows only, fixed in 11.2.0.2
Refer to note 1286394.1 for details.
?bug 16953470 - affects Solaris only, happens when "hostmodel" is set to strong
CVU trace:
[7041@racnode1] [Thread-408] [ 2013-06-13 12:41:17.772 GMT+04:00 ] [StreamReader.run:65] OUTPUT><CV_CMD>/usr/sbin/ping -i 192.168.169.2 192.168.169.2 3 </CV_CMD><CV_VAL>/usr/sbin/ping: sendto Network is unreachable
Manually run the "ping -i" command, receives same error
To find out current "hostmodel":
# ipadm show-prop -p hostmodel ip
PROTO PROPERTY PERM CURRENT PERSISTENT DEFAULT POSSIBLE
ipv6 hostmodel rw weak weak weak strong, src-prio, rity, weak
ipv4 hostmodel rw weak weak weak strong, src-prio, rity, weak
To change hostmodel:
ipadm set-prop -p hostmodel=weak ipv4
ipadm set-prop -p hostmodel=weak ipv6
The workaround is to set hostmodel to weak
In addition, Solaris bug 16827053 is open to fix on OS level.
?bug 17043435
The bug is closed as duplicate of internal bug 17070860 which is fixed in 11.2.0.4
To verify manually
Repeat the following for each interface as grid user:
runcluvfy.sh comp nodecon -i <network-interface> -n <racnode1>,<racnode2>,<racnode3> -verbose
When to ignore the error?
If the error happened on network that's not related to Oracle Clusterware, it can be ignored, i.e. if happened on administrative network and not affecting anything, it can be ignored.