search cancel

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

book

Article ID: 111982

calendar_today

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". 

 

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 
 

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 !