[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

3820.0. "No response from Agent" by GIDDAY::STANISLAUS () Thu Aug 29 1996 04:20

	One of my customer made this comment and I was suprised to hear this,
because I haven't heard of this before. He said he has had the problem for over
18 months (since he first got the HUBs) and we (Digital) haven't fixed it.

	He has 12 DEChub 900s each with DR900TM, DR90T-16, DS900TM, DS900EF,
etc. All his MAM modules are at version 3.x. He is using Hubwatch version 3.x.

	Every now and then, ranging from once every two days to a week, he
will get NO RESPONSE FROM AGENT when trying toi access from Hubwatch, a
DEChub900.

	He says the fault can be fixed by RESTTING MAM TO CURRENT SETTINGS or
Power Cycling the entire DH900 chassis.

	I said upgrade to the latest F/W versions all the modules and try again.
Eg. MAM to 4.2, DR900TM to 2.x, DS900EF to 1.6.1 or 1.5.2, etc. He said that
he did upgrade his F/W versions already once due to a similar advice from
another Digital engineer once before and that did not help. So he is hesitant
to try another F/W upgrade.

	He also said that someone from Digital said that the problem is not in
the HUB, but with Hubwatch. He has been told that if the HUB has been up for an 
N number of hours, the UPTIME counter reaches a certain value, which Hubwatch
doesn't like to know about (because of a bug) and hence the problem. He said
that he was told that version 5.x of Hubwatch (Multichassis Manager) will fix
this problem.

	But we have several dozen DEChub 900's inhouse at our Head Office in
Rhodes. I cannot recall a day when I ever had this problem, requiring a DH900
MAM module RESET TO CURRENT SETTINGS. 

	Also the customer says the above problem can be seen with Hubwatch
managing a Gigaswitch. The Gigaswitch has to be rebooted again to make Hubwatch
access the Gigaswitch once the Gigaswitch has been up for a certain number of 
hours. 

	Rebooting Hubwastch PC doesn't fix the problem. The managed unit DH900
or Gigaswitch has to be rebooted so that the UPTIME goes to a value of 0 and
starts counting up again.

	Has anyone else heard this above story or is this customer making it up 
although it does appear to make sense. Then why don't I see the problem on our
inhouse DEChubs and Gigaswitches. 

Alphonse

T.R	Title	User	Personal Name	Date	Lines
3820.1	Me too!!	KERNEL::FREKES	Excuse me while I scratch my butt	`Thu Aug 29 1996 07:28`	16
	Alphonso Iam getting the same problem on an intermittent basis. I had it this morning, on our hub in the office. I have had to do a RESET WITH CURRENT SETTINGS, before I could do it. So I looked further, and decided to try a few pings. I pinged the in bound IP address and it was taking 65 times longer to ping this than if I pinged a module in the hub with an IP address, ie a DECswitch900ef. I am not sure if the two issues are related, or I am barking up the wrong tree completley. Perhaps someone else can shed some light on this issue. Steven Freke UK CSC - Basingstoke
3820.2		NPSS::MDLYONS	Michael D. Lyons DTN 226-6943	`Thu Aug 29 1996 10:37`	10
	dir /title=uptime Topic Author Date Repl Title > 3179 CSC32::D_PERRIN 18-JAN-1996 2 long sysuptime a problem? 3312 TROOA::MCCHARLES 27-FEB-1996 6 SYSUPTIME COUNTER PROBLEM? 3562 KAOT01::WATTERS 27-MAY-1996 6 Can you exceed 248 days of uptime on DECswitch 900EF (v1 ...note that the uptime period involved is much longer than weeks. MDL
3820.3		NETCAD::MILLBRANDT	answer mam	`Thu Aug 29 1996 18:53`	23
	I am surprised to hear that your customer has a DECrepeater 90T-16 in his hub, but is running MAM V3.x and HUBwatch V3.x. There is no management support for this device prior to V4!!! Of course, you can plug it in and use it as a dumb repeater. But HUBwatch won't even know what faceplate to draw. There are also significant management improvements and LAN interconnection improvements if the DECswitch 900EF, MAM and HUBwatch are all brought up to date. MAM V4 allows a customer to use up to three in-band IP addresses. HUBwatch can be switched to use a different address if the "No Response" thing occurs. The No Response from Agent can have several causes. We can't say it won't happen again with the upgrades. The slower pings via in-band MAM address vs a device's own IP address is normal behavior. For the in-band MAM pathway, the ping msg is received by the device, then sent across the 38.4kbps backplane, processed by the MAM, returned over backplane, then sent out to the network by the device. Dotsie
3820.4	bug report from customer is true	NETCAD::HOPPE		`Tue Sep 10 1996 17:48`	19
	> Rebooting Hubwastch PC doesn't fix the problem. The managed unit DH900 >or Gigaswitch has to be rebooted so that the UPTIME goes to a value of >0 and starts counting up again. > > Has anyone else heard this above story or is this customer making it up >although it does appear to make sense. Then why don't I see the >problem on our inhouse DEChubs and Gigaswitches. Yes, this story is true. I was not the person who actually fixed the problem, but I do remember it being fixed. The problem was found to be that after a module had been up for approximately 9 months straight without rebooting, the large sysUpTime counter would cause problems for hubwatch. This should already be fixed in the newest versions of hubwatch (MCM). Although, if the customer has reset the device and is seeing this problem in a short amount of time, I doubt this is the bug he is observing. Chris