[comp.dcom.lans] Ethernet/Optical link locking up

gotch@rhea.trl.oz.au (Rob Gotch) (07/06/90)

Our Ethernet looks like this:

Building 1                 Building 2     Building 3     Building 4
   #                          #              #              #
   |                          |              |              |	
   |                          |              |              |
   @-----derep======derep-----@              |              |
   |                          |              |              |
   |                          |              |              |
   |                          #              |              |
   |                                         |              |
   @-----derep=====================derep-----@              |
   |                                         |              |
   |                                         |              |
   |                                         #              |
   |                                                        |
   @-----derep====================================derep-----@ 
   |                                                        |
   |                                                        |
   #                                                        #

| is thickwire backbone
@ is ANC-20 dual port transceiver (MAU)
- is transceiver (MAU) cable
= is duplex optical fibre
# is 50 ohm termination

Our problem is that, occasionally, one of the repeated links locks up.
Close inspection of the equipment reveals that the ANC-20 MAU's at each
end of the affected link show the collision detect light hard on.

As soon as we disconnect one of the AUI cables to either MAU the
collision lights go out and upon reconnecting the AUI cable the link
begins to operate normally - until next time :-(.

As far as I know, we have built our network well within the design spec,
in terms of cable lengths, fibre loss budget, etc. The problem has 
occured on two of the three links so it may not be a single faulty
device. The impression I get is that the fault is in one of the ANC-20's
although this would implicate more than one device.

Has anyone else experienced similar problems? If so, how were your
problems fixed? Does anyone have any ideas about how to identify and 
eliminate our problem?

Thanks in advance, Rob.
------------------------------------------------------------------------
Rob Gotch (r.gotch@trl.oz.au)  | And the son of God died, which is immediately
Financial & Computing Services | credible because it is absurd. And buried, he
Telecom Research Laboratories  | rose again, which is certain because it is
770 Blackburn Rd Clayton Vic   | impossible.         Tertullian 160 AD.

spurgeon@sirius.cc.utexas.edu (Charles Spurgeon) (07/09/90)

In article <1864@trlluna.trl.oz> gotch@rhea.trl.oz.au (Rob Gotch) writes:
>
>Our problem is that, occasionally, one of the repeated links locks up.
>Close inspection of the equipment reveals that the ANC-20 MAU's at each
>end of the affected link show the collision detect light hard on.
>
>As soon as we disconnect one of the AUI cables to either MAU the
>collision lights go out and upon reconnecting the AUI cable the link
>begins to operate normally - until next time :-(.
>

I recall this happening at Stanford a couple of years ago.  The
symptom was that a DEREP used inside a building between two coax
segments would lock up.  It's been a while, but I seem to recall the
collision light on the MAUs being on solid, as you report.  The MAUs
in the configuration were Cabletron ST-500s.

We tracked the problem down to excessive collisions causing the DEREP
and its attached MAUs to somehow get into what looked like jabber
latch mode.  Power cycling the MAUs (by removing the AUI cables) would
reset things and all was well until the next giant broadcast storm in
the building caused enough collisions to set off the lock up scenario.
Upon investigation, we found several misconfigured hosts with IP
forwarding problems sending huge numbers of broadcasts onto the
building's wire.

One of the folks at Stanford found a way to duplicate the repeater
lock up with a test set up in the lab, using thin wire cable and
several different types of transceivers.  If you injected packets into
the system, and then unterminated the thin net segments in the right
order, you could get the DEREP and its (non-DEC) MAUs to lock up.

The DEREP problem was "solved" by using DEC H4000 transceivers with
the DEREPs.  As I recall, we were told that only the H4000s are
guaranteed to work with DEREPs.


Charles Spurgeon                     |                                  |
UTnet Network Information Center     | spurgeon@emx.utexas.edu          |
University of Texas at Austin        | ...!cs.utexas.edu!ut-emx!spurgeon|
-------------------------------------------------------------------------