After running NewMM.pl script still seeing "Different Type Model" minor alarms
Article ID: 111982
Updated On:
Products
Issue/Introduction
CA Spectrum device modeling is not doing a fully automated Device reconfiguration. Background here is to see the "Different Type Model" alarm indicating a device (model change) conflicting to a current device modeling. This is FAD.
To resolve this issue, NetOps Spectrum provide the ./Install-Tools/Postinstall -> NewMM.pl script.
NetOps Spectrum documentation covering this at
Customizing Identification with Device Certification
Change the Model Type for a Single Device Type Using a Script
Why is the "NewMM.pl" script failing to resolve the "Different Type Model" (PCause 0x10203) (EventType 0x10006 / The model created is not the same type as device)?
We see the script runs fine for many device reconfigurations.
The major background is, that for the NewMM.pl scripting/processing logic the type conversion is defined in pairs for "current model type" converted to "new model type".
So in case the current device model-type is not matching to the script declared paring (current_model-type : new_model-type) then script logic cannot convert this device model. Not any model-type pairing is declared by default.
Sample:
- initially the network device was modeled as "HubCat29xx" model-type - and this device hardware is now replaced by a current Cisco-Switch (C3850 class)
- the Spectrum logic can proper discover and create a device model for the C3850 - using the SwCiscoIOS model-type
- the NewMM.pl script does not cover a HubCat29xx to SwCiscoIOS conversion rule for i.e. 1.3.6.1.4.1.9.1.1745
Checking the NewMM.pl script for this (sample here is conversion pairing HubCat29xx to SwCiscoIOS):
grep "Destination mtype is SwCiscoIOS" NewMM.pl
# Source mtype is Rtr_Cisco / Destination mtype is SwCiscoIOS
# Source mtype is SwCat6xxx / Destination mtype is SwCiscoIOS
# Source mtype is SwCat35xx / Destination mtype is SwCiscoIOS
# Source mtype is SwCat4xxx / Destination mtype is SwCiscoIOS
# Source mtype is GnSNMPDev / Destination mtype is SwCiscoIOS
# Source mtype is GnSNMPDev / Destination mtype is SwCiscoIOS
grep HubCat29xx NewMM.pl | cut -c1-80
# Source mtype is Rtr_Cisco / Destination mtype is HubCat29xx
["HubCat29xx", "0x11c000f", 0,0, "$sysObjectID", "1.3.6. .......
# Source mtype is GnSNMPDev / Destination mtype is HubCat29xx
["HubCat29xx", "0x11c000f", 0,0, "$sysObjectID", "1.3.6. .......
This shows the checked NewMM.pl script does not support the conversion "HubCat29xx" to "SwCiscoIOS".
Environment
All supported releases and Operating Systems
Resolution
CA Spectrum NewMM.pl script supports a "single" conversion pairing mode per command-line option "-m".
Documentation section:
Change the Model Type for a Single Device Type Using a Script
Running the NewMM.pl script in single-device mode is the solution to address non_defined device model-type pairing for the NewMM.pl script.
The NewMM.pl script could be used to do a manual conversion in case:
- the current CA Spectrum install will support the device model-type assignment per auto-discovery logic out of the box
(so please do a single device discovery by "IP" and verify the default model-type assignment.)
- the Device SysObjID is supported and listed in the "Device Certification" Utility
Now make use of CA Spectrum install owner - while having the SpectroSERVER running - to run the script with "-m"
./Install-Tools/Postinstall/NewMM.pl -m
In the upcoming dialog update the "device model-type" pairing and SysObjID as appropriate. Below find additional information for the above sample device problem (obsolete Model-Type HubCat29xx - new targeted Model-Type SwCiscoIOS for device models with SysObjID 1.3.6.1.4.1.9.1.1745)
You may have to rerun the NewMM.pl script with option "-m" then for further model-type conversions.
Each run will do so for one single criteria set: current_model-type : targeted_new_model-type : SysObjID
Additional Information
Sample data/output for running ./NewMM.pl -m
[spectrum@lab PostInstall]$ ./NewMM.pl -m
NewMM.pl is running using custom conversion criteria. To use out-of-the-box conversion
criteria, run NewMM.pl without the `-m' option.
Enter name or IP of VNM Host: lab
Enter SpectroServer Landscape Handle (Must be in hex): 0x9600000
Enter System Object ID: 1.3.6.1.4.1.9.1.1745
Enter the current model type name: HubCat29xx
Enter the destination model type name: SwCiscoIOS
connect: successful lab
current landscape is 0x9600000
...
Collecting data...
Processing data...
/ Please Wait...
_______________________________________________________________
The script may have discovered one or more models of type
0x11c000f which can be converted to the following new model type:
Model Type: SwCiscoIOS
Only eligible models matching the conversion criteria
will be converted to the new model type.
The following models have been discovered and will be
converted upon request:
MHandle: 0x96000d0
MName: SWCH-L2b-3850.ca.net
MType: 0x11c000f
....
* Single Landscape Mode
* Landscape : 0x9600000 (lab @ lab)
* Source Model Type : 0x11c000f (HubCat29xx)
* Destination Model Type : 0x2100b2 (SwCiscoIOS)
* Validating Transfer Attributes
* Validating Filter Attributes
Landscape 0x9600000 has 1 model(s)
+ Changing discovery attributes
+ OK to convert model 0x96000d0 - SWCH-L2b-3850.ca.com
+ Converting shared SCM configurations
+ Creating New Models
+ Converted 0x96000d0 -> 0x96002cd
+ Converting nonshared SCM configurations
+ Restoring container associations
+ Restoring device associations
+ Restoring connections for 0x96002cd
* Conversion Complete !
Feedback
