Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3291
  • Last Modified:

ORA 12170 TNS connect timeout

Has anyone come across this in OAS 10g R2?

Oracle Application Server 10gR2 on Red Hat ES 4u4
Oracle 10gR2 RAC (2-node) on Red Hat AS 4u4

The Application Servers are on different subnet from the RAC database and hence on separate switches.

During Installation of Identity Management, my installation abruptly fails. Checking the logs revealed connect timeout error. Then telnet to the database machine on any port from the app server times-out, although ping works. In fact telnet from the application server to anything else times-out. Telnet is only successful after reboot.

However, when I moved the app servers onto the same subnet, hence same switch, as the RAC, the installation completed successfully.

Now I need to move the App servers back into the DMZ where they are intended for. So I'm running the chgiphost.sh script and I'm hiting the same problem as I did during the installation.

It appears that some process in the installation is killing ability of Linux to talk to other machines on ports. Has anyone come across this? Is this firewall or software - Oracle or Linux?

More symptoms:
I can still telnet from the RAC to the App server even though the app server cannot talk to the database server
Don't forget I can ping the RAC server from the app server but telnet or ssh timeout.

Don't forget connectivity is durable when all servers are placed on the same subnet.

The remote database is definitely listening

I'm considering moving my database servers to teh DMZ. Has anyone done this without security risks? I believe you could create port rules to protect your database servers.

0
Richard Olutola
Asked:
Richard Olutola
2 Solutions
 
anand_2000vCommented:
it might be a simple issue of routing. please request in http://www.experts-exchange.com/Community_Support/ to shift this question to networking
0
 
bpeterseCommented:
Re: last question.  Keep your DB behind all firewalls and put only the app server - or a portion thereof - on the DMZ.  If possible, put the Portal and SSO on it's own server in the DMZ and keep everything behind the firewall.  You could use port rules to protect your DB servers - but you can use the same logic to keeping it behind the firewall.  It adds one more layer of security to keep your data integrity intact.

0
 
Richard OlutolaConsultantAuthor Commented:
This was indeed a connectivity issue as I suspected.

I believe this should be deleted because it would not be of any use to anybody the fact that I was working where the network infrastructure is in a questionable state.

How do I delete this.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now