John WatsonMessages: 5095Registered: January 2010 Location: Global Village

Senior Member

The same subnet is not an issue, though using 192.x.x.x for VIPs may (according to the RFC that describes VIPs) not be allowed and definitely causes problems with some Oracle 10g tools.
I would fix Java first, how do you know that some tools other than vipca do not need it? Then use vipca, which does not care about non-routable 192 addresses. And what did you do with the crs_setperm utility? Did you run it at all?

And one other thing - CentOS is not something that Oracle has ever tested their software on, nor is it supported. I have personally been involved in a few escalations where an Oracle customer attempted to use CentOS believing it was an exact copy of Redhat, only to find out that there are in fact differences.

Thank you both for your interest,
yes, I am well aware of the order and meaning of all the commands and options (i am not a DBA though). The single instance database is
successfully serviced throught the eth0 interface which was selected as public during the clusterware installation. The second
application cannot be started as the application VIP cannot be started at first hand. Apparently, CentOS 5.4 where successfully
transparent during the cluvfy checkups. Oracle is 10g2.
Mr Watson, my log files do not show anything clearer than my [vip].log: Interface eth1 checked failed (host=esm1)
If you can guide through some other logging mechanism or trace file, I can bring you some more info. I know such problems are very
general in nature and I do not expect a straight forward answer.
Thanx again for you interest.

Just a word of caution - cluvfy successfully running does not mean that Oracle will work - it's expected to be run on supported OS's - not everything. Still, the fact that it did work may mean you are OK - but there is a lot more behind the scenes going on that cluvfy doesn't check.

Can you manually plumb the second IP address to the nic? Are there any messages in the /var/log/messages?

What point release of 10gr2 are you running? (10.2.0.3, 10.2.0.4, etc.)

John WatsonMessages: 5095Registered: January 2010 Location: Global Village

Senior Member

Did you use the crs_setperm utility to set the permissions on the VIP appropriately?
Or have you fixed Java, so that you can use vipca?
And what error is in the crsd.log file, when you try to start the VIP?

Yes crs_setperm was used correctly as owner:root and user oracle to have read&execute
proviledges. I am not at the production site at the moment due to weekend but as I remember
crsd.log does not provide something helpful, I would have spotted it.. I reproduced some parts
of the environment in VMWARE at home and the application VIPs are created successfully on the
second interface. I will search for differences in the configuration on Monday and report back.
Hope you are still here.

I managed to spot the source of the problem. It lies in the racgvip shell script where a ping is done to the default gateway
in order to determine if the interface is up. The problem was that the firewall was blocking the ICMPs thus an error code
is returned and the interface is marked useless. For the time being I comment the "ping" line (as I know the interface is up)
resolving the issue. Have to check with the net admin tomorrow.