Reproducing a timeout issue can be tricky. Often, they occur around the same time and are caused by heavy network traffic. You could re-create the issue by flooding your network or your NICs and try to connect. A lot of applications and app servers will retry the connection and it will be successful. I believe that is why there is another MOS doc that explains how you can remove these informational messages from your alert.log. I wouldn't recommend doing that though.
Do you really want do know how to reproduce this? Or, are you asking me to show proof?
Currently, I'm having these kind of problems in some databases in my developer environment.. I spent some time investigating, but I didn't find a solution yet. I read many documents(MOS), and try other things...
Fatal NI connect error 12537, connecting to:
TNS for Linux: Version 126.96.36.199.0 - Production
Oracle Bequeath NT Protocol Adapter for Linux: Version 188.8.131.52.0 - Production
TCP/IP NT Protocol Adapter for Linux: Version 184.108.40.206.0 - Production
Time: 18-SEP-2013 22:20:03
Tracing not turned on.
Tns error struct:
ns main err code: 12537
TNS-12537: TNS:connection closed
ns secondary err code: 12560
nt main err code: 0
nt secondary err code: 0
nt OS err code: 0
opiodr aborting process unknown ospid (6536) as a result of ORA-609
The only thing that I notice that these errors star to raise after maintenance plan window at 22:00 PM
2013-09-18 22:00:00.253000 -03:00
Setting Resource Manager plan SCHEDULER[0x3109]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
Starting background process VKRM