Ora Net 1c

Still not quite sure then in the light of that why a node also requires a vip on top of the
public ip and
private ip ?
In case in node failure, the VIP address is moved to one of the surviving nodes which is used for
connections fail-over and also resolves the TCP/IP timeout for connections to that IP.
Is it therefore possible to setup RAC / GNS without DNS or DHCP ?

Yes, it is possible to setup RAC (but not GNS), you just'll have to edit /etc/hosts (on all nodes) file to
hard-code the IP addresses.
Also if I am just setting up 2 nodes, I presume there will only be 2 SCAN listeners by default ( or is
the minimum 3 and there will simply be 2 on the same node ? )
In that case, two SCAN listeners will run on one node.
If you have ever been tasked with extending an Oracle RAC cluster by adding a new node (or
shrinking a RAC cluster by removing a node), then you know the pain of going through a list of all
clients and updating their SQL*Net or JDBC configuration to reflect the new or deleted node. To
address this problem, Oracle 11g Release 2 introduced a new feature known as Single Client Access
Name or SCAN for short. SCAN is a new feature that provides a single host name for clients to access
an Oracle Database running in a cluster. Clients using SCAN do not need to change their TNS
configuration if you add or remove nodes in the cluster. The SCAN resource and its associated IP
address(s) provide a stable name for clients to use for connections, independent of the nodes that make
up the cluster. You will be asked to provide the host name (also called the SCAN name in this
document) and up to three IP addresses to be used for the SCAN resource during the interview phase
of the Oracle Grid Infrastructure installation. For high availability and scalability, Oracle recommends
that you configure the SCAN name for round-robin resolution to three IP addresses. At a minimum,
the SCAN must resolve to at least one address.
The SCAN virtual IP name is similar to the names used for a node's virtual IP address, such as
racnode1-vip. However, unlike a virtual IP, the SCAN is associated with the entire cluster, rather than
an individual node, and can be associated with multiple IP addresses, not just one address.
During installation of the Oracle Grid Infrastructure, a listener is created for each of the SCAN
addresses. Clients that access the Oracle RAC database should use the SCAN or SCAN address, not
the VIP name or address. If an application uses a SCAN to connect to the cluster database, the
network configuration files on the client computer do not need to be modified when nodes are added
to or removed from the cluster. Note that SCAN addresses, virtual IP addresses, and public IP
addresses must all be on the same subnet.
The SCAN should be configured so that it is resolvable either by using Grid Naming Service (GNS)
within the cluster or by using the traditional method of assigning static IP addresses using Domain
Name Service (DNS) resolution.
In this article, I will configure SCAN for round-robin resolution to three, manually configured static
IP address using the DNS method.
racnode-cluster-scan IN A 192.168.1.187
I can now see how SCAN name is basically, from the client perspective, an abstraction for the cluster
to in effect give a single name for the cluster which GNS will resolve ( i.e. a vip in its own right but
which could be any one of the VIPs of the SCAN Listeners )
Still not quite sure then in the light of that why a node also requires a vip on top of the public ip and
private ip ? Will SCAN not point to a SCAN Listener and in turn redirect a connection to a local
listener ( will this redirection not use the public IP of the node being redirtected to ? ).
Just to clear my confusion - a node will have a public and a private IP, does it also have a virtual ip in
addition to these ?
Also I am just setting up Clusterware/RAC in a small demo environment. I am using 2 linux servers
just connected by a network switch. I wasn't planning configuring any DNS or DHCP. Is it therefore
possible to setup RAC / GNS without DNS or DHCP ?
Also if I am just setting up 2 nodes, I presume there will only be 2 SCAN listeners by default ( or is
the minimum 3 and there will simply be 2 on the same node ? )
A comment. You can use a single IP for SCAN. You can use /etc/hosts for hostname resolution across
all RAC nodes. 3 IPs are not mandatory. DNS resolution is not mandatory.
As for why so SCAN and VIP. A SCAN Listener cannot and does not directly connect a client to a
database instance.
It has a list of "remote" services. It hands off a client connection to a specific VIP listener (depending
on things like requested service, load balancing, etc).
So the SCAN IP and listener are like an abstraction or proxy layer - where the client uses a single
name for access to a specific cluster service, without having to know on which RAC nodes that cluster
service run on, and the virtual IP addresses for these cluster nodes.
Interestingly, back with Oracle Parallel Server (precursor to RAC), there was a similar single cluster
IP concept. This disappeared with RAC in Oracle 8. The SCAN feature was sorely missed as it makes
accessing cluster services a lot easier.
PURPOSE
This document is intended to explain what is ora.cluster_interconnect.haip resource in 11gR2 Grid
Infrastructure.
DETAILS
Redundant Interconnect without any 3rd-party IP failover technology (bond, IPMP or similar) is supp
orted natively by Grid Infrastructure starting from 11.2.0.2. Multiple private network adapters can be
defined either during the installation phase or afterward using the oifcfg. Oracle Database, CSS,
OCR, CRS, CTSS, and EVM components in 11.2.0.2 employ it automatically.
Grid Infrastructure can activate a maximum of four private network adapters at a time even if more are
defined. The ora.cluster_interconnect.haip resource will start one to four link local HAIP on private
network adapters for interconnect communication for Oracle RAC、ASM, and Oracle ACFS etc.
Grid automatically picks free link local addresses from reserved 169.254.*.* subnet for HAIP.
According to RFC-3927, link local subnet 169.254.*.* should not be used for any other purpose. With
HAIP, by default, interconnect traffic will be load balanced across all active interconnect interfaces, a
nd corresponding HAIP address will be failed over transparently to other adapters if one fails or beco
mes non-communicative. .
After GI is configured, more private network interface can be added with "<GRID_HOME>/ bin/oifc
fg setif" cmd. The number of HAIP addresses is decided by how many private network adapters are ac
tive when Grid comes up on the first node in the cluster. If there's only one active private network, Gri
d will create one; if two, Grid will create two; and if more than two, Grid w ill create four HAIPs. The
number of HAIPs won't change even if more private network adapters are activated later, a restart of
clusterware on all nodes is required for the number to change, however, the newly activated adapters
can be used for fail over purpose.
NOTE: If using the 11.2.0.2 (and above) Redundant Interconnect/HAIP feature (as documented in CA
SE 2 below) - At present it is REQUIRED that all interconnect interfaces be placed on separate subne
ts. If the interfaces are all on the same subnet and the cable is pulled from the first NIC in the routing
table a rebootless-restart or node reboot will occur.
At the time of this writing, redundant private network requires different subnet for each network adapt
er, for example, if eth1, eth2 and eth3 are used for private network, each should be on different subnet,
Refer to Case 2.
When Oracle Clusterware is fully up, resource haip should show status of ONLINE:
$ $GRID_HOME/bin/crsctl stat res -t -init
..
ora.cluster_interconnect.haip
1 ONLINE ONLINE <node1>
Case 1: Single Private Network Adapter

If multiple physical network adapters are bonded together at the OS level and presented as a single de
vice name, for example bond0, it's still considered a single network adapter environment. Single priva
te network adapter does not offer true HAIP, as there's only one adapter, at least two is recomm ended
to gain true HAIP. If only one private network adapter is defined, such as eth1 in the example below,
one virtual IP will be created by HAIP. Here is what's expected when Grid is up and running:
$ $GRID_HOME/bin/oifcfg getif
eth1 10.x.x.128 global cluster_interconnect
eth3 10.1.x.x global public
$ $GRID_HOME/bin/oifcfg iflist -p -n
eth1 10.x.x.128 PRIVATE 255.255.255.128
eth1 169.254.0.0 UNKNOWN 255.255.0.0
eth3 10.1.x.x PRIVATE 255.255.255.128
Note: 1. subnet 169.254.0.0 on eth1 is started by resource haip; 2. refer to note 1386709.1 for
explanation of the output
ifconfig
..
eth1 Link encap:Ethernet HWaddr 00:16:3E:11:11:22
inet addr:10.x.x.168 Bcast:10.1.0.255 Mask:255.255.255.128
inet6 addr: fe80::216:3eff:fe11:1122/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6369306 errors:0 dropped:0 overruns:0 frame:0
TX packets:4270790 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3037449975 (2.8 GiB) TX bytes:2705797005 (2.5 GiB)
eth1:1 Link encap:Ethernet HWaddr 00:16:3E:11:22:22

inet addr:169.254.x.x Bcast:169.254.255.255 Mask:255.255.0.0
Instance alert.log (ASM and database):
Private Interface 'eth1:1' configured from GPnP for use as a private interconnect.
[name='eth1:1', type=1, ip=169.254.x.x, mac=00-16-3e-11-11-22, net=169.254.0.0/16,
mask=255.255.0.0, use=haip:cluster_interconnect/62]
Public Interface 'eth3' configured from GPnP for use as a public interface.
[name='eth3', type=1, ip=10.x.x.168, mac=00-16-3e-11-11-44, net=10.1.x.x/25,
mask=255.255.255.128, use=public/1]
..
Shared memory segment for instance monitoring created
Picked latch-free SCN scheme 3
..
Cluster communication is configured to use the following interface(s) for this instance
169.254.x.x
Note: interconnect will use virtual private IP 169.254.x.x instead of real private IP. For pre-11.2.0.2
instance, by default it will still use the real private IP; to take advantage of the new feature, init.ora
parameter cluster_interconnects can be updated each time Grid is restarted .
For 11.2.0.2 and above, v$cluster_interconnects will show haip info:

SQL> select name,ip_address from v$cluster_interconnects;
NAME IP_ADDRESS
--------------- ----------------
eth1:1 169.254.x.x
Case 2: Multiple Private Network Adapters

Multiple switches can be deployed if there's more than one private network adapters on each node, in
case one network adapter fails, the HAIP on that network segment will be failed over to others on all
nodes.
2.1. Default Status

Here is an example of 3 private networks eth1, eth6 and eth7 when Grid is up and running:
$ $GRID_HOME/bin/oifcfg getif
eth1 10.x.x.128 global cluster_interconnect
eth3 10.1.x.x global public
eth6 10.11.x.x global cluster_interconnect
eth7 10.12.x.x global cluster_interconnect
eth1 10.x.x.128 PRIVATE 255.255.255.128
eth1 169.254.0.x UNKNOWN 255.255.192.0
eth1 169.254.192.x UNKNOWN 255.255.192.0
eth3 10.1.x.x PRIVATE 255.255.255.128
eth6 10.11.x.x PRIVATE 255.255.255.128
eth6 169.254.64.x UNKNOWN 255.255.192.0
eth7 10.12.x.x PRIVATE 255.255.255.128
eth7 169.254.128.x UNKNOWN 255.255.192.0
Note: resource haip started four virtual private IPs, two on eth1, and one on eth6 and eth7
ifconfig
..



RX bytes:2692567483 (2.5 GiB) TX bytes:382357191 (364.6 MiB)



Instance alert.log (ASM and database):

[name='eth1:1', type=1, ip=169.254.xx.xx, mac=00-16-3e-11-11-22, net=169.254.x.0/18,
[name='eth6:1', type=1, ip=169.254.xx.xx, mac=00-16-3e-11-11-77, net=169.254.x.0/18,
[name='eth7:1', type=1, ip=169.254.x.x, mac=00-16-3e-11-11-88, net=169.254.x.0/18,
[name='eth1:2', type=1, ip=169.254.x.x, mac=00-16-3e-11-11-22, net=169.254.x.0/18,
Public Interface 'eth3' configured from GPnP for use as a public interface.
[name='eth3', type=1, ip=10.x.x.68, mac=00-16-3e-11-11-44, net=10.1.x.x/25,
mask=255.255.255.128, use=public/1]
Picked latch-free SCN scheme 3
..
Cluster communication is configured to use the following interface(s) for this instance
169.254.x.98
169.254.x.250
169.254.x.237
169.254.x.103
Note: interconnect communication will use all four virtual private IPs; in case of network failure, as
long as there is one private network adapter functioning, all four IPs will remain active.
2.2. When Private Network Adapter Fails

If one private network adapter fails, in this example eth6, virtual private IP on eth6 will be relocated
automatically to a healthy adapter, and it is transparent to instances (ASM or database)
eth1 10.x.x.128 PRIVATE 255.255.255.128
eth1 169.254.0.x UNKNOWN 255.255.192.0
eth1 169.254.128.x UNKNOWN 255.255.192.0
eth7 10.12.x.x PRIVATE 255.255.255.128
eth7 169.254.64.x UNKNOWN 255.255.192.0
eth7 169.254.192.x UNKNOWN 255.255.192.0
Note: virtual private IP on eth6 subnet 169.254.64.x relocated to eth7
ifconfig
..





2.3. When Another Private Network Adapter Fails

If another private network adapter is down, in this example eth1, virtual private IP on it will be
relocated automatically to other healthy adapter with no impact on instances (ASM or database)
eth7 10.12.x.x PRIVATE 255.255.255.128
eth7 169.254.64.x UNKNOWN 255.255.192.0
eth7 169.254.192.x UNKNOWN 255.255.192.0
eth7 169.254.0.x UNKNOWN 255.255.192.0
eth7 169.254.128.x UNKNOWN 255.255.192.0
ifconfig
..



2.4. When Private Network Adapter Restores

If private network adapter eth6 is restored, it will be activated automatically as virtual private IPs will
be assigned to it:
..
eth6 10.11.x.x PRIVATE 255.255.255.128
eth6 169.254.128.x UNKNOWN 255.255.192.0
eth6 169.254.0.x UNKNOWN 255.255.192.0
eth7 10.12.x.x PRIVATE 255.255.255.128
eth7 169.254.64.x UNKNOWN 255.255.192.0
eth7 169.254.192.x UNKNOWN 255.255.192.0
ifconfig
..
RX bytes:185138 (180.7 KiB) TX bytes:56439 (55.1 KiB)





Miscellaneous
It's NOT supported to disable or stop HAIP while the cluster is up and running unless otherwise
advised by Oracle Support/Development.
1. The feature is disabled in 11.2.0.2/11.2.0.3 if Sun Cluster exists
2. The feature does not exist in Windows 11.2.0.2/11.2.0.3
3. The feature is disabled in 11.2.0.2/11.2.0.3 if Fujitsu PRIMECLUSTER exists
4. With the fix of bug 11077756 (fixed in 11.2.0.2 GI PSU6, 11.2.0.3), HAIP will be disabled if it fails
to start while running root script (root.sh or rootupgrade.sh), for more details, refer to Section bug 110
77756
5. The feature is disabled on Solaris 11 if IPMP is used for private network. Tracking bug 16982332
6. The feature is disabled on HP-UX and AIX if cluster_interconnect/"private network" is Infiniband
HAIP Log File

Resource haip is managed by ohasd.bin, resource log is located in
$GRID_HOME/log/<nodename>/ohasd/ohasd.log and
$GRID_HOME/log/<nodename>/agent/ohasd/orarootagent_root/orarootagent_root.log
L1. Log Sample When Private Network Adapter Fails

In a multiple private network adapter environment, if one of the adapters fails:
ohasd.log
2010-09-24 09:10:00.891: [GIPCHGEN][1083025728]gipchaInterfaceFail: marking interface failing
0x2aaab0269a10 { host '', haName 'CLSFRAME_a2b2', local (nil), ip '10.11.x.x', subnet '10.11.x.x',
mask '255.255.255.128', numRef 0, numFail 0, flags 0x4d }
2010-09-24 09:10:00.902: [GIPCHGEN][1138145600]gipchaInterfaceDisable: disabling interface
0x2aaab0269a10 { host '', haName 'CLSFRAME_a2b2', local (nil), ip '10.11.x.x', subnet '10.11.x.x',
mask '255.255.255.128', numRef 0, numFail 0, flags 0x1cd }
2010-09-24 09:10:00.902: [GIPCHDEM][1138145600]gipchaWorkerCleanInterface: performing
cleanup of disabled interface 0x2aaab0269a10 { host '', haName 'CLSFRAME_a2b2', local (nil), ip
'10.11.0.188', subnet '10.11.x.x', mask '255.255.255.128', numRef 0, numFail 0, flags 0x1ed }
orarootagent_root.log
2010-09-24 09:09:57.708: [ USRTHRD][1129138496] {0:0:2} failed to receive ARP request
2010-09-24 09:09:57.708: [ USRTHRD][1129138496] {0:0:2} Assigned IP 169.254.x.x no longer
valid on inf eth6
2010-09-24 09:09:57.708: [ USRTHRD][1129138496] {0:0:2} VipActions::startIp {
2010-09-24 09:09:57.708: [ USRTHRD][1129138496] {0:0:2} Adding 169.254.x.x on eth6:1
2010-09-24 09:09:57.719: [ USRTHRD][1129138496] {0:0:2} VipActions::startIp }
2010-09-24 09:09:57.719: [ USRTHRD][1129138496] {0:0:2} Reassigned IP: 169.254.x.x on
interface eth6
2010-09-24 09:09:58.013: [ USRTHRD][1082325312] {0:0:2} HAIP: Updating member info
HAIP1;10.11.x.x#0;10.11.x.x#1
2010-09-24 09:09:58.015: [ USRTHRD][1082325312] {0:0:2} HAIP: Moving ip '169.254.x.x' from
inf 'eth6' to inf 'eth7'
2010-09-24 09:09:58.015: [ USRTHRD][1082325312] {0:0:2} pausing thread
2010-09-24 09:09:58.015: [ USRTHRD][1082325312] {0:0:2} posting thread
2010-09-24 09:09:58.016: [ USRTHRD][1082325312] {0:0:2} Thread:[NetHAWork]start {
2010-09-24 09:09:58.016: [ USRTHRD][1082325312] {0:0:2} Thread:[NetHAWork]start }
2010-09-24 09:09:58.017: [ USRTHRD][1116531008] {0:0:2} [NetHAWork] thread started
2010-09-24 09:09:58.017: [ USRTHRD][1116531008] {0:0:2} Arp::sCreateSocket {
2010-09-24 09:09:58.034: [ USRTHRD][1116531008] {0:0:2} Arp::sCreateSocket }
2010-09-24 09:09:58.034: [ USRTHRD][1116531008] {0:0:2} Starting Probe for ip 169.254.x.x
2010-09-24 09:09:58.034: [ USRTHRD][1116531008] {0:0:2} Transitioning to Probe State
2010-09-24 09:09:58.231: [ USRTHRD][1093232960] {0:0:2} Arp::sProbe {
2010-09-24 09:09:58.231: [ USRTHRD][1093232960] {0:0:2} Arp::sSend: sending type 1
2010-09-24 09:09:58.231: [ USRTHRD][1093232960] {0:0:2} Arp::sProbe }
2010-09-24 09:10:04.879: [ USRTHRD][1116531008] {0:0:2} Arp::sAnnounce {

2010-09-24 09:10:04.879: [ USRTHRD][1116531008] {0:0:2} Arp::sSend: sending type 1
2010-09-24 09:10:04.879: [ USRTHRD][1116531008] {0:0:2} Arp::sAnnounce }
2010-09-24 09:10:04.879: [ USRTHRD][1116531008] {0:0:2} Transitioning to Defend State
2010-09-24 09:10:04.879: [ USRTHRD][1116531008] {0:0:2} VipActions::startIp {
2010-09-24 09:10:04.879: [ USRTHRD][1116531008] {0:0:2} Adding 169.254.x.x on eth7:2
2010-09-24 09:10:04.880: [ USRTHRD][1116531008] {0:0:2} VipActions::startIp }
2010-09-24 09:10:04.880: [ USRTHRD][1116531008] {0:0:2} Assigned IP: 169.254.x.x on interface
eth7
2010-09-24 09:10:06.802: [ USRTHRD][1082325312] {0:0:2} VipActions::stopIp }

2010-09-24 09:10:06.803: [ USRTHRD][1082325312] {0:0:2} USING HAIP[ 0 ]: eth7 -
169.254.112.x
169.254.178.x
169.254.244.x
169.254.30.x
Note: from above, even only NIC eth6 failed, there could be multiple virtual private IP movement
among surviving NICs
ocssd.log
2010-09-24 09:09:58.314: [ GIPCNET][1089964352] gipcmodNetworkProcessSend: [network] failed
send attempt endp 0xe1b9150 [0000000000000399] { gipcEndpoint : localAddr
'udp://10.11.x.x:60169', remoteAddr '', numPend 5, numReady 1, numDone 0, numDead 0,
numTransfer 0, objFlags 0x0, pidPeer 0, flags 0x2, usrFlags 0x4000 }, req 0x2aaab00117f0
[00000000004b0cae] { gipcSendRequest : addr 'udp://10.11.x.x:41486', data 0x2aaab0050be8, len 80,
olen 0, parentEndp 0xe1b9150, ret gipcretEndpointNotAvailable (40), objFlags 0x0, reqFlags 0x2 }
2010-09-24 09:09:58.314: [ GIPCNET][1089964352] gipcmodNetworkProcessSend: slos op :
sgipcnValidateSocket
2010-09-24 09:09:58.314: [ GIPCNET][1089964352] gipcmodNetworkProcessSend: slos dep :
Invalid argument (22)
2010-09-24 09:09:58.314: [ GIPCNET][1089964352] gipcmodNetworkProcessSend: slos loc :
address not
2010-09-24 09:09:58.314: [ GIPCNET][1089964352] gipcmodNetworkProcessSend: slos info: addr
'10.11.x.x:60169', len 80, buf 0x2aaab0050be8, cookie 0x2aaab00117f0
2010-09-24 09:09:58.314: [GIPCXCPT][1089964352] gipcInternalSendSync: failed sync request, ret
gipcretEndpointNotAvailable (40)
2010-09-24 09:09:58.314: [GIPCXCPT][1089964352] gipcSendSyncF [gipchaLowerInternalSend :
gipchaLower.c : 755]: EXCEPTION[ ret gipcretEndpointNotAvailable (40) ] failed to send on endp
0xe1b9150 [0000000000000399] { gipcEndpoint : localAddr 'udp://10.11.x.x:60169', remoteAddr '',
numPend 5, numReady 0, numDone 0, numDead 0, numTransfer 0, objFlags 0x0, pidPeer 0, flags
0x2, usrFlags 0x4000 }, addr 0xe4e6d10 [00000000000007ed] { gipcAddress : name
'udp://10.11.x.x:41486', objFlags 0x0, addrFlags 0x1 }, buf 0x2aaab0050be8, len 80, flags 0x0
2010-09-24 09:09:58.314: [GIPCHGEN][1089964352] gipchaInterfaceFail: marking interface failing
0xe2bd5f0 { host '<node2>', haName 'CSS_a2b2', local 0x2aaaac2098e0, ip '10.11.x.x:41486', subnet
'10.11.0.128', mask '255.255.255.128', numRef 0, numFail 0, flags 0x6 }
2010-09-24 09:09:58.314: [GIPCHALO][1089964352] gipchaLowerInternalSend: failed to initiate
send on interface 0xe2bd5f0 { host '<node2>', haName 'CSS_a2b2', local 0x2aaaac2098e0, ip
'10.11.x.x:41486', subnet '10.11.x.x', mask '255.255.255.128', numRef 0, numFail 0, flags 0x86 }, hctx
0xde81d10 [0000000000000010] { gipchaContext : host '<node1>', name 'CSS_a2b2', luid '4f06f2aa-
00000000', numNode 1, numInf 3, usrFlags 0x0, flags 0x7 }
2010-09-24 09:09:58.326: [GIPCHGEN][1089964352] gipchaInterfaceDisable: disabling interface
0x2aaaac2098e0 { host '', haName 'CSS_a2b2', local (nil), ip '10.11.x.x', subnet '10.11.x.x', mask
'255.255.255.128', numRef 0, numFail 1, flags 0x14d }
'10.11.x.x', mask '255.255.255.128', numRef 0, numFail 0, flags 0x86 }
2010-09-24 09:09:58.327: [GIPCHALO][1089964352] gipchaLowerCleanInterfaces: performing
cleanup of disabled interface 0xe2bd5f0 { host '<node2>', haName 'CSS_a2b2', local
0x2aaaac2098e0, ip '10.11.x.x:41486', subnet '10.11.x.x', mask '255.255.255.128', numRef 0, numFail
0, flags 0xa6 }
2010-09-24 09:09:58.327: [GIPCHGEN][1089964352] gipchaInterfaceReset: resetting interface
'10.11.x.x', mask '255.255.255.128', numRef 0, numFail 0, flags 0xa6 }
2010-09-24 09:09:58.338: [GIPCHDEM][1089964352] gipchaWorkerCleanInterface: performing
cleanup of disabled interface 0x2aaaac2098e0 { host '', haName 'CSS_a2b2', local (nil), ip '10.11.x.x',
subnet '10.11.x.x', mask '255.255.255.128', numRef 0, numFail 0, flags 0x16d }
2010-09-24 09:09:58.338: [GIPCHTHR][1089964352] gipchaWorkerUpdateInterface: created remote
interface for node '<node2>', haName 'CSS_a2b2', inf 'udp://10.11.x.x:41486'
2010-09-24 09:09:58.338: [GIPCHGEN][1089964352] gipchaWorkerAttachInterface: Interface
attached inf 0xe2bd5f0 { host '<node2>', haName 'CSS_a2b2', local 0x2aaaac2014f0, ip
'10.11.x.x:41486', subnet '10.11.x.x', mask '255.255.255.128', numRef 0, numFail 0, flags 0x6 }
2010-09-24 09:10:00.454: [ CSSD][1108904256]clssnmSendingThread: sending status msg to all
nodes
Note: from above, ocssd.bin won't fail as long as there's at least one private network adapter is
working
L2. Log Sample When Private Network Adapter Restores
In a multiple private network adapter environment, if one of the failed adapters becomes restored:
ohasd.log
2010-09-24 09:14:30.962: [GIPCHGEN][1083025728]gipchaNodeAddInterface: adding interface
information for inf 0x2aaaac1a53d0 { host '', haName 'CLSFRAME_a2b2', local (nil), ip '10.11.x.x',
subnet '10.11.x.x', mask '255.255.255.128', numRef 0, numFail 0, flags 0x41 }
2010-09-24 09:14:30.972: [GIPCHTHR][1138145600]gipchaWorkerUpdateInterface: created local
bootstrap interface for node '<node1>', haName 'CLSFRAME_a2b2', inf
'mcast://230.0.1.0:42424/10.11.x.x'
2010-09-24 09:14:30.972: [GIPCHTHR][1138145600]gipchaWorkerUpdateInterface: created local
interface for node '<node1>', haName 'CLSFRAME_a2b2', inf '10.11.x.x:13235'
ocssd.log
2010-09-24 09:14:30.961: [GIPCHGEN][1091541312] gipchaNodeAddInterface: adding interface
information for inf 0x2aaab005af00 { host '', haName 'CSS_a2b2', local (nil), ip '10.11.x.x', subnet
2010-09-24 09:14:30.972: [GIPCHTHR][1089964352] gipchaWorkerUpdateInterface: created local
bootstrap interface for node '<node1>', haName 'CSS_a2b2', inf 'mcast://230.0.1.0:42424/10.11.x.x'
2010-09-24 09:14:30.972: [GIPCHTHR][1089964352] gipchaWorkerUpdateInterface: created local
interface for node '<node1>', haName 'CSS_a2b2', inf '10.11.x.x:10884'
information for inf 0x2aaab0035490 { host '<node2>', haName 'CSS_a2b2', local (nil), ip '10.21.x.x',
information for inf 0x2aaab00355c0 { host '<node2>', haName 'CSS_a2b2', local (nil), ip '10.11.x.x',
interface for node '<node2>', haName 'CSS_a2b2', inf 'mcast://230.0.1.0:42424/10.12.x.x'
attached inf 0x2aaab0035490 { host '<node2>', haName 'CSS_a2b2', local 0x2aaab005af00, ip
'10.12.x.x', subnet '10.12.x.x', mask '255.255.255.128', numRef 0, numFail 0, flags 0x46 }
interface for node '<node2>', haName 'CSS_a2b2', inf 'mcast://230.0.1.0:42424/10.11.x.x'
attached inf 0x2aaab00355c0 { host '<node2>', haName 'CSS_a2b2', local 0x2aaab005af00, ip
'10.11.x.x', subnet '10.11.x.x', mask '255.255.255.128', numRef 0, numFail 0, flags 0x46 }
0x2aaab00355c0 { host '<node2>', haName 'CSS_a2b2', local 0x2aaab005af00, ip '10.11.x.x', subnet
cleanup of disabled interface 0x2aaab00355c0 { host '<node2>', haName 'CSS_a2b2', local
0x2aaab005af00, ip '10.11.x.x', subnet '10.11.x.x', mask '255.255.255.128', numRef 0, numFail 0,
flags 0x66 }
0x2aaab0035490 { host '<node2>', haName 'CSS_a2b2', local 0x2aaab005af00, ip '10.12.x.x', subnet
cleanup of disabled interface 0x2aaab0035490 { host '<node2>', haName 'CSS_a2b2', local
0x2aaab005af00, ip '10.12.x.x', subnet '10.12.x.x', mask '255.255.255.128', numRef 0, numFail 0,
flags 0x66 }

Ora Net 1c

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ora Net 1c

Uploaded by

Copyright:

Available Formats

Still not quite sure then in the light of that why a node also requires a vip on top of the

Is it therefore possible to setup RAC / GNS without DNS or DHCP ?

Case 1: Single Private Network Adapter

eth1:1 Link encap:Ethernet HWaddr 00:16:3E:11:22:22

For 11.2.0.2 and above, v$cluster_interconnects will show haip info:

Case 2: Multiple Private Network Adapters

2.1. Default Status

eth1:1 Link encap:Ethernet HWaddr 00:16:3E:11:11:22

eth1:2 Link encap:Ethernet HWaddr 00:16:3E:11:11:22

eth6 Link encap:Ethernet HWaddr 00:16:3E:11:11:77

eth6:1 Link encap:Ethernet HWaddr 00:16:3E:11:11:77

eth7 Link encap:Ethernet HWaddr 00:16:3E:11:11:88

eth7:1 Link encap:Ethernet HWaddr 00:16:3E:11:11:88

Instance alert.log (ASM and database):

2.2. When Private Network Adapter Fails

eth1:1 Link encap:Ethernet HWaddr 00:16:3E:11:11:22

eth1:3 Link encap:Ethernet HWaddr 00:16:3E:11:11:22

eth7 Link encap:Ethernet HWaddr 00:16:3E:11:11:88

eth7:2 Link encap:Ethernet HWaddr 00:16:3E:11:11:88

eth7:3 Link encap:Ethernet HWaddr 00:16:3E:11:11:88

2.3. When Another Private Network Adapter Fails

eth7:1 Link encap:Ethernet HWaddr 00:16:3E:11:11:88

eth7:2 Link encap:Ethernet HWaddr 00:16:3E:11:11:88

eth7:3 Link encap:Ethernet HWaddr 00:16:3E:11:11:88

2.4. When Private Network Adapter Restores

eth6:1 Link encap:Ethernet HWaddr 00:16:3E:11:11:77

eth6:2 Link encap:Ethernet HWaddr 00:16:3E:11:11:77

eth7 Link encap:Ethernet HWaddr 00:16:3E:11:11:88

eth7:2 Link encap:Ethernet HWaddr 00:16:3E:11:11:88

eth7:3 Link encap:Ethernet HWaddr 00:16:3E:11:11:88

HAIP Log File

L1. Log Sample When Private Network Adapter Fails

2010-09-24 09:10:04.879: [ USRTHRD][1116531008] {0:0:2} Arp::sAnnounce {

2010-09-24 09:10:06.802: [ USRTHRD][1082325312] {0:0:2} VipActions::stopIp }

You might also like