https://bugzilla.novell.com/show_bug.cgi?id=752745 https://bugzilla.novell.com/show_bug.cgi?id=752745#c0 Summary: First connect after a reboot to a local IP address, takes a lot of time Classification: openSUSE Product: openSUSE 12.1 Version: Final Platform: x86-64 OS/Version: SLES 11 Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: maurizio.biletta@itacaservice.it QAContact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 After a reboot, the first time I try to connect (ex.: telnet to a port) to a local IP address (local interfaces, aliases, and any sort of non-loopback network interfaces) the session takes a lot of time to get in place. After the first attempt finishes, every subsequent attempt just work fine. The problem shows up also if I just wait few minutes (more than 10) from an attempt to another (I guess some sort of cache expires...). The problem shows up only on local IP address. If I try to connect to an IP of another box, everything works fine. I can see from a strace, that the execution is waiting for the "connect" syscall to finish. The problem is visible on SLES11 SP2 and on openSUSE 12.1 The problem is not showing up on older releases of SLES (such as SLES11 SP1). I can't say if the problem persists on olther releases of openSUSE. Reproducible: Always Steps to Reproduce: 1. Fresh reboot of the system 2. Telnet to the eth0 IP address to a CLOSE port 3. Repeat step 2 Actual Results: The "connection refused" message, takes a lot of time to show up. Every other attempt, just work fine. NOTE: My eth0 ip is: 10.0.0.1 and "1222" is a CLOSED port on my box. # time telnet 10.0.0.1 1222 Trying 10.0.0.1... telnet: connect to address 10.0.0.1: Connection refused real 0m21.076s user 0m0.000s sys 0m0.000s # time telnet 10.0.0.1 1222 Trying 10.0.0.1... telnet: connect to address 10.0.0.1: Connection refused real 0m0.003s user 0m0.000s sys 0m0.000s Expected Results: I expect that the first attempt just takes the same time of the second (or at leat just few milliseconds more because of a non cached ip/dns). Definitely, not 20 seconds more. This issue does not usually represent a real problem, except in certain case. For example, in my configuration, I have several oracle database in cluster with HAE. After I upgraded to SP2, all my listener resources in the cluster, were just failing because of a "timeout" event. As a workaround I changed the timeout meta parameter with a higher value just to get everything back to work. I supose that this problem could directly affect various aplication, expecially cluster resources and monitoring tools. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.