dcf@COMET.LCS.MIT.EDU (David C. Feldmeier) (05/30/86)
I am doing measurements of the interpacket arrival times for the gateways on a 10 Mbit token ring at MIT, especially our gateway to the ARPANET because it carries the most traffic. While doing these measurements, I noticed that about 35% of the packets arriving at the gateway were only 300 microseconds after the previous packet. Since this is faster than the gateway receives or a single host transmits, I was curious about what was causing it. The problem turned out to be with the 30 VAXs on the ring that run Berkeley 4.2 Unix. A gateway would send a routing packet to the broadcast address and all of the VAXs would not recognize the destination address and forward the packet to the default gateway, which is the gateway to the ARPANET. As soon as the broadcast packet was transmitted, all of the VAXs would simultaneously begin forwarding packets to the gateway as quickly as possible until they got through. The token ring has a data link layer packet acknowledgment, so the VAXs would simply continue in order around the ring with successful host dropping out. Eventually, all would succeed (about 0.13 seconds) and the net would return to normal. The interarrival time of 300 microseconds is because the transmission time of the routing packet is 300 microseconds. The ring was 100% loaded with back-to-back packets for the entire 0.13 seconds. I suspect that on an Ethernet, this would be a bigger mess because of the multiple collisions. -Dave Feldmeier
james@CLS.LCS.MIT.EDU (James W. O'Toole Jr.) (05/31/86)
From: dcf@comet.lcs.mit.edu (David C. Feldmeier) Subject: Avalanche I suspect that on an Ethernet, this would be a bigger mess because of the multiple collisions. I wouldn't expect multiple collisions, just one: then the ``randomness'' in the backoff times ought to break the symmetry. This is an interesting way to get collisions though. Usually the biggest cause of Ethernet collisions is the transmission of a long packet. If two other hosts become ready to transmit during that time, they will both begin transmitting shortly after the long packet's end. Curious, the gateway's broadcast acts as a synchronizing event, so that the independent transmission times assumption fails. --Jim
BILLW@SU-SCORE.ARPA (William "Chops" Westfield) (05/31/86)
Im pretty sure that I've seen thi problem discussed before - I think as a way to trash microvaxes (somebody sends out an rwhod broadcast packet to the correct (all 1's) address. N Sun workstations think that the broadcast address address ought to be 0, and that the -1 address packet needs to be forwarded (which they all do). the resulting massive and lengthy collision seems to break the DEQNA...) This is the major reason why it is suggested that ip forwarding be turned off on all unixes that aren't actually gateways... BillW -------
chris@GYRE.UMD.EDU (Chris Torek) (06/01/86)
Indeed, it seems to me that IP forwarding should default to `off' on most Unix machines. It also makes sense to disable it if the machine has only one IP interface; this is what 4.3 does. For anyone who has not already done it, IP forwarding may be turned off as follows: 1) binary-only: The first write turns it off in the running kernel; the second turns it off in the boot image. % su [password] # adb -w /vmunix /dev/kmem ipforwarding/W 0 ipforwarding: 1 = 0 ipforwarding?W 0 ipforwarding: 1 = 0 [type ^D here] 2) source: Find the declaration of `ipforwarding' in /sys/netinet/ip_input.c; change it to be initialised to zero. Chris