Telnet sessions...

[Chris Bidwell]

I'm curious as to know why or what would be causing a telnet session to take so long to connect? I'm connecting from a Window 2000 Prof Workstation to my HPUX 11 box and it takes a minute or longer for an acknowledgement of a telnet session just to prompt for a username and pw. Thanks

[harry d brown jr]

Chris,

Do a test, instead of using the name of the host, use the IP and see if it is any faster. Also, are you using NIS or NIS+ on your HP?


live free or die
harry

[Sanjay_6]

Hi Chris,

It could be bacause the workstation is unable to resolve the ip address easily. If you are trying to telnet using the system name, use the ip address and try. Also try to look at the route/gateway the workstation is using to connect to the server. you can trace the route from the workstation to the server using "tracert" command under windows.

Hope this helps.

Regds

[James R. Ferguson]

Hi Chris:

If you are running DNS then it sounds like you are experiencing reverse-name-lookup timing issues. Declare your clients in /etc/hosts or DNS.

Regards!

...JRF...

[Chris Bidwell]

Thanks for the assist guys, when I'm telnetting to my server, I'm inputting the IP address and note the hostname, so I know it's not a DNS issue. I did do a tracert to the server and it's going through 7 hops to get to it's destination. I have done this before, and don't remember it taking so long.

[harry d brown jr]

Chris,

7 hops? Sounds like a bunny rabbit issue :-)) What does the traceroute show in delays between hops?

live free or die
harry

[Sanjay_6]

Hi Chris,

If the tracert is showing it going 7 hops, your problem lies over there. You have to look at the routes and the gateways configured between your workstation and the server.

Hope this helps.

Regds

[Krishna Prasad]

Is the telnet response the same to any host?

From the workstation does it take this long to telnet to all the hosts on the same subnet?

Is there a different workstation you can telnet from that is on the same subnet of the workstation? Maybe it is the workstation that is having the problem.

Also from your last response something in your network may have changed. A new router, a router removed, a router config change? IP change of the workstation or Server?

[Chris Bidwell]

That is definitely possible...I do know that I'm on token ring (That's what I get for working at IBM I suppose, hehe), and my HPUX box is Ethernet. So I know I'm going through that crossover as well. I was previously having some problems relating to NIS. But I that I've resolved those issues....

[harry d brown jr]

Chris,

Token ring? Don't you mean "Lord of the Rings", by JR Tolkien. You sure have one Hobbit of a problem.

live free or die
harry

[Chris Bidwell]

Yeah, I know what you mean...if it were up to me, I'd have fiber ran through here, but you know how it goes!

[Roger Baptiste]

hi,

Another way to confirm that the problem is with the hops is to , do a telnet into the
server from the same server. i.e after you telnet from the PC to the server and get into the system, do a telnet again into the same system.

HTH
raj

[Ron Kinner]

I assume telnet sessions to other devices on the same subnet take just as long so we can rule out a bad box?

Are we talking Cisco routers here? IBM shops with Cisco routers tend to use priority queuing on WAN links because SNA traffic can't tolerate delays. This works fine for SNA but everyone else gets sidetracked until the SNA express gets through. You might talk to your router guy and maybe he would be willing to put telnet sessions into the highest priority queue (or at least a higher queue than the default). Telnet is usually a low bandwidth application so you shouldn't slow down the SNA traffic enough to amount to anything.

Just a little background info on Priority Queuing so you can sound like you know what you are talking about when you talk to the router guy: There are four queues: High, Medium, Normal, and Low. The router always empties the High queue as soon as possible. If it has time it will then empty the Medium queue, recheck the High queue and then if it still has time it will work on the other two, always checking the higher queues for new traffic. During heavy traffic it's not uncommon for applications in the lower queues to timeout because the router doesn't empty their queues fast enough. Other routers probably do the same thing but I only speak Cisco.

Another note: Ping and Trace may be in a higher queue from Telnet so that a ping or trace looks good whereas a telnet session takes forever. This would probably be a dumb thing to do but you can do it and there might even be a valid reason for it such as preventing OpenView from generating false alarms.

Ron

[Chris Bidwell]

Outstanding! I didn't even think of that. I will check into that and see how the priorities are set. I'm also having a problem FTPing into the same server. I'm trying to do a binary transfer of some HPUX drivers and I cannot connect. I have FTP and TFTP enable in network services, is there something else that I'm missing?

[Ron Kinner · Accepted solution]

Telnet to the box and do a netstat -a and see if you are listening for ftp (port 21).

tcp 0 0 *.ftp *.* LISTEN



Might be easier to just ftp from there back to your home box and do a get instead of a put. It's a lot easier to get ftpd working on a local machine than on one on the other side of a s-l-o-w telnet session.

Since FTP is a high traffic protocol it's probably set for Normal or Low priority and your router guy is not going to want to change that. You might ask him when is the best time to try it. Hopefully there are some lulls in traffic.

FTP can also run into grief because of firewalls. It uses port 21 to set up and control the transfer but the actual data comes from port 20. This is hard for some firewalls to understand.

Ron