Slow telnet logins

[Terrence]

We are experiencing slow telnet logins on 3 of 10 HPUX servers. One is 11i & the other is 11i V2.

It started after we had to shut down our primary DNS server. I updated the resolv.conf on all ten servers so they have correct valid DNS server ip's. 7 of the servers work fine. But 3 (The most important 3 of course) now take 15-60 seconds to provide a login prompt.

I added retrans 2000 and retry 1 to the resolv.conf on both since that should eliminate the DNS servers as the culprit. It had no effect.

Any ideas on what else it could be? The servers are in (separate) 2 node service guard clusters. Both of the servers (rp4440's) in one cluster (HPUX 11i) are affected. In the other cluster (rp7420's & 11iV2) only the active node displays the problem. The passive node provides the login prompt immediately.

[Michael Steele_2]

Hi

Add 'set -xv' to /etc/profile and .profile files to see where the hang up is occurring.

Verify the new nameserver is on the same subnet. If it's on a different subnet then this is likely to be the problem.

[Terrence]

The delay is happening before the login prompt shows up, so the profiles don't enter into it. Once you've entered your id and password it proceeds just fine.

Don't think the DNS needs to be on the same subnet as the HPUX server. 7 of ten servers work just fine and they aren't on the same subnet as the DNS either.

[Patrick Wallek · Accepted solution]

On the problematic servers how is the nslookup speed?

Can you correctly look up the same device by both name and ip address?

Perhaps a stop / start of inetd so it can reread DNS configuration. This should not be necessary, but it may help.

[Fabio Ettore]

Hi,

it's most likely to be something about the reachability of DNS server.
Do all HP-UX systems have the same default gateway? Even if it's not sure to be useful, try traceroute to DNS server onto a system which is working fine and one which is not working fine.

HTH.

Best regards,
Fabio

[Michael Steele_2]

I agree about running a traceroute and checking the delay and latentcy between hops.

It may also be something as simple as speed and duplex on those particular ports. You can also check these with the network admins.

[Terrence]

Thanks to everyone for playing.

Patrick gets the prize.

I had considered recycling inetd but it seemed too unlikely. However when a 1 star olympian suggested it, I couldn't resist.

We had tried trace route and it really revealed nothing. All ten servers were configured basically the same so logically it had to be something particular to the server, not the network or DNS.

For those with a similar problem in future that is not DNS related (though I believe our issue was triggered when we had to shut down the primary DNS);

inetd -k
/sbin/init.d/inetd start

[Terrence]

Thread closed