ping slow to "start" when contacting a Unix server from Linux (SuSE)

[TwoProc]

When I use ping to contact a Unix server (HPUX, Linux) by name, it's slow to start. It takes about 3 seconds or so before it begins. If I use "ping -n" it doesn't do this. To me - It looks like the target server is obviously wanting to reverse lookup my address before it processes the ping request. If I use "ping -n" or just ping the same machine but by IP address and not by name, it starts giving me data right away. Also, if I ping a Microsoft Server, even by name - it starts right away, with no delay (probably meaning no rarp attempt). Also, if I ping out to the internet, like hp.com - there is no delay there either, and I'm pretty sure HP won't let me put my IP address in their host file even if I wanted to... :-)

As another data point - it happens whether or not I have iptables rules turned on or flushed free on my client SuSE workstation, so it's not a *firewall* time out/retry delay for dns or anything like that (which was my first thought).

OK.... I'm pretty sure I could fix this by adding my host name to the hosts file on each server, or to dns maybe. But why? I don't remember having to do this before for the ping command, but I remember having to do this for ssh, or in the old days - telnet.

Can anyone tell me why this is happening on my Unix servers? Easy fix in nsswitch.conf, resolv.conf maybe?

[Steven Schweda]

> To me - It looks like the target server is
> obviously wanting to reverse lookup my
> address before it processes the ping
> request.

What target server? Unlike some highly
sophisticated protocols, say, FTP and Telnet,
"echo" is normally handled internally to the
inetd. ("cat /etc/xinetd.d/echo".) My
opinion is no guarantee, but I'd expect it to
be pretty simple/stupid, and to have no
interest whatsoever in your name.

Your "ping" program may do a reverse look-up
(or something else pointless) on something,
which may be slow for some reason. Does
something like "strace" tell you what it's
doing when it pauses?

If you're worried about DNS sloth, you could
run some tests using nslookup (for names and
numbers, at each end), to see what doesn't
work well. Knowing what doesn't work can
make guessing a solution easier.

[Rob Leadbeater]

Hi TwoProc,

I've no idea why this is happening, but you could use a network sniffer to try and figure it out.

Wireshark (Ethereal) or tcpdump will probably be quite enlightening.

You might also want to let us know what version of Suse you're using...

Cheers,

Rob

[TwoProc]

Hey Rob, thanks for the reply - it's Suse 10.3.

[Ciro Iriarte]

The ping issuer (your suse workstation) tries to resolve the server's IP. Try adding it to your local /etc/hosts.

On the man for ping in SLES10, there's no flag to explicitly ask for name resolution of targets, but maybe that changed on newer versions. Check for bash aliases that modify the default ping command.

[Matti_Kurkela]

Just for clarification:
Steven referred to TCP/UDP "echo" service, which is normally provided by (x)inetd. It is not at all related to the "ping" command.

The normal ping command uses ICMP Echo-Request ("ping") and ICMP Echo-Reply ("pong") packets, which are normally handled at the kernel level.

MK