Conference netcad::hub_mgnt

Patrick,

Powering down your hub should NOT cause lost configurations!
Please make sure the firmware revs (especially for the DEChub 900 manager)
are up-to-date.


Removing a module will cause the backplane configs to be lost.


Meanwhile, we are planning a backup and restore configuration utility that
may be a part of the next (V4.0) version of HUBwatch.

Tom Hood
HUBwatch

	as it was mentionned in the last Network academy by Herman Levenson,
i understood that the backup/restore functionnality was top of the list
to the improvements of Hubwatch functions .

	we have many customers who are waiting anxiously for this 
feature as it will allow them to reconfigure hubs and modules very 
quickly on change of modules or on change of topologies 
	
	so we hope strongly that it will work with V4 of Hubwatch .

	if there is a need to reinforce the need for this functionnality 
we can develop a whole argument about this with both technical reasons and
business figures .

	thanks for letting us now about it 

Re: .2:

Pierre,

We *know* backup and restore is important.  And we're busily spec-ing out
the work for it.  But we haven't reached the level of detail yet that
gives us a schedule for that chunk of work.

So, it's a matter of:
	(1) Finish specifying the design.
	(2) Develop schedules and figure out how many fingers we need
	    to type the code.
	(3) Use 10 or 20 fewer fingers than we need, and type code as fast 
	    as we can.
	(4) When it works, ship it.

Will it be done with the next release?  Maybe.  In fact, I hope so.
Is this a high priority activity?  You bet your bazookas it is.
Is a software engineer (me) going to publicly announce an exact answer on 
dates for an undesigned component?  No way, Jose!

allegedly Tom Hood,
HUBwatch, maybe.

	thanks Tom for explaining what is going on ;

	typically this need for quick save and restore is raised
by our main dechub buyer here in Toulouse , the french air traffic 
control administration ; they have planned their network with lots 
of dechubs ( over 120 ) with lots of fddi conc ( over 250 ) and also
ethernet repeaters  ( over 60 ) and decservers	; 

	now the network ( consisting of 6 sites interconnected ) 
will mainly be operated by technical operators and they just dont want 
to have to reconfigure "manually" every module if they have to change it 
(they are going to do "first level maintenance " of the modules ; that is
quick replacement of failed modules ) 

	of course we hope that the modules are very seldom failing , but 
there is also another point : they are going to switch modules cyclically
 from normal operations to standby for systems reconfigurations (
there are more than 1000 alpha stations involved for the air control "realtime"
 for determining airplanes positions ) 

	i hope it helps understand their feeling about this save/restore 
feature and why they are waiting for it .

	as it was already discussed in details in this notesfile , there is
no easy way to do this with "basic" snmp managers  as they first intended to
do .

	cordialement , PJ

Again, we *know* it is a very high priority, and we are working on it. It 
includes a surprisingly complex tangle of software.  We're doing our best...


Tom Hood
HUBwatch

    Hi,
    
    Version 4.0 is now shipping with (it appears) no sign of the
    save/restore functionality.
    
    Can we have an update please?  
    
    Will it be in the imminent V4.1?  (It doesn't look likely going by 
    NAC::NIPG:[manage]status.txt)
    
    
    How about V4.2?
    
    
    Clinton

See note 2634.