Quote:>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
-p command takes a really long time to execute:
Quote:> I'm dong an arp -a, or netstat -p, and its taking a really long time
> to finish on one our boxes, a solaris 7 ultra-5. It works fine on
> the other solaris boxes here. I do a truss on the command, a see
> that its sleeping after listing one entry in the arp table. Than after
some
> time, it lists another line in the table, and goes back to sleep. This
> keeps going on til the entire arp table is listed. It takes about 100
seconds
> to complete and there are only 8 entries in the arp table!!
> The same situation when I do a netstat -a. But if I do a netstat -an
> it works fine. So I'm quite puzzled here. The reason I ask is that I
think
> this has something to do when I first telnet onto the box - it takes an
> awfully long time for the login prompt to come, but after that everything
is
> okay. This only occurs on this box, whereas I can telnet to the other
boxes
> fine. All the boxes are on the SAME hub/switch. Any ideas anyone????
It is a reverse DNS issue. I've run into this problem many many times.
When you telnet to a Solaris/SunOS box, it does a reverse DNS lookup on
the IP address you are coming in from. If you are coming from an IP that
does not lookup, it takes some time to fail and timeout and then go ahead
and allow the login program to proceed.
The reason you see the same delay with the netstat commands you are
running, such as netstat -a, but not with netstat -an, is that the 'n'
flag tells it to not try to reverse lookup the IP's that it lists in the
output, just to list them as IP's.
If only one of your Solaris boxes is doing this, then you most likely
have something set up wrong in the nsswitch.conf or in the resolv.conf
files, keeping the reverse lookups from happening.
Otherwise, you may not have all your client machines in DNS where the
Solaris box can resolve them. Or with a small enough network, get them
into the Solaris /etc/hosts file.
We had this problem on a wider scale, and we lessened it by making sure
our internal and external DNS servers had a response for ALL the IP's in
our range, even if they weren't in use.
--
Jason Baugher
Virtual Adept Professional Consulting Services
1406 Adams St.
Quincy, IL 62301
(217) 221-5406
http://baugher.pike.il.us/virtualadept
by