X-Envelope-to: NOVELL@SUVM.BITNET
X-VMS-To: IN%"NOVELL@SUVM.BITNET"
X-VMS-Cc: JRD
Newsgroups: bit.listserv.novell
Date:         Mon, 13 Apr 1992 16:48:00 MDT
Reply-To:     Novell LAN Interest Group <NOVELL@SUVM.BITNET>
From:         Joe Doupnik <JRD@USU.BITNET>
Subject:      Re: Breakdowns

>In article <NOVELL%92041116060551@SUVM.ACS.SYR.EDU>, Larry.H.Bradley@NRC.CA
>writes:
>> A bus configuration for a network (e.g. thin ethernet, or ARCnet
>> bus) is more susceptible to problems than a star (10BaseT or normal
>> ARCnet) more due to cable problems than NIC problems. If a NIC just
>> plain dies, no problem in either event. If a NIC starts spewing out
>> garbage, then it will screw up a bus, and may screw up a start,
>> depending on what the concentrator can do. A typical ARCnet
>> concentrator doesn't have the ability to disconnect segments that
>> are causing problems. Most 10BaseT concentrators due.
>>
>> We don't use bus configurations EVER. (Well, hardly ever).
>>
>
>It should probably be noted here that running Ethernet doesn't preclude the use
>of a star like physical configuration with the addition of intelligent
>Multiport Repeaters. Then you can have the best of both worlds. Running
>Ethernet with cheap ethernet cards in a stable configuration where each office
>is on its own segment, and therefore more immune to the problems normally
>associated with the Bus Topology.

>Doing it this way, doesn't however stop a brain damaged NIC from jamming the
>network, but I believe you can get MPR's which are intelligent enough to
>isolate a jammed segment. Just like intelligent hubs.
>
>>
>> *------------------------------------+----------------------*
>> |Larry Bradley                       |    LARRY@VM.NRC.CA   |
>> |Communications Manager              | Larry.Bradley@NRC.CA |
>> |National Research Council of Canada |    LARRY@NRCVM01     |
>> |Networks Branch                     |                      |
>> |M60, Montreal Road                  | (613)993-0240        |
>> |Ottawa, Canada  K1A 0R6             | FAX:(613) 954-2561   |
>> *------------------------------------+----------------------*
>--
>==============================================================================
>|  Hamish Marson   <h.marson@waikato.ac.nz>                                  |
>|  Programmer (n/5), School of Computing and Mathematical Sciences           |
>|  University of Waikato,                                                    |
>|  Hamilton, New Zealand.                                                    |
---------------------
        I should add some recent local experiences here on the otherwise
sensible and correct comment that intelligent hubs for Ethernet (coax or
twisted pairs) can isolate malfunctioning nodes.
        The experiences are several. One lulu was an Ethernet adapter in a
Vista Terminal Server went halfway bad and put d.c. on the coax. No problem
until a DEC workstation nearby heard packets, decided the voltage levels
were slightly wrong and send out a JAM signal. This propagated through all
the multiport repeaters and onto the campus backbone. Down went the backbone.
This link now has a bridge, as you can well imagine.
        Other boards go half bad too, and their messing up cause them to
send JAM signals again. No amount of hubbing intelligence deals with this.
Crummy wiring leads to the same experiences, and that's true for my coax
AND twisted pair plants.
        A case last week was a person installed an old DEPCA board in a PC,
tried a Packet Driver, it didn't work (very old DEPCA board), and went off to
lunch. The backbone again ground to a halt. The PC was sending Runt pkts
as fast as it could go and dominating the backbone coax. Another bridge
went in the same day. Today there are no unbridged contacts with the main
backbone.
        Really bad boards can be dealt with by the hubs, but those cases seem
to be fewer than the not-too-bad ones, at least for me. Stubs on coax
eventually get found and their owners publicly humiliated, extra terminators
are impounded as well deserved booty, home made connections are replaced.
        I have commented at length to Net Management vendors ($$$ boys) that
their products do nothing, zero, zip, nada, to find such situations. Their
products work if the net works, and then that's a rather expensive toy to
be running. Phones have a habit of being rather prompt, if embarassing, alarms
for broken nets. My quick crutches happens to be a) Netwatch for a quick
view and then a b) plain electronic volt/ohm meter for on the spot checks.
The latter can be applied to live lines because it puts very little current
on the wires; wait for lulls in the pkt rate to get good readings, retest
with reversed red/black wires. Serious work means a TDR (need a good portable)
and a portable protocol monitor (the one we have weighs more than I do, almost).
        So my view has become intelligent hub ports (hard to find those
which are not) are great for wires disconnected from the hub itself, and not
a whole bunch more. Disconnecting a long wire at the far end can still let
reduced amplitude reflections propagate back through the hub/repeater and
cause mischief.
        Joe D.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU