[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

4233.0. "Clearvisn backup fails "brMiGetCallBack:"" by SNOFS2::JEYACHANDRAN () Fri Feb 21 1997 01:47

	CLEARVISN V1.1.0 Recovery Manager gives the following error message.
	both on backup & restore. MAM F/W is V4.1.0 

	No problem with several other Hubs with same f/w & configuration.
	Cust says the backup was working OK earlier & now is failing.

	"        Getting Connection Table... 
	brMiGetCallBack: Failed on error 89
	ERROR...
	SNMP (GenErr) error. 
    	Script status: FAILED"

	What is the function of the MIB Object brMiGetCallBack ?

	Could this problem be a MAM module failure?
-------------------------------------------------------------------------------
- --- Start of backup script: DEChub 900 Manager ---
    Saving backplane configuration (LAN interconnect): 
        Verifying FDDI Auto-Healing is disabled... OK
              Getting PortSubtype Table... OK
        Getting Ligo Table... OK
        Getting LigoSubtype Table... OK
        Getting LigoLabel Table... OK
        Getting Segment Table... OK
        Getting SegSubtype Table... OK
        Getting Connection Table... 
brMiGetCallBack: Failed on error 89
ERROR...
 SNMP (GenErr) error. 
    Script status: FAILED 

clearVISN Recovery Manager Operation Log. Time: Mon Feb 17 17:19:15 1997
- ------------------------------------------------------------------
Start of restore script: DEChub 900 Manager ---
    Restoring backplane configuration (LAN interconnect): 
        Setting FDDI Auto-Healing DISABLED... OK
        Verify current and saved hub populations match... OK
        Reading tables from SDF... OK
        Reading tables from device: 
            Reading Port table... OK
            Reading Port Subtype table... OK
            Reading Ligo table... OK
            Reading Ligo Subtype table... OK
            Reading Ligo Label table... OK
        Translating Port & Ligo table indices: 
            Translating Port table indices... OK
            Translating PortSubtype table indices... OK
            Translating Ligo table indices... OK
            Translating LigoSubtype table indices... OK
        Erasing Connection, Segment, & SegSubtype tables: 
            Erasing Connection table... 
brMiGetCallBack: Failed on error 89
ERROR...
 SNMP (GenErr) error. 
    Script status: FAILED
T.RTitleUserPersonal
Name		DateLines
4233.1Anyone seen the problem?SNOFS2::JEYACHANDRANMon Feb 24 1997 23:039
	Hello,

	Has anyone seen the problem?

	Is there anything we can try to isolate the problem?

	Thanks in advance.

	Daniel.
4233.2Same problemSTU03::RUEGGENThu Feb 27 1997 01:398
    Hello Daniel,
    
    I am sorry, that I can't be of more help, but I have had the same
    situation and cannot figure out what the problem is.
    
    If I find out anything I will let you know.
    
    Ulrich
4233.3Sounds like a connectivity issueNETCAD::GILLISFri Feb 28 1997 13:1247
Daniel,

Sounds like your connection from the NMS to the hub is the culprit.
Make sure your NMS is connected to one of the following:

1)The OBM port on the Hub900 (best choice)
2)If connected to a port on a module (in-band management),
make sure that the module is defined as the IP services module
for the device. In addition, a port-switch module CANNOT be
used as the IP Services module.


If you don't use the above guidelines, an initial Backup operation
will be successful, because a Backup operation does SNMP gets only
(read-only operations). However, a restore will most likely fail, because
restore operations wipe out (erase) the connections from the module to the
backplane before restoring your parameters. The OBM port on the DEChub900
and an IP Services module use the 38K management channel; any other
connection from your NMS to the Hub900 is a direct in-band connection
that Recovery Manager may disconnect.

Once a "disconnect" occurs, chances are the Hub900 is in an incoherent
state, and you won't be able to run a Backup successfully to it unless
it is set back to Factory Defaults.

Oh, about the "brMiGetCallBack" message ...
=========================================
This is an internal error message that we (unfortunately)
are exposing to the user. In clearVISN Recovery Manager V2.0,
we will now say something like "Cannot communicate with device"
instead. (When something fails, we print out the name of the
function in the code where the failure occurs, and the 
function name is brMiGetCallBack() ). Sorry about this mess.


Please refer to the clearVISN DOCS, chapter on Recovery Manager.
These connectivity concerns are spelled out quite well
(or, perhaps, they are not, and you need to tell me this!!!)

===============================================
In any event, to get you back up and running, make sure
your network connection to the Hub900 is one that Recovery
Manager requires, set your Hub900 to Factory Defaults, and
try to restore your previously-saved Hub900 parameters.

John Gillis
clearVISN Recovery Manager