ICMP As A Diagnostic Tool?

[Mi...@udel.edu.uucp]

Miles,

I suggest you invite co-BBNer Mike Brescia (X3662) for a beer and learn
all about ICMP uses and abuses. This is not a frivolous suggestion.

Dave

[Mi...@udel.edu.uucp]

Vint,

Well, I don't know about that, although I (modestly) claim to have invented
the term "ping" (Packet InterNet Groper) circa 1979. Mike Brescia at BBN,
Hans-Werver Braun at U Michigan and others have a lot of grease under their
fingernails.

Having said that, I can't imagine an internet (small i), ISO or any other,
viable in even the weakest sense without something like ICMP built into
the protocol stack at outset. I even have to resist saying that agian
for emphasis.

Dave

[mi...@brl.arpa.uucp]

BRL uses the "ping" program, which transmits ICMP Echo Request packets
with the data field set to a process ID, a sequence number, and
a struct timeval (time in seconds and microseconds), plus patterns
to pad out any extra length (a command-line parameter).

[The BRL ping program is now provided as /etc/ping in 4.3 BSD UNIX].

We use this tool for network troubleshooting *extensively*.
Many Lab managers even know how to run PING, so that they can
get more information about why connections to far-away hosts
may be working poorly.

We also have a tool (PINGPOLL) that we use (within the campus net only)
to monitor round-trip-times and packet loss, as well as a very simple
ICMP-based routing daemon (ROUTER).

ICMP is invaluable -- it provides a level of visibility of activity
at the link level that is very helpful.

Oh yes, another good use to to watch the effects of varying packet
size. Good for finding IP reassembly bugs (in days gone by), and
various interesting performance problems (back-to-back etherpackets, etc).

The "ping -f" (aka FLOODPING) option is very good for stress-testing
a particular network, gateway, host, whatever. As the name suggests,
it releases ICMP echo request packets as fast as it can.

Another version of PING that we have uses the IP option "record route",
which is useful to see where the packets are traveling.

Very useful, and amusing to watch.

Best,
-Mike

[tsuc...@gateway.mitre.org.uucp]

From Miles Fidelman:
> It's been my observation that ICMP provides some useful functionality for
> isolating and diagnosing internetwork problems - e.g. by timing pings,
> looking at what percentage of echos come back, source routing packets via
> specific paths, route recording, etc.
>
> It strikes me that the lack of similar functionality for the OSI world may
> lead to an OSI internet in which significant classes of problems can not
> be fault isolated. I find this a rather scary thought.

It is not true that the OSI world lacks similar functionality. ISO IP
ISO 8473) has error messages which covers everything ICMP does except
Redirect, Echo, and Timestamp, and Information.

The Redirect function in ISO is in the ES-IS (End System to Intermediate
System) routing protocol, DP 9542. The Echo function can be accomplished
by using partial source route with the "echoing" machine on the list.
(This if the distant machine is an IS.) To an ES, a transport connection
can be used much to the same, if not better, effect.

In addition, ISO is working on a suite of management functions and
protocols which will allow for much more detailed and flexible management,
debugging, etc., of networks. I can't speak for all layers, but in ANSI
X3S3.3 (Network and Transport layers) we are actively working on this.

Paul Tsuchiya tsuc...@gateway.mitre.org
The MITRE Corp. tsuc...@mitre-gateway.arpa

[g...@spam.istc.sri.com.uucp]

The Redirect function in ISO is in the ES-IS (End System to Intermediate
System) routing protocol, DP 9542. The Echo function can be accomplished
by using partial source route with the "echoing" machine on the list.
(This if the distant machine is an IS.) To an ES, a transport connection
can be used much to the same, if not better, effect.

I believe one advantage to the way we do ICMP echoes is that, for all
the implementations I have heard of, processing of the echo reply takes
place in kernel space instead of user space. The use of a user program
waiting on a transport connection to trap echoes and generate echo
replies requires scheduling of that process. If the system is loaded,
it will lessen the accuracy of the round-trip time.

In case anyone is interested, I have some war stories describing the use
of ICMP for fault isolation. (Example: discovering that you have lost
your gateway, and finding a new one.) They're too long to reprint here,
but might provide some amusing reading.

--gregbo