LDP
/
old-www
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
old-www/LDP/LG/issue56/eyler.html

776 lines
16 KiB
HTML
Raw Permalink Blame History

<!--startcut ==============================================-->
<!-- *** BEGIN HTML header *** -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML><HEAD>
<title>ping LG #56</title>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#0000AF"
ALINK="#FF0000">
<!-- *** END HTML header *** -->
<CENTER>
<A HREF="http://www.linuxgazette.com/">
<H1><IMG ALT="LINUX GAZETTE" SRC="../gx/lglogo.jpg"
WIDTH="600" HEIGHT="124" border="0"></H1></A>
<!-- *** BEGIN navbar *** -->
<IMG ALT="" SRC="../gx/navbar/left.jpg" WIDTH="14" HEIGHT="45" BORDER="0" ALIGN="bottom"><A HREF="dennis.html"><IMG ALT="[ Prev ]" SRC="../gx/navbar/prev.jpg" WIDTH="16" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="index.html"><IMG ALT="[ Table of Contents ]" SRC="../gx/navbar/toc.jpg" WIDTH="220" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../index.html"><IMG ALT="[ Front Page ]" SRC="../gx/navbar/frontpage.jpg" WIDTH="137" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="http://www.linuxgazette.com/cgi-bin/talkback/all.py?site=LG&article=http://www.linuxgazette.com/issue56/eyler.html"><IMG ALT="[ Talkback ]" SRC="../gx/navbar/talkback.jpg" WIDTH="121" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../faq/index.html"><IMG ALT="[ FAQ ]" SRC="./../gx/navbar/faq.jpg"WIDTH="62" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="flechtner.html"><IMG ALT="[ Next ]" SRC="../gx/navbar/next.jpg" WIDTH="15" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><IMG ALT="" SRC="../gx/navbar/right.jpg" WIDTH="15" HEIGHT="45" ALIGN="bottom">
<!-- *** END navbar *** -->
<P>
</CENTER>
<!--endcut ============================================================-->
<H4 ALIGN="center">
"Linux Gazette...<I>making Linux just a little more fun!</I>"
</H4>
<P> <HR> <P>
<!--===================================================================-->
<center>
<H1><font color="maroon">ping</font></H1>
<H4>By <a href="mailto:pate@gnu.org">Pat Eyler</a></H4>
</center>
<P> <HR> <P>
<!-- END header -->
<DIV
CLASS="SECTION"
><H1
CLASS="SECTION"
><A
NAME="AEN3"
></A
></H1
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN5"
>An Overview of ping</A
></H2
><P
>Ping is an diagnostic tool for verifying connectivity between two hosts
on a network. It sends ICMP Echo Request packets to a remote IP address
and watches for ICMP responses. The author of the initial version of the
ping program that we use today was Mike Muss. Many other people have
tweaked, rewritten, and variously abused ping since then.
</P
><P
>The name ping itself is somewhat colorful. Some people will claim
that it is an acronym standing for the Packet INternet Groper, this is not
the case. Ping was named after the sound of a sonar tracking system.
There is even a story claiming that a system administrator wrote a script
which repeatedly pinged a host on the network and made an audible
<SPAN
CLASS="QUOTE"
>"pinging"</SPAN
> alert for each success. The system administrator
was then able to methodically go through his network checking BNC
connectors until he found the dodgy connector that had been plaguing his
network &#8212; when the noises stopped, he'd found his culprit.
</P
><P
>Ping used to be a very good indicator of a machines ability to receive
and send IP packets in general. If you could ping a host, you could also
make an ftp or http connection. With the wider advent of packet filtering
for security, this is becoming less true. Many firewalls explicitly
disallow ICMP packets on the twin grounds that,
<P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> <P
>1) people don't need to know what your internal network looks
like,
</P
>
</TD
></TR
><TR
><TD
> <P
>2) and, any protocol can be used to launch an attack, even ICMP.
</P
>
</TD
></TR
></TBODY
></TABLE
><P
></P
>
Deciding whether to let ICMP through your firewall is a tough call to
make. There are certainly good uses for ICMP, but there are also attacks
based on ICMP (e.g., the <SPAN
CLASS="QUOTE"
>"Ping of Death"</SPAN
>, which used
oversized ping packets to overload the IP stack of the target &#8212; with
often spectacular results). If you choose to allow ICMP into your network
make sure you've thought about the repercussions.
</P
><P
>There are additional flavors of the ping command that have been
written for other purposes. Among the most common is the fping command.
Which was written to ping a range of addresses, and is commonly used in
network scanners and monitors like saint and mon (both of which are
covered in this chapter). Another variation is the Net::Ping module,
which provides a perl implementation of Ping functionality that can easily
be used from within a script without calling an external program. You
might use the script something like this:
<DIV
CLASS="EXAMPLE"
><P
><B
>Example 1. Using Net::Perl</B
></P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>#!/usr/bin/perl -w
use strict;
use Net::Ping;
my $host = $ARGV[0];
my $p = Net::Ping-&#62;new("icmp");
if ($p-&#62;ping($host)) {
print "$host is alive.\n";
} else {
print "$host is not reachable.\n";
}
</PRE
></TD
></TR
></TABLE
></DIV
>
</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN21"
>ping at Work</A
></H2
><P
>Ping is most often used without additional arguments and shut off with
a <B
CLASS="KEYCAP"
>Ctrl</B
>&#8211;<B
CLASS="KEYCAP"
>c</B
>. The results look like
this:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>[pate@cherry pate]$ ping mango
PING mango (192.168.1.1) from 192.168.1.10 : 56(84) bytes of data.
64 bytes from mango (192.168.1.1): icmp_seq=0 ttl=255 time=0.5 ms
64 bytes from mango (192.168.1.1): icmp_seq=1 ttl=255 time=0.3 ms
64 bytes from mango (192.168.1.1): icmp_seq=2 ttl=255 time=0.3 ms
64 bytes from mango (192.168.1.1): icmp_seq=3 ttl=255 time=0.3 ms
64 bytes from mango (192.168.1.1): icmp_seq=4 ttl=255 time=0.3 ms
64 bytes from mango (192.168.1.1): icmp_seq=5 ttl=255 time=0.3 ms
--- mango ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 0.3/0.3/0.5 ms
[pate@cherry pate]$
</PRE
></TD
></TR
></TABLE
>
This output can split into three sections. The first section, the single
line starting with the word <SPAN
CLASS="QUOTE"
>"PING"</SPAN
>, shows an overview of the
command. The second section, the lines beginning with <SPAN
CLASS="QUOTE"
>"64
bytes"</SPAN
> show a running tally of the responses received. The third
section, everything after the line <SPAN
CLASS="QUOTE"
>"--- mango ping statistics
---"</SPAN
>, shows a summary of the results. In this case, the results
are good, none of the packets were dropped and they were all passed
fairly quickly.
</P
><P
> This example also shows another important point, you should not rely
on a single packet to diagnose your network. A series of five or ten is
much better, as you can count up to 40% data loss as congestion on a
network, and even a single packet dropped can be attributed to a busy host
on the other end.
</P
><P
>There are several useful options to the ping command. These are
summarized in the following table:
<DIV
CLASS="TABLE"
><P
><B
>Table 1. Ping Command Options</B
></P
><TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
CELLSPACING="0"
CELLPADDING="4"
CLASS="CALSTABLE"
><THEAD
><TR
><TH
ALIGN="LEFT"
VALIGN="TOP"
>Switch</TH
><TH
ALIGN="LEFT"
VALIGN="TOP"
>Description</TH
></TR
></THEAD
><TBODY
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="PARAMETER"
><I
>-c</I
></TT
>
<TT
CLASS="VARNAME"
>count</TT
>
</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
> <P
>Stop sending and receiving packets after
<TT
CLASS="VARNAME"
>count</TT
> packets.
</P
>
</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="PARAMETER"
><I
>-d</I
></TT
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
> <P
>Set the SO_DEBUG on the socket used.
</P
>
</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="PARAMETER"
><I
>-f</I
></TT
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
> <P
>Send the packets as fast as possible. (flood)
</P
>
</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="PARAMETER"
><I
>-i</I
></TT
>
<TT
CLASS="VARNAME"
>wait</TT
>
</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
> <P
>Set an interval of <TT
CLASS="VARNAME"
>wait</TT
> seconds between
packets.
</P
>
</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="PARAMETER"
><I
>-I</I
></TT
>
<TT
CLASS="VARNAME"
>&#9001;device&#9002;</TT
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
> <P
>Sets the output interface.
</P
>
</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="PARAMETER"
><I
>-l</I
></TT
>
<TT
CLASS="VARNAME"
>preload</TT
>
</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
> <P
>Sends <TT
CLASS="VARNAME"
>preload</TT
> packets as fast as
possible, then drops back to normal mode.
</P
>
</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="PARAMETER"
><I
>-n</I
></TT
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
> <P
>Don't look up hostnames, just give IP addresses.
(numeric)
</P
>
</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="PARAMETER"
><I
>-p</I
></TT
>
<TT
CLASS="VARNAME"
>pattern</TT
>
</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
> <P
>Specify up to 16 bytes of <SPAN
CLASS="QUOTE"
>"pad data"</SPAN
> to be
sent with the packet.
</P
>
</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="PARAMETER"
><I
>-q</I
></TT
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
> <P
>Output only summary lines. (quiet)
</P
>
</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="PARAMETER"
><I
>-r</I
></TT
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
> <P
>Don't use routing tables to send the packet, just drop it
out the local interface.
</P
>
</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="PARAMETER"
><I
>-R</I
></TT
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
> <P
>Set the Record Route option.
</P
>
</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="PARAMETER"
><I
>-s</I
></TT
>
<TT
CLASS="VARNAME"
>packetsize</TT
>
</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
> <P
>Set the number of data bytes sent to
<TT
CLASS="VARNAME"
>packetsize</TT
>.
</P
>
</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="PARAMETER"
><I
>-T tsonly</I
></TT
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
> <P
>Sends a ping with the timestamp option.
</P
>
</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="PARAMETER"
><I
>-T tsandaddr</I
></TT
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
> <P
>Collects timestamps and addresses
</P
>
</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="PARAMETER"
><I
>-T tsprespec</I
></TT
>
<TT
CLASS="VARNAME"
>[host1 [host2 [host3 [host4]]]]</TT
>
</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
> <P
>Collects timestamps and addresses from prespecified hops.
</P
>
</TD
></TR
></TBODY
></TABLE
></DIV
>
</P
><P
>These options can be combined to make ping even more helpful. One
thing that you cannot see is that the ping command used in the previous
section is likely to take several seconds to run and report back. Using
the <TT
CLASS="PARAMETER"
><I
>-f</I
></TT
> switch will reduce the time
spent waiting for the command. Combining this with the <TT
CLASS="PARAMETER"
><I
>-c 10</I
></TT
> and the <TT
CLASS="PARAMETER"
><I
>-q</I
></TT
> switches will give you quick results and
easier output to read:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
> <TT
CLASS="PROMPT"
>[root@cherry /root]# ping -c 10 -fq mango
PING mango (192.168.1.1) from 192.168.1.10 : 56(84) bytes of data.
--- mango ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.9 ms
[root@cherry /root]#
</TT
>
</PRE
></TD
></TR
></TABLE>
<P> Note: The -f and -l switches can only be used by root, as they can cause
serious network degradation if misused.
</P
></TD
></TR
></TABLE
></DIV
><P
>It might be of some benefit to test larger packets, using <TT
CLASS="PARAMETER"
><I
>ping -c10 -s 1024 -qf</I
></TT
> will send larger packets
for you. This can be especially useful where you suspect problems with
fragmented packets.
</P
><P
>To see the route that your packets are traversing, you can use
<TT
CLASS="PARAMETER"
><I
>ping -c10 -R</I
></TT
>. This command produces
the following output:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
> <TT
CLASS="PROMPT"
>PING tbr.nailed.org (206.66.240.72) from 192.168.1.10 : 56(124) bytes of data.
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=0 ttl=239 time=217.2 ms
RR: 192.168.1.10
216.41.39.90
serial0.mmgw32.bos1.Level3.net (209.244.39.25)
208.218.130.22
166.90.184.2
so-6-0-0.mp2.NewYork1.level3.net (209.247.10.45)
137.39.52.10
180.ATM7-0.BR2.NYC9.ALTER.NET (152.63.22.229)
lo0.XR2.NYC9.ALTER.NET (137.39.4.175)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=1 ttl=239 time=1940.8 ms (same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=2 ttl=239 time=250.6 ms (same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=3 ttl=239 time=230.3 ms (same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=4 ttl=239 time=289.8 ms (same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=5 ttl=239 time=1261.4 ms (same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=6 ttl=239 time=469.4 ms (same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=7 ttl=239 time=1272.3 ms (same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=8 ttl=239 time=353.1 ms (same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=9 ttl=239 time=1281.1 ms (same route)
--- tbr.nailed.org ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 217.2/756.6/1940.8 ms
</TT
>
</PRE
></TD
></TR
></TABLE
>
</P
><DIV
CLASS="NOTE"
><P
>
Note: The record route option specified by the <TT
CLASS="PARAMETER"
><I
>-R</I
></TT
> switch is not honored by all routers and
hosts. Further, it contains only a limited space to hold router
addresses, traceroute may be a better tool for identifying the path
packets follow through a network.
</P
></TD
></TR
></TABLE
></DIV
><P
>The ping command is a very useful tool for your troubleshooting kit,
and should not be overlooked.
<P
><EM>This article is copyright 2000, Pat Eyler and New Riders Publishing.
It is presented under the
<A HREF="http://www.opencontent.org/openpub/">Open Publication License</A>, with
no additional terms applied. It is a draft version of a section of the book
</EM>Networking Linux: A Practical Guide to TCP/IP<EM>, which will be published
by <A HREF="http://www.newriders.com">New Riders Publishing</A> in the
winter.</EM>
<!-- *** BEGIN copyright *** -->
<P> <hr> <!-- P -->
<H5 ALIGN=center>
Copyright &copy; 2000, Pat Eyler and New Riders Publishing<BR>
Published in Issue 56 of <i>Linux Gazette</i>, August 2000</H5>
<!-- *** END copyright *** -->
<!--startcut ==========================================================-->
<HR><P>
<CENTER>
<!-- *** BEGIN navbar *** -->
<IMG ALT="" SRC="../gx/navbar/left.jpg" WIDTH="14" HEIGHT="45" BORDER="0" ALIGN="bottom"><A HREF="dennis.html"><IMG ALT="[ Prev ]" SRC="../gx/navbar/prev.jpg" WIDTH="16" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="index.html"><IMG ALT="[ Table of Contents ]" SRC="../gx/navbar/toc.jpg" WIDTH="220" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../index.html"><IMG ALT="[ Front Page ]" SRC="../gx/navbar/frontpage.jpg" WIDTH="137" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="http://www.linuxgazette.com/cgi-bin/talkback/all.py?site=LG&article=http://www.linuxgazette.com/issue56/eyler.html"><IMG ALT="[ Talkback ]" SRC="../gx/navbar/talkback.jpg" WIDTH="121" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../faq/index.html"><IMG ALT="[ FAQ ]" SRC="./../gx/navbar/faq.jpg"WIDTH="62" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="flechtner.html"><IMG ALT="[ Next ]" SRC="../gx/navbar/next.jpg" WIDTH="15" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><IMG ALT="" SRC="../gx/navbar/right.jpg" WIDTH="15" HEIGHT="45" ALIGN="bottom">
<!-- *** END navbar *** -->
</CENTER>
</BODY></HTML>
<!--endcut ============================================================-->
Reference in New Issue View Git Blame Copy Permalink