roy@alanine.phri.nyu.edu (Roy Smith) (07/14/90)
By watching with tcpdump, I can see that when an occassional IP
object gets configured with the wrong broadcast address, each time it sends
a broadcast packet, a flurry of arp requests are generated by various
machines on the network. I sort of understand what is going on, but not
exactly. We use a hostpart of .0.0 for broadcasts, but once in a while a
misconfigured box pops up with .255.255, which other machines then try to
arp for.
What I don't understand is 1) why they bother to arp at all and 2)
why only some machines do it? As I understand it, when a machine wants to
send an IP packet, it has to arp to find out what link-level address to put
in the ethernet dst field. But why should a machine try to do an IP->ether
address resolution just because it receives an rwho packet sent to the
wrong IP broadcast address? An rwho requires no response, so there really
isn't any reason to need to know where it came from. As for the second
question, what is it about some machines that makes them arp for bad
broadcasts and others not? In our particular case, we have a bunch of
Sun-3's, all running SunOS-3.5.2. One of them runs a generic kernel, and
that's the only one that arps in response to .255.255 packets. All our
other Suns run customized kernels, but the only customizations are to
delete device drivers they don't need; nothing (that I know of) has been
changed in the networking code, yet they don't arp .255.255's. Why not?
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"hedrick@athos.rutgers.edu (Charles Hedrick) (07/14/90)
broadcasts cause arp storms because of a combination of over friendliness and confusion. Suppose you've got a system that things the broadcast address is 128.6.0.0 (an old 4.2 system). Now you have a system that sends using the correct broadcast address, which for my local subnet is 128.6.4.255. The old system will see this packet, since it's a broadcast. The IP input code will look, not recognize it as a broadcast, and assume that 128.6.4.255 is a host. Since most IP code is capable of acting as a gateway, it will assume somebody is trying to use it as a gateway, and thus try to forward the packet to 128.6.4.255. This will cause it to send an ARP request for 128.6.4.255. Another scenario is that you send a broadcast for 255.255.255.255 (the correct generic local broadcast). An old host may not recognize this as a broadcast. It will think this is a packet destined for network 255. Since it doesn't have a route to network 255, it may try to send back an ICMP unreachable. This will cause it to ARP the original sender. There are all sort of scenarios like this. They are complicated by various bugs. E.g. one implementation ended up sending ICMP errors to a broadcast address. What's really amusing is if somebody answer an ARP for 128.6.4.255 with a response giving Ethernet address ff.ff.ff.ff.ff.ff. In some sense this is right. However this can result in all sorts of mischief.
k2@charly.bl.physik.tu-muenchen.de (Klaus Steinberger) (07/16/90)
roy@alanine.phri.nyu.edu (Roy Smith) writes: > By watching with tcpdump, I can see that when an occassional IP >object gets configured with the wrong broadcast address, each time it sends >a broadcast packet, a flurry of arp requests are generated by various >machines on the network. I sort of understand what is going on, but not >exactly. We use a hostpart of .0.0 for broadcasts, but once in a while a >misconfigured box pops up with .255.255, which other machines then try to >arp for. At first: Not the .255.255 boxes are misconfigured, all of youre other stuff is misconfigured. The official broadcast address is a host-part of all ones! There was an bug in Berkeley 4.2 networking code, which led to those all zero addresses! > What I don't understand is 1) why they bother to arp at all and 2) >why only some machines do it? As I understand it, when a machine wants to >send an IP packet, it has to arp to find out what link-level address to put >in the ethernet dst field. But why should a machine try to do an IP->ether >address resolution just because it receives an rwho packet sent to the >wrong IP broadcast address? An rwho requires no response, so there really It's because IP-forwarding is normally enabled in the kernel. And some machines think, if they are configured to all zeros broadcast, and they see a all ones broadcast, that they must forward it. So they try to arp' the address. >isn't any reason to need to know where it came from. As for the second >question, what is it about some machines that makes them arp for bad >broadcasts and others not? In our particular case, we have a bunch of >Sun-3's, all running SunOS-3.5.2. One of them runs a generic kernel, and >that's the only one that arps in response to .255.255 packets. All our >other Suns run customized kernels, but the only customizations are to >delete device drivers they don't need; nothing (that I know of) has been >changed in the networking code, yet they don't arp .255.255's. Why not? Maybe, you have disabled IP-forwarding in the customized kernels. I think you should have a close look to all your equipment, if it's able to use the .255.255 broadcast, and then you should switch to it. It's hard to do, because you have to change all configurations in one shot, but you will not run into trouble, if new machines are installed. Most networking software is derived from Bsd 4.3, so the broadcast will be configurable, but all defaults to .255.255. Sincerely, Klaus Steinberger Klaus Steinberger Beschleunigerlabor der TU und LMU Muenchen Phone: (+49 89)3209 4287 Hochschulgelaende, D-8046 Garching, West Germany BITNET: K2@DGABLG5P Internet: k2@charly.bl.physik.tu-muenchen.de
jbvb@VAX.FTP.COM (James B. Van Bokkelen) (07/18/90)
RFC 1122 says that 1) machines with only one IP address shall not act as routers by default, 2) nobody shall forward or issue ICMP error messages in response to packets that arrive via an IP or MAC level broadcast, and 3) that everyone must be cognizant of the old 4bsd IP broadcast address as well as the correct (RFC 950) one. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901