Conference netcad::hub_mgnt

3136.0. "Repeaters and concentrators all resetting." by BANNOR::SGIBSON (yer uncle baff....) Tue Jan 09 1996 09:44

Hi,

	I have a problem with some DEChub900 MS's or perhaps I should say
	with some DECconcentrator 900MX's, DECrepeater 900TM's and PORTswitch
	900CP's.

	I had one hub which was configured to bring FDDI in on a DECswitch
	900EF(and out) and it was bridged to several internal LAN's on the
	hub chassis with port two of the 900TM connecting to one and a couple
	of ports on the 900CP conecting to others. I was getting a lot of
	resets with both, though the 900EF and the hub were both ok.
	This hub was actually located in the same place as two other hubs
	with a 900EF and two 900TM's each. These hubs are on an extended
	LAN with Galway (I am located in Ayr, Scotland) and NONE of the 
	twisted pair repeaters configured in these two hubs are resetting.
	The firmware versions in all the hubs and repeaters were as follows:

		Hub   : 4.0.4 (3 units)
		900EF : 1.5.0 (3 units)
		900TM : 1.1.0 (5 units)
		900CP : 2.0.2 (1 unit)

	I then received some new hubs and cards which were for other projects
	in the plant and had started to install four other hubs in two locations
	within the factory alongside another group who were installing four
	hubs they had recieved in the same shipment. They were having problems
	with hubwatch, so we decided ALL the hubs should be upgraded to the
	latest version of the firmware. The eight new hubs would also be
	configured with DECconcentrator 900MX's. (they had v3.0.1 firmware)
	so all the hubs I had (including a few still to be installed) were
	upgraded as were all the cards. So the current firmware version are
	as follows:

		Hubs  : 4.1.0 (15 units)
		900EF : 1.5.2 (19 units)
		900TM : 2.0.0 (18 units)
		900CP : 2.1.0 (2 units - can't get anymore of these yet)
		900MX : 3.1.1 (8 units - should be 9, but one DOA)

	The situation is now as follows, four of the hubs configured with
	1x900MX, 1x900EF & 2x900TM's continue to show resets on the 900MX
	and the 900TM's (configured with fibre inputs).
	Six of the hubs (4 of which are on a private IP subnet and the other
	2 are on the extended LAN) are not having any resets at all.

	The other 9 hubs are still experiencing the resets, and pretty much
	all at the same time, they all show the same (to within a few seconds)
	uptime.

	I dumped the error log entries on the 900MX's, the 900TM's and the
	900CP's and they have the following entries, with the only difference
	being slight time stamp and reset count entries.

	DECconcentrator 900MX	DECrepeater 900TM	PORTswitch 900CP
	=====================	=================	================

Entry No.	 125		     106		     2092
Time Stamp	 0 0		   0 30068		   0 29452
Reset cnt	 130		     2364		     2091
Error:	    Trap @322 in	Fatal Error; Line 334,	Fatal Error; Line 334,
	  sys_ip_stack_cfg.c	    File srv.c		    File srv.c

	The above is the most continual dump, every entry (with the exception
	of a a Stop Thrash; Cleared Non Volatile Data on the 900MX concentrator)
	is what is noted above. The 900TM's and 900CP's only ever get that
	error.
	When I was checking the first hub prior to its upgrade, the 900TM &
	900CP were getting the same error, the firmware upgrade does not
	appear to have made any difference.

	I set-up another hub with a couple of 900TM's and a 900CP at my desk,
	using an Ethernet feed into port 7 on the 900EF (no concentrators 
	onvolved in this configuration) and I am getting exactly the same
	resets. These devices are quite some distance apart, but are all
	resetting at the same time.

	Since I started this note, I have know had to replace the four newest
	hubs with a DECbridge 620 and DEMPR's as we were having a serious
	problem with VAXstations in a LAVc rebooting after losing connections
	for over two minutes.
	I think this is some other problem and am not convinced that the
	resetting is causing this, however, the resetting problem is a
	serious one that I need to get fixed.

	Any help on the matter would be greatly appreciated.

regards,

Sanny

Hi,

	Further to .0

	I have read note #3020 (I had read it before entering .0) and have
	now managed to get time (after ensuring the customer could continue
	to work) to give one of the concentrators an IP address, I don't
	know yet if this will make any difference.

	In .0 I said I didn't know if the resetting was causing the workstations
	to crash, having now moved everything off of the hubs, they are no
	longer crashing, so it might be that it was (it does make sense if
	all four concentrators in that ring reset, then everything on those
	hubs loses connectivity).

	I disconnected the hubs from the world and left them in their own
	private ring, so there was little or no network traffic and all the
	resets stopped, everything stayed up.
	I then connected one of the hubs to the world via an ethernet port
	on the DECswitch 900EF (port 7) to allow me to monitor the hubs and
	would you believe it, the resets all came back...I caught two of
	the concentrators at reset time (uptime of 23 seconds) using hubwatch
	and they were showing a network utilisation of 100%

	If the IP address on the concentrator makes a difference (see para 1
	above) then can someone explain to me why four other hubs which are
	using concentrators and don't have IP addresses either (and handle a
	lot of network traffic) don't have ANY resets.

	This problem seems to be very similar to #3020, it is the same dump
	error on the concentrator and everything goes at the same time, network
	wide...

	Any assistance would be greatly appreciated.

Sanny