internet broadcast addresses
Joe Kelsey
joe at fluke.UUCP
Sat Jun 23 05:05:54 AEST 1984
Yes - I have found Berkeley's choice to be quite annoying. Their use
of this blatantly non-standard bug can cause problems if you are trying
to connect heterogenous machines on the same network. We have 5 VAXen
running 4.2, 4 SUN-2s running 4.2, a VMS VAX and an IBM 3083 sharing
the same Ethernet and trying to send mail, files, etc., back and forth.
In addition, the UNIX VAXen each send out the rwho packets once every
minute. So, that is 5 broadcast packets per minute, each with the
internet destination address of 192.9.200.0 (we use net number
192.9.200), or approximately one packet every 12 seconds. These
packets go out over the Ether with Ethernet addresses of all one's, so
everyone HAS to receive them and then decide if they are important or
not. The SUNs don't participate in the rwho junk, so they ignore the
packets. Similarly, the IBM seems to safely ignore the packets. On
VMS, we are running Compion's Access-I software. This is a very well
thought out package, with perhaps the only major problem being that it
was *modularly designed*. No, modularity is great and wonderful, but
if you stick too closely to modularity in network design, especially in
the interface between layers, you may lose big. When Access receives
the packet, the network interface module strips the Ethernet cruft off
the packet before passing it to IP. IP says "who is this host
192.9.200.0? I never heard of them before!" and proceeds to send out
two response packets: one is an ICMP message to the sending host saying
"I don't know who this 192.9.200.0 is" and a retransmission of the
packet it just received. Well, the NIM can easily send out the ICMP
message because it already knows the ethernet address of the sender,
but it can't retransmit the rwho packet since it doesn't know what the
ethernet address is. So, the NIM blithely sends out an ARP trying to
find out who 192.9.200.0 is!
I found out about this behavior when we first booted the IBM software.
We had console tracing turned on and noticed a message about ARP adding
a translation for the VMS machine several times ber minute. At first I
thought that the VMS ARP implementation was screwed up and just sending
out constant ARP packets, but then I looked at some detailed traces
from the Access software (you can get INCREDIBLE levels of tracing from
Access - more than you EVER wanted to know!) and discovered this
side-effect of modularity! The real problem is that IP doesn't know
that the packet came in as a broadcast packet, and the NIM doesn't
realize that IP is retransmitting a packet that it received as a
broadcast as a specific address packet. If IP *knew* that the packet
with the 0 address was a broadcast packet, it could just throw it away
and all would be fine. If the NIM *knew* that the only broadcast
packets it wants to see are.
Sigh. Aren't non-standards fun! At least it all works!
/Joe
More information about the Comp.unix.wizards
mailing list