In this Document
Goal
Solution
Instructions for Changing Interfaces/Subnet
Notes for Windows Systems
Ramifications of Changing Interface Names Using oifcfg
References
References
--------------------------------------------------------------------------------
Applies to:
Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 11.2.0.0. - Release: 10.1 to 11.2
Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 11.2.0.0. [Release: 10.1 to 11.2]
Information in this document applies to any platform.
Goal
The purpose of this note is to describe how to change or update the cluster_interconnect and/or public interface information that is stored in OCR.
It may be necessary to change or update interface names, or subnet associated with an interface if there is a network change affecting the servers, or if the original information that was input during the installation was incorrect. It may also be the case that for some reason, the Oracle Interface Configuration Assistant ('oifcfg') did not succeed during the installation.
This note is not intended as a means to change the Public or Private Hostnames themselves. Public or Private hostnames can only be changed by removing/adding nodes, or reinstalling Oracle Clusterware. However, VIP Hostnames can be changed, refer to Note 276434.1 for details.
Solution
Network information(interface, subnet and role of each interface) for Oracle Clusterware is managed by 'oifcfg', but actual IP address for each interfaces are not - 'oifcfg' can not update IP address information. 'oifcfg getif' can be used to find out currently configured interfaces in OCR:
% $ORA_CRS_HOME/bin/oifcfg getif
eth0 10.2.156.0 global public
eth1 192.168.0.0 global cluster_interconnect Above example is from a Linux system, but the syntax is the same for any platform. On Unix/Linux systems, the interface names are generally assigned by the OS, and standard names vary by platform. For Windows systems, see additional notes below. Above example shows currently interface eth0 is used for public with subnet 10.2.156.0, and eth1 for cluster_interconnect/private with subnet 192.168.0.0
The 'public' network is for database client communication (VIP also uses the same network though it's stored in OCR as separate entry), whereas the 'cluster_interconnect' network will be for RDBMS/ASM cache fusion; starting with 11gR2, cluster_interconnect is also used for clusterware heartbeats - this is significant change compare to prior release as pre-11gR2 uses the private nodenames that were specified at install time for clusterware heartbeats.
If the subnet for either the 'public' or 'cluster_interconnect' interface is incorrect and needs to be changed, you should make the changes using oifcfg as the same user who did the original CRS installation, because the 'setif' option updates the OCR and sets permissions in the OCR for the interface based on who is running the command. This is true on all platforms, including Windows.
Instructions for Changing Interfaces/Subnet
1. Public Network Change
If the change is only public IP address and the new ones are still in the same subnet, nothing needs to be done on clusterware level (all changes needs to be done on OS level to reflect the change). If the change involves different subnet or interface, as there is not a 'modify' option - you will need to delete the interface and add it back with the correct information. So, in the example here, the subnet is being changed from 10.2.156.0 to 10.2.166.0 via two separate commands - first a 'delif' followed by a 'setif':
% $ORA_CRS_HOME/bin/oifcfg delif -global eth0
% $ORA_CRS_HOME/bin/oifcfg setif -global eth0/10.2.166.0:public
syntax: oifcfg setif /:
Note: If public network is changed, it may be necessary to change VIP as well, refer to Note 276434.1 for details; for 11gR2, it may be necessary to change SCAN as well, refer to note 972500.1 for details.
2. Private Network Change
2A. For pre-11gR2, if you wish to change the cluster_interconnect information and/or private IP address, hosts file needs to be modified on each node to reflect the change while the Oracle Clusterware Stack is down on all nodes. After the stack has restarted, to change the cluster_interconnect used by RDBMS and ASM instances, run oifcfg. In this example:
% $ORA_CRS_HOME/bin/oifcfg delif -global eth1
% $ORA_CRS_HOME/bin/oifcfg setif -global eth1/192.168.1.0:cluster_interconnect
2B. For 11gR2 and higher, refer to note 1073502.1 and the following documentation:
Oracle Clusterware Administration and Deployment Guide 11g Release 2 (11.2)
Chapter 2 Administering Oracle Clusterware -> Changing Network Addresses on Manually Configured Networks
Note: For 11gR2, as clusterware also uses cluster_interconnect, intended private network must be added by "oifcfg setif" before stopping clusterware for any change.
Note: If you are running OCFS2 on Linux and are changing the private IP Address for your cluster, you may also need to change the private IP address that OCFS2 is using to communicate with other nodes. For more information on this, please refer to
3. Verify the correct interface subnet is in use by re-running oifcfg with the 'getif' option:
% $ORA_CRS_HOME/bin/oifcfg getif
eth0 10.2.166.0 global public
eth1 192.168.1.0 global cluster_interconnect
Notes for Windows Systems
The syntax for changing the interfaces on Windows/RAC clusters is the same as on Unix or Linux, but the interface names will be slightly different. On Windows systems, the default names assigned to the interfaces are generally names such as:
Local Area Connection
Local Area Connection 1
Local Area Connection 2
If you are using an interface name that has spaces in it, such as the examples above, you must enclose the name in quotes. Also, be aware that it is case sensitive. So for example, on Windows, you would use syntax such as the following to add the public subnet in:
C:\oracle\product\10.2.0\crs\bin\oifcfg setif -global "Local Area Connection 1"/10.2.166.0:public However, it is common practice on Windows to rename the interfaces to use names that are more meaningful, such as renaming them to 'Public' and 'Private'. If interface names are renamed after CRS is installed, then you will need to run 'oifcfg' to delete the old interface and add the new one back in, as described above.
You can view the available interface names on each node by running the command:
oifcfg iflist This command must be run on each node, as the 'iflist' option is showing the interface names that exist at the operating system level on that particular node. On the other hand, commands such as 'oifcfg getif', 'oifcfg delif' and 'oifcfg setif' are actually reading/updating the OCR, which is a shared resource. So these commands need only be run one time, and should be runnable from any node in the cluster.
Ramifications of Changing Interface Names Using oifcfg
The ramifications of changing the interface names depends on which name you are changing, and whether or not you are also changing the IP address. In cases where only the interface names are being changed, the ramifications are minor. If you change the name for the Public Interface that is stored in the OCR, you will also need to modify the nodeapps for each node. Therefore, the nodeapps will have to be brought down in order for this change to take effect. See Note 276434.1 for more details on changing the nodeapps to use a new public interface name.
For the Private interface, the database will use the interface stored in the OCR and defined as a 'cluster_interconnect' for cache fusion traffic. You will be able to see this at startup in the alert log, after the parameter listing - for example:
Cluster communication is configured to use the following interface(s) for this instance
192.168.1.1If this is incorrect, then once you have corrected the entries stored in the OCR (by using 'oifcfg' as described in this note) you will have to restart the instance in order for it to re-read the OCR and pick up the correct network. This applies to ASM instances and Database instances alike.
Note 1: If you intend to change the actual IP addresses for the interconnect, this should be done while the CRS stack is down, in order to prevent node evictions. However, the CRS stack must be running in order to run the 'oifcfg' utility. Once the IP addresses are changed, and the CRS stack has been brought back up, you can then use 'oifcfg' to change the information stored in the OCR. At that point, the instances can then be started.
Note 2: On Windows systems, after shutting down the instance, you will also need to stop/restart the OracleService
(or OracleASMService before the OCR will be re-read. References
For additional information on these commands:
For 10gR1, refer to:
Oracle Real Application Clusters Administrator's Guide 10g Release 1 (10.1) Part No. B10765-01. Chapter 8, "Administrative Options", Administering System and Network Interfaces with the
OIFCFG (Oracle Interface Configuration) Tool
For 10gR2, refer to:
Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide , 10g Release 2 (10.2) , Part Number B14197-03. Chapter 9.
For 11gR1, refer to:
Oracle Clusterware Administration and Deployment Guide
11g Release 1 (11.1) , Part Number B28255-03, Appendix C
For 11gR2, refer to:
Oracle Clusterware Administration and Deployment Guide
11g Release 2 (11.2), Part Number E10717-10, Appendix D
Oifcfg Usage:
oifcfg iflist
oifcfg setif {-node | -global} {/:}...
oifcfg getif [-node | -global] [ -if [/] [-type ] ]
oifcfg delif [-node | -global] [[/]]
oifcfg [-help]
- name of the host, as known to a communications network
- name by which the interface is configured in the system
- subnet address of the interface
- type of the interface { cluster_interconnect | public | storage }
