Telnet connection slow

[trilok_pvp]

Hi

when i try to connect HP unix server through telnet from remote windows PC. It takes lot of time to show the login prompt. All DNS servers are working fine and able to do nslookup. But to get the login prompt it takes time. last week it is working fine, suddenly we are facing this problem in 2 unix servers.

[likid0]

Check your system resources, cpu , memory , network, and see if any of them is saturated.
You can use:

sar
glance
swapinfo -atm
vmstat
top
etc

And allways check syslog:

/var/adm/syslog/syslog.log

[Steven Schweda]

> [...] HP unix server [...]

Not a complete description. Even simple
"uname -a" output would say more.

> [...] All DNS servers are working fine and
> able to do nslookup. [...]

Of what? Where? The usual DNS problem is on
the Telnet server, when a (reverse) look-up
of the client's IP address fails.

Evidence (actual commands with their actual
output) can be more helpful than your vague
interpretations and conclusions (like "able
to do nslookup").

> [...] we are facing this problem in 2 unix
> servers.

For which clients? Can you Telnet from one
of the HP-UX systems to itself?

An ITRC Forum search for keywords like, say,
telnet slow
should find many similar threads with all the
usual suggestions.

[trilok_pvp]

Hi

when i try to connect telnet from the same PC. it is connecting immediatly. From windows PC it is connecting slow.

I tested by adding the client system ip in etc\hosts on HP box. Then it is connecting fast.

But it is not possible to add all the clients in the hosts file

pls suggest

[Steven Schweda]

> I tested by adding the client system ip in
> etc\hosts on HP box.

We call that "/etc/hosts" in UNIX-land.

> Then it is connecting fast.

Sounds like a DNS problem. Find the people
who control your DNS servers, and ask them to
add all the Windows systems to the DNS data.

What should work is this, on the HP-UX
system (that is, on the Telnet server):

nslookup Windows_system_IP_address

If that is slow, then you can expect Telnet
connections to that server to be slow.

The Telnet server program (telnetd) wants to
know the name of the client. It tries to
get it. If that inquiry works quickly, then
you get connected quickly.

[trilok_pvp]

We are having 2 domains, earlier we are having a single DNS server for both domains.

Now 2 domains 2 DNS server's are placed. HP unix servers are placed in one domain and we are accessing the server by windows clinet PC, PC's are placed in another domain.

When we try nslookup for client PC in HP Box's it is not resolving the name.

[Steven Schweda]

> When we try nslookup for client PC in HP
> Box's it is not resolving the name.

And that probably explains the slow-Telnet
problem.

> We are having 2 domains, earlier we are
> having a single DNS server for both
> domains.

Apparently, some one made a mistake when
making this change.

Did you expect someone here to solve your DNS
problem? (Someone with no useful information
about your network or its DNS configuration,
old or new?)

[Mel Burslan]

From this conversation, it sounds like when your second domain controller was taken into the operation, it was made the primary DNS server, at the same time it does not have the same name resolution information as your old one has.

Your server is lookin up to the new domain controller as the DNS server first and it can not find the information it needs to make the telnet connection happen. This is where you are waiting. When it times out, it most probably is going to the secondary DNS server, which is your old domain controller with all the necessary IP address information and finding the stuff it needs and establishing the telnet session.

The person who needs to fix this is the people who are in charge of your AD domain controllers. Or you can enter all the connecting windows clients into your server's /etc/hosts file. Choice is yours. Better solution is to have a correctly working DNS server, not a half-ass implementation. But knowing how long it takes to perform such changes by groups other than your own, you might opt for the /etc/hosts solution to fix your own problem.

Hope this helps

[UVK]

From what all you said this sounds like a DNS issue to me, I would involve those who made changes with the DNS. if you did the DNS update you might have made a mistake somewhere ..verify ur changes