jam@RADC-LONEX.ARPA (09/19/88)
> tmallory@PARK-STREET.BBN.COM writes: > > incredibly obnoxious thing to do! > > Opinion: If a reply is sent, then the best response is to insert the IP > address of the interface over which the packet was received in the source > address field of the reply. > > cire@cisco.com: > > Actually, I've found use for sending out broadcast pings. It can be > very usefull when you are at a node in an internet that for one > reason or another seems to not hear anymore. Say you are the net > administrator and don't have a lot of time. Can anyone hear? Throw > out a broadcast ping and see what you get back. The information can > be very useful in a gross sort of way. Gag! Obnoxious is right, I agree with Tracy. There really isn't any need to flood areas of the network like that with potential ping responses. An administrator should be permanantly imprinted with a copule of hosts to ping, preferably one on and one off the local node. That has always been the quickest way for me to find if the node is down, or if we just lost both the lines out of it. Usually the node is down, ever since BBN 'upgraded' the equipment... The same stands for broadcast messages on an ethernet off a major internet. Why bother to decipher the information coming back? Just hit a host or two in order to see if your backbone is still operational. But on a local ethernet, you aren't dealing with the expense of flooding the area with packets (unless your net has several thousand computers plugged in...) The only potential use that I really see for a broadcast ping, and only on a small local network, is for a facility that wants to keep track of the current state of each host. A modified ping program could provide an up/down display for each computer out there. Have I missed any other major possibilites? Joel jam@radc-lonex.arpa, jam@etn-wlv.eaton.com
cire@CLASH.CISCO.COM (09/20/88)
Okay. I agree. Broadcast pings are generally a bad idea and we should change implementations to ignore them. Flooding is a bad idea. What I was relating earlier was based on past observations of several production networks I've lived on (not administered). I observed that there were situations where an overworked net administrator needed to establish that some portion of an internet is functional. This is usually under extreme time pressure. It is also on an internet composed primarily of ethernets which grew together in a rather random fashion. Under these circumstances perhaps the broadcast pings are usefull. On well administered networks where the net admins are intimately familar with well known hosts on each of the network components broadcasts would clearly be inappropriate. What I was talking about is what I've seen to be more the norm. Don't get me wrong. Broadcast Pings and other related phenomena can be really obnoxious. I agree with that. -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941
murayama@Cs.Ucl.AC.UK (Yuko Murayama, +44-1-387-7050 ext.3695) (09/22/88)
I, for one, vote for broadcast/multicast ping. Broadcast ping is a totally different concept from ping with a unicast address in the sense that you don't have to know what objects are there. It is very tempting to use it for configuration detection. You can find out not only active objects but also what shouldn't exist. Yuko
brescia@PARK-STREET.BBN.COM (Mike Brescia) (09/23/88)
It seems we have started one of those "tastes great!" - "less filling!"*
arguments again.
Should every station reply to a broadcast of some kind?
NO: it causes massive collisions.
YES: it helps manage the net by finding formerly unknown stations and
diagnosing problems caused by heavy bursts of traffic
Perhaps you should put a broadcast detector in your copy of ping, so that it
will only send one packet, instead of one per second, as its default. The
main point is that you do not want to have the massive collisions occur while
people are really trying to get work done.
Also, I think that the NO answer works best for connection protocols like TCP,
and that the YES answer may be useful for datagram protocols like ICMP/ECHO or
UDP/RWHO.
Mike
*Apologies to people who don't see U.S. television ads; this refers to a
series of commercials for a 'lite' malt beverage which allege there are 2
partisan groups which favor it, for different reasons. (I could start a whole
new argument about the benefits/curses of beer ... but that belongs on another
mailing list.)dupuy@douglass.columbia.edu (Alexander Dupuy) (09/25/88)
As someone pointed out earlier, if responses to broadcast ICMP packets are disallowed, we'll have to come up with a new way of determining the network mask. But it is true that if all the hosts on a network respond, you have instant congestion. Perhaps a compromise is in order. Leave the requirement that hosts not respond to broadcast ICMP packets, but make a specific exception for gateways (what does the gateway requirements RFC say about this?) saying that they may respond to properly formed broadcast ICMP packets. Presumably, the number of gateways on a net is much less than that of hosts, so the congestion problem is not too great. And if you have a need to determine your netmask, you ought to have a gateway on the net (what's the point of subnetting a standalone net?). Is this too simple to really work? @alex -- inet: dupuy@columbia.edu uucp: ...!rutgers!columbia!dupuy
roy@phri.UUCP (Roy Smith) (09/25/88)
dupuy@douglass.columbia.edu (Alexander Dupuy) writes:
-> Leave the requirement that hosts not respond to broadcast ICMP packets,
-> but make a specific exception for gateways [...] if you have a need to
-> determine your netmask, you ought to have a gateway on the net (what's
-> the point of subnetting a standalone net?).
What if your gateway is down? Just because you're cut off from the
rest of the world doesn't mean you should be prevented from booting your
diskless nodes.
--
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"