Tuning the Cluster Interconnect - Expert Oracle RAC Performance Diagnostics and Tuning - page 476

Step 4
Further investigation of the traffic on the network adapters using IPTraf indicated the following:

• There was traffic moving between the network configured for the interconnect using the

TCP protocol. Clusterware uses TCP for heartbeat checks and clusterware-level messages.
From Step 1 previously, the OCR file had the right entries for the CSS, indicating the
clusterware was using the private network for heartbeat verification.

• There was no UDP traffic on the network configured for the interconnect. However, there was

a large amount of UDP traffic on the public interface. This cross-verified the finding in Step 3
previously that the database had a wrong configuration and was using the public interface.

Step 5
Where did the database get the private IP address? The following query output indicated that the IP address for the
cache fusion should have been coming from the OCR file but was coming from the O/S:

SELECT inst_id,
name,
ip_address,
is_public
FROM gv$cluster_interconnects
ORDER BY inst_id;

Instance NAME IP_ADDRESS IS_ SOURCE
-------- --------------- ---------------- --- ---------------------
1 bond0 10.32.8.35 NO OS dependent software
5 bond0 10.32.8.43 NO OS dependent software
4 bond0 10.32.8.41 NO OS dependent software
3 bond0 10.32.8.39 NO OS dependent software
2 bond0 10.32.8.37 NO OS dependent software

Step 6
The private interfaces are not visible to the database for cache fusion. The oifcfg command can also help verify if the
private interface is visible to the database. The following command returned no entries:

$GRID_HOME/bin/oifcfg getif