ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.
NewMM.pl run done - still seeing "Different Type Model" minor alarms
Article ID: 111982
Updated On:
Products
CA Spectrum
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, CA Spectrum provide the ./Install-Tools/Postinstall -> NewMM.pl script.
The Product Manuals covering this at (you may replace to ./10-3-0/en.. or to ./10-3-1/en.. for most current documentation releases)
https://docops.ca.com/ca-spectrum/10-2-3/en/managing-network/certifications/customizing-identification-with-device-certification
https://docops.ca.com/ca-spectrum/10-2-3/en/installing-and-upgrading/upgrading/upgrading-models
https://docops.ca.com/ca-spectrum/10-2-3/en/managing-network/certifications/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".
To resolve this issue, CA Spectrum provide the ./Install-Tools/Postinstall -> NewMM.pl script.
The Product Manuals covering this at (you may replace to ./10-3-0/en.. or to ./10-3-1/en.. for most current documentation releases)
https://docops.ca.com/ca-spectrum/10-2-3/en/managing-network/certifications/customizing-identification-with-device-certification
https://docops.ca.com/ca-spectrum/10-2-3/en/installing-and-upgrading/upgrading/upgrading-models
https://docops.ca.com/ca-spectrum/10-2-3/en/managing-network/certifications/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
This applies to all supported CA Spectrum platforms and CA Spectrum releases.
Resolution
CA Spectrum NewMM.pl script supports a "single" conversion pairing mode per command-line option "-m".
Documentation https://docops.ca.com/ca-spectrum/10-2-3/en/managing-network/certifications/customizing-identification-with-device-certification/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
Documentation https://docops.ca.com/ca-spectrum/10-2-3/en/managing-network/certifications/customizing-identification-with-device-certification/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
[[email protected] 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: grlabspec02
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 grlabspec02
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 (grlabspec02 @ grlabspec02)
* 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 !
[[email protected] 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: grlabspec02
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 grlabspec02
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 (grlabspec02 @ grlabspec02)
* 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
Yes
No
Powered by
