rjberke@skvax1.csc.ti.com (RICHARD BERKE -- COMMUNICATIONS ENGINEERING) (09/08/89)
I'm trying to understand the valid, per-protocol uses of broadcasting on a local ethernet. I'd appreciate either specific purposes described, or suggestions on where I can read up on the topic. We have a multi-campus, MAC-bridged ethernet, with a single TCP/IP network. We have currently about 1300 TCP/IP nodes, with other (DECNET, XNS, IPX) system types filling the rest of 8,000 nodes. No overt implementations of sub-netting are in use (at least not to my knowledge.) I've been seeing growing bursts of ethernet broadcasts, with the type of ARP, sent out to our network broadcast address: 128.247.255.255. This is other than the expected ARP traffic of stations looking for ethernet resolution of their intended individual target nodes. I suspect that our well intentioned community have products performing tasks which they aren't directly aware of, and there may be non-optimal answers used for system installation parameters. Can anyone out there shed some light on this? Thanks, Richard Berke Texas Instruments Plano, TX rjberke@skvax1.csc.ti.com
romkey@asylum.sf.ca.us (John Romkey) (09/08/89)
It's probably an system running an old Berkeley UNIX TCP that's getting packets sent to the IP broadcast address but not recognizing them as such and then, thinking it's a router, trying to forward them, finding their for its same subnet, and ARP'ing for them. One solution is to make sure that all your systems running Berkeley have the variable ipforwarding in the kernel set to 0 to disable routing. - john
Bruce.Orchard@SCARECROW.WAISMAN.WISC.EDU (Bruce Orchard) (09/09/89)
Our campus network has 2 programs that regularly generate IP
broadcasts:
1. RIP, which broadcasts routing information to port 520.
The protocol is described in RFC 1058.
2. RWHO, which broadcasts a list of the users logged in on
a system. I don't know of any reference about it other
than the code--it was part of Berkeley 4.2.
The excessive ARP packets you see probably arise from some
nodes using 0 for the broadcast address (following Berkeley
4.2) and others using all 1's (following RFC 919).
The ARP's arise as follows:
1. Node A broadcasts a packet to x.x.255.255.
2. Node B, which thinks the broadcast address is
x.x.0.0, receives the packet and decides the packet
is neither a broadcast packet nor one addressed
to itself. Therefore it attempts to forward it
to node x.x.255.255, so it uses ARP to get its
address.
The reverse also happens.
I would like to see at least 2 code changes in node B:
1. It would recognize both addresses as broadcasts.
2. It would check the Ethernet destination address
and never forward a packet that was addressed to
the Ethernet broadcast address.
Bruce Orchard
University of Wisconsin-Madison