NewMM.pl run done - still seeing "Different Type Model" minor alarms

Document ID : KB000111982
Last Modified Date : 23/08/2018
Show Technical Document Details
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:
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


 
Background:
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.
 
Instructions:
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 
 
Additional Information:
Sample data/output for running ./NewMM.pl -m  

[spectrum@grlabspec02 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 !