[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

4281.0. "follow uo to note 4024 : loss of hub configuration and unexpected factory reset" by TOOSRV::SELLES () Fri Mar 14 1997 12:51


a customer is experiencing the same problem as described in note 4024

a hub unexpectedly resets itself to factory default during normal operation 
losing all its configuration , including the Lan backplane

the hub firmware is 4.3.0 ; they use Hubwatch 4.1.1 from Unix 

the customer provided the dump from the hub error log : the problem looks 
like the "stop thrash protection" feature activates after too much repeated
resets ; 

this hub is populated with 5 FDDI modules configured as a tree , and 1 Ethernet
module ; 

from the customer network architecture , it is the root of a kind of "super"
dual-ring of trees ; so when it fails and reset to factory , this causes the
major problem of FDDI sub-rings partitionning that the customer wants to avoid
at any price ( BTW , it is this same customer which is responsible for the
auto-disconnect feature in FDDI concentrators ) 

this failure seems to happen when the customer has its own "network supervision"
application started , which uses a regular flow of snmp gets with bursts at
application startup , for monitoring all kind of hub objects ( including
counters , ports status , hub status ... ) 

they are using FDDI inband IP services and the MAM relays all snmp requests to
modules ( there are no IP addresses for modules because their exploitation
people says it is faster to replace a failed module having no IP address , as by
now Recovery Manager doesnt apply back an IP address to a module ) ;
they can use also OBM IP services in backup if inband is overloaded ; 


so the questions of the customer are :

1) what is causing the hub to reset too often ?
	should i open a SPR or IPMT ?

2) is it possible to disable "thash protection" ?  ( at worst , for the customer
, they prefer having the hub reseting itself but not losing its configuration ) 

3) will it be possible in next version of Recovery Manager to apply all
parameters back to a module including its IP address  ( this would make possible
 that they go directly to the module agent , rather than doing an indirection
thru MAM agent ?

4) will the speed of Bus Management be augmented between MAM and module agent ?
38,4 Kbps being slow from they point of view ? ( gigaswitch mgmt  bus is 10Mbps
)    


thanks a lot for your replies 
regards PJ



PS : below dump of errorlog from customer's hub 


Dump error log - Current Reset Count 54

Entry           46
Time Stamp      0 0
Reset Count     51
stop Trash;Cleared Nonvolatile Data.

Entry           45
Time Stamp      0 53200
Reset Count     50
Trap @          591 in obm.c

Entry           44
Time Stamp      0 36000
Reset Count     49
Trap @          591 in obm.c

Entry           43
Time Stamp      0 68600
Reset Count     48
Trap @          591 in obm.c

Entry           42
Time Stamp      0 27700
Reset Count     47
Trap @          591 in obm.c

Entry           41
Time Stamp      0 19900
Reset Count     46
Trap @          591 in obm.c

No more Error log Entry


BTW , they experience those messages also on other hubs ;

T.R	Title	User	Personal Name	Date	Lines
4281.1	Recovery Mgr restores hub's settings, but not IP addr	NETCAD::MOWER		`Fri Mar 14 1997 19:33`	16
	> 3) will it be possible in next version of Recovery Manager to apply all > parameters back to a module including its IP address (this would make > possible that they go directly to the module agent, rather than doing > an indirection thru MAM agent ? I don't fully understand your questions, but I will provide some data... Recovery Manager does restore a hub's parameters, including backplane configuration, but does not restore a hub's IP address - it cannot - for it to do so would be a catch-22 as Recovery Mgr requires that the hub have an IP address so Recovery Mgr can talk to the hub. Carl Mower. clearVISN
4281.2	what is catch-22 ?	TOOSRV::SELLES		`Tue Mar 18 1997 09:41`	9
	hello Carl thanks for your answer by the way , what means catch-22 ? is it what we call hen-egg paradox ? PJ
4281.3		NETCAD::MILLBRANDT	answer mam	`Tue Mar 18 1997 10:16`	1
	The base note problem is being worked through email.
4281.4	Catch-22 and your IP address	NETCAD::GILLIS		`Tue Mar 18 1997 11:05`	16
	PJ, For an explanation of "Catch-22", a book by Joseph Heller, go to http://www.globeserve.com/bookstore/0440204399.htm As it pertains to your situation: Think of using telnet console to a remote device. An ip address has to be defined on the device for you to connect via telnet. Now, if you had the ability to redefine or purge the ip address during the telnet console session, you would lose your connection by doing so. This is a "catch-22" John Gillis clearVISN
4281.5	another example of 'catch-22'	NETCAD::MOWER		`Tue Mar 18 1997 22:39`	21
	> by the way , what means catch-22 ? Here is another explanation, in addition to John's in -.1: 1. You want to call a friend you have not heard from in 10+ years, so that you can find out where in the country they settled. 2, In order to get their phone number, you must call directory assistance. 3. But in order to know what area-code's directory assistance to call you must know what part of the country they are located at... 4. (back to step #1) (granted, there are ways to solve this problem, but I hope this also helps you to understand "catch-22"). > is it what we call hen-egg paradox ? Yes, it's like the 'which came first, the chicken or the egg' problem.
4281.6	Why not use BootP?	HBAHBA::REED	John Reed @CBO = Network Services	`Thu Apr 24 1997 14:27`	19
	The way that Bay Networks 10/100 switches, and DECserver 900TM module, and some other routers I've seen do this, is to only allow the IP address to be changed in the non-volatile memory. The active images's IP address, default GW, mask, and community string is not modifyable. But you DO need to start somewhere. I like the DECNIS and Gigaswitch approach to the MAC address. They assign the Chassis a specific address, and the modules tack on a slot-number to the base address of the unit. Perhaps this approach could be modified to use with the IP address of modules. This gives each module a unique address, and it is repeatable and deterministic. but it also eats up a large number of IP addresses. Perhaps the BOOTP approach would be better (like Bay or HP does witih their hubs and routers). Just define the IP address in the Bootptab of the NW management station, and if you swap out a card, you need to edit the flat ascii file before that module will work again. JR
4281.7	Come on, use up those IPv4 addresses to force a switch to IPv6...	TWICK::PETTENGILL	mulp	`Tue Apr 29 1997 22:25`	2
	Then the IP address assignment for hubs is easy: just use the IEEE 48 bit ID plus the appropriate prefix.