[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference netcad::hub_mgnt

Title:	DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:	Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:	NETCAD::COLELLADT

Created:	Wed Nov 13 1991
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4455
Total number of notes:	16761

587.0. ""OPEN" on 90C thinwire strand brings down LAN" by NWD002::KOPEC_ST (Squash:Racketball::Chess:Checkers) Tue Dec 28 1993 15:47

I was recently talking with a DEC customer in AK who had his 
LAN come down *hard* when a network administrator tried placing a 
terminator at the end of a thinwire strand off of a DECrepeater 90C but he 
did not install it securely.

This thus created an "open" which literally stopped his business for the day.

It was my understanding that the DECrepeater 90C was designed to segment 
off a "bad" strand of thinwire, whether the cause was due to an open, a 
short, a babbling transceiver, or other.  Note that the repeater is in 
standalone mode, ie not in a hub.

Is this a known problem with the 90C?
Was there a firmware upgrade which was meant to prevent this? 

Thx, Stan

    PS  We are working with the customer to get rid of his thinwire
    backbone and go to a managed hub environment with 10BT drops however I
    would still like to know the answer to the above.  thx!

T.R	Title	User	Personal Name	Date	Lines
587.1	maybe...	CGOS01::DMARLOWE	dsk dsk dsk (tsk tsk tsk)	`Wed Dec 29 1993 13:44`	16
	I have run 90Cs in hub and standalone with open ports and never experienced this kind of problem. The only thing I can think of is the length of coax is causing the 'open' at the bad terminator to be reflected as something between an open and a short at the 90C. This would cause the 90C to repeatedly segment and reconnect the port. During the segmenting process the 90C must see 64 consecutive collisions which are also passed to every port and the hub or side port (I think). Try adding a meter or two of coax and see if that cures the problem with the bad terminator. The other thing I've seen is a connection that wasn't perfect and would cause an intermittant connection. This caused massive runt packets to be created and passed on to the backbone (no bridge in between). dave
587.2		NWD002::KOPEC_ST	Squash:Racketball::Chess:Checkers	`Wed Dec 29 1993 15:11`	6
	Dave, did the massive runt packets bring the whole LAN down hard in your scenario? Thx, Stan
587.3	not bad enough	CGOS01::DMARLOWE	dsk dsk dsk (tsk tsk tsk)	`Wed Dec 29 1993 16:51`	5
	No because it was very intermittant but since every SER was 'repeated' onto the backbone, it took them awhile to find the source of the problem. dave
587.4	bent terminator, not "open", brought down 90C LAN	NWD002::KOPEC_ST	Squash:Racketball::Chess:Checkers	`Wed Dec 29 1993 21:53`	13
	Just got word from the Field engineer on the resolution of the problem. Unfortunately, they had determined which segment was bad and disconnected it before the Sniffer was added so they couldn't get a closer look but... The one thing that seemed to bring the network to its knees when troubleshooting was creating heavy traffic such as booting a satallite node. Portions of the network were physically isolated and satellites rebooted to cause failures. When it was determined which segment was causing the problem it was disconnected. The next day a Sniffer and a TDR were brought in. The Sniffer showed normal traffic. The TDR showed a bad terminator. The terminator was slightly bent.