Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!rice!sun-spots-request
From: bernard@pleiades.oz.au (Bernard Wilson)
Newsgroups: comp.sys.sun
Subject: Re: ethernet hardware "etiquette"
Keywords: Networks
Message-ID: <5092@brazos.Rice.edu>
Date: 16 Feb 90 05:56:52 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 55
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 46, message 5

We have both Suns and a microVAX which are not as yet on the same Ethernet
network. I have cross posted the article below in the hope of gaining
useful information.

					Bernard Wilson

In article <17590@megaron.cs.arizona.edu>, leonard@cs.arizona.edu (Aaron Leonard) writes:
---------------------------- START OF TEXT ------------------------------------
I have no wish to start a holy war here.

BUT it is my simple observation that Suns are poor neighbors to have on an
Ethernet.  (Another way of putting this might be: VAXclusters are too
delicate to coexist happily with lusty, rambunctious Suns.)

I have never seen proof of the oft-repeated rumor that Suns "cheat" on the
9.6 ms Ethernet retransmit time.  I do know, however, that if you are
running a Local Area VAXcluster that shares a large, variegated Ethernet
with Suns, you should be wary of the following aspects of reality:

1. A few Suns running NFS can swamp the Ethernet very quickly.  I don't
want to get into the technical details here, but due to some rather
fast-and-loose design decisions in NFS, you will find that colliding NFS
traffic will produce a degenerate situation in a hurry.

2. Sloppy TCP/IP code residing on Suns can cause frequent network
meltdowns.  Specifically, Suns are notorious for behaving poorly when
confronted by IP broadcast addresses different from what they expect.
More precisely, just a handful of Suns which use the 0's broadcast and
which run RIP (which alas seems to be the default), will generate feedback
loops quite capable of destroying the network, when confronted by address
queries for the 1's broadcast.  (Note: Suns are not the only machines
which exhibit this problem, merely the most virulent.)

On my campus, we have experienced frequent network meltdowns, typically
associated with Suns and their allies caught in a feedback loop of some
sort.  Such events were frequently highlighted by members of Local Area
VAXclusters undergoing "voluntary" CLUEXIT bugchecks when they found that
they couldn't maintain SCS contact with eachother. 

We have lessened the frequency and severity of these tragic occasions via
the following techniques:

1. Put Suns behind IP routers whenever possible.  In other words, get them
OFF of the same Ethernet from your VAXen (and from each other.)

2. Increase the RECNXINTERVAL SYSGEN param on your NI VAXcluster nodes to
something like 120 seconds.   This makes them better able to weather
broadcast storms without committing hara kiri.

I do not intend to raise the issue of the morality of the Suns' behavior,
but only to stress the need for proper prophylaxis when your "share
needles with them" as it were. 

Aaron
------------------------------ END OF TEXT ------------------------------------