Delays in netstat, telnet, ftp connection responses 1

[garygressel]

On some Redhat 7, Solaris, and HP boxes, I've/others have noticed occasional delays in responding to connection requests for ftp and telnet. We get connected but no login prompt for a few/many seconds. Also, the netstat -a command will show several connections, hang, and then continue on.

The delay doesn't impact existing connections. However, we can have multiple windows up trying to connect via telnet and/or ftp, and existing telnet sessions issuing a "netstat -a" command, all in a hung state. Then, on their own, they all come clear at the same time. The netstat -a command is the only command we've noticed exhibiting this behavior on an existing connection.

I've seen this for some time on some Sun boxes but others never show the behavior. Now I'm seeing it on my Redhat 7 at home and in talking with other SA's, they've seen it on other boxes too.

Something one SA noticed...although netstat -a shows the problem, we can issue a simultaneous netstat -na on another session and not see the problem.

What's the common thread??? At first I thought inetd/xinetd, until the nestat command showed up. The -na/-a points towards DNS but doing telnet/ftp via IP or DNS makes no difference---both delay.

Thanks in advance for thoughts/suggestions!
Gary Gressel

 

[ElgisRamon]

I guess it´s your name resolution: Your servers are tryn to authenticate or log your accesses, then try to get the client's name from the DNS... and that is slooooow. If the client tries to connect using an IP address, the server tries to get a DNS name nowadays... then it´s slow. I have exactly the same problem when my Internet linkn goes down!... Try changing your name resolution order in your servers and setting names for your clients in thir hosts files.

 

[garygressel]

Ah, well that stinks. When we noticed the -na/-a differences in netstat we knew somehow it was related to name lookups but I didn't realize telnet/ftp tried to do reversing as well.

I did a quick test here at work and it seems to fix the problem. Unfortunately here at work I'm looking at 13,000 PCs, all DHCP'd, so I guess "live with it" will be our motto. I can't wait to get home though and fix things there!

Some additinal checking and I understand why some boxes did and some boxes did not exhibit this behavior. Some had different /etc/nsswitch.conf configurations causing additional lookups.

At least we now understand why! Thanks!