Chapter 6: Developing a New Certification
This section contains the following topics: New Certification Management (see page 87) New Device Model Type (see page 89)
Creating a New Application Model Type (see page 100) How to Add Support for Additional Traps (see page 111) Distributing a New Certification (see page 112)
New Certification Management
To model a device, CA Spectrum uses a device model type and its associated interface and application model types. You can add device model types or you can enhance the functionality of the GnSNMPDev device model type. To enhance device management with CA Spectrum, a solid understanding of the functional components of a device is required.
The GnSNMPDev device model type and the interface and application models that are known to the GnSNMPDev model type support many device functions. Supported functions comprise both proprietary and standard MIBs. Identify the functionality of the device that GnSNMPDev already supports. For example, if device interfaces map one-to-one with physical ports on a single board, GnSNMPDev supports this device without enhancement. GnSNMPDev includes native support for MIB-II interfaces in the Snmp2_Agent application model.
To test GnSNMPDev device support, use an IP address to model the device in OneClick. CA Spectrum automatically finds the model type most appropriate for the device. If a specific model type is lacking, CA Spectrum selects the GnSNMPDev model type and instantiates a GnSNMPDev model to represent the device. You can then evaluate the type of support that CA Spectrum can provide for your device by default.
Once you have established the default support, consider the required customizations. You can then more easily decide if further customization is necessary to manage your device properly. The following sections outline some scenarios in which expanded support is required.
New Certification Management
88 Certification User Guide
Additional MIB Support
If device management in your environment requires access to additional MIBs, MIB objects can be made available to a device model. The following methods let you increase access to MIBs:
■ (Recommended) Import the new MIB directly into the SpectroSERVER using the import mechanism provided in MIB Tools.
■ Create a device model type to represent your device and include the necessary
MIBs in the device model type.
■ Create an application model type that provides access to the new MIB.
More information:
Creating a New Application Model Type (see page 100) New Device Model Type (see page 89)
Unique Trap Mapping
Create a device model type if the device that you are modeling requires unique trap processing in response to a common trap. For example, assume that you want core routers to generate a major alarm in response to an authentication failure. However, all other devices generate a minor alarm in response to the same failure.
By default, CA Spectrum generates a minor alarm in response to an
authenticationFailure trap. You can create a device model type, and you can configure support for the trap in the event and alert configuration files for this device model type. This support overrides CA Spectrum default processing for the authenticationFailure trap for this model type only.
Unique Watches
You can generate events and alarms that are based on the results of a watch. The GnSNMPDev model type provides a number of predefined watches that can be enabled for individual models.
You can customize the watch implementation on the models that represent your device for each applicable GnSNMPDev model. However, you can avoid repeating this
customization on each model by creating your own device model type to implement the customized watch.
New Device Model Type
Chapter 6: Developing a New Certification 89 All of the information that makes up a watch is stored as attributes in the model type specified in the watch. The only exception is the probable cause information that is created for an alarm that results from the watch. This information is stored in the ProbCause model type .
Because you have not created the ProbCause model type with your Developer ID, you lack permission to export and distribute it with your management module. As a result, the probable cause information for the watches that you have created is not distributed. To solve this problem, derive a new model type from the ProbCause model type. The probable cause information for any watches for any of your management modules is automatically stored in this derived model type. Because you have created this derived model type, you can distribute it with your management module.
Note: For more information, see the Watches User Guide.
More information:
New Device Model Type (see page 89)
Interface Model Creation
If your device does not advertise interface (port) information in the MIB-II standard interface table but instead uses information from a proprietary MIB, CA Spectrum cannot model the associated interfaces.
Without interface models, you cannot resolve connections to the interface level, nor can you monitor the status of each interface. To work around this problem, create a new application model type that includes support for the proprietary MIB with the interface information.
More information:
Creating a New Application Model Type (see page 100)
New Device Model Type
CA Spectrum offers multiple options for creating device model types. The topics in this section describe some of the factors to consider. A new device model type requires some or all of the following tasks:
■ Understanding the database derivation and MIB requirements ■ Creating the model type and setting required attributes
New Device Model Type
90 Certification User Guide
■ Making desired customizations
■ Making the new model type distributable to other CA Spectrum hosts
New Device Model Type Design
The device model type database architecture for developing new device model types organizes all of the proprietary MIBs that you import into separate MIB model types. These MIB model types can then be derived directly into the device model type, as shown in the following diagram:
Manufacturer
Vendor X
MIB A MIB B MIB C
GnSNMPDev
VendorXDevice = instantiable model type
= instantiable and derivable model type
This scheme has the following advantages:
■ A single MIB can be derived into multiple model types. For example, you can use
the same MIB to create multiple device model types or a device and an application model type while maintaining the attribute IDs.
■ Vendor MIBs can be organized in a single collection.
■ Convenient access to MIB information is available directly from the device model.
For example, you can access OneClick views, watches, and logging and polling information about proprietary vendor attributes from the device model.
New Device Model Type
Chapter 6: Developing a New Certification 91 If the new device model requires access to additional MIBs from CA Spectrum, the simplest method is the MIB import mechanism that is available in MIB Tools. This mechanism creates attributes from these objects and makes them available to all models that represent a device in the SpectroSERVER database.
Note: For more information, see the Device Management User Guide. The MIB import mechanism distributes the new MIB across all SpectroSERVERs in a distributed environment.
New Device Model Type Creation
After selecting a database scheme, use the Model Type Editor to create your model types. Derive all device model types from the GnSNMPDev model type.
Note: For more information, see the Model Type Editor User Guide.
When you are using the Model Type Editor to create a device model type, remember to set the model type flags correctly for the new model type.
More information:
Model Type Flags Setting (see page 91)
New Device Model Type Configuration
A few steps are involved in configuring a new device model type. Complete the following tasks:
■ Set model type flags
■ Set attribute values
■ Map a device or a device family to the new device model type ■ Configure serial number handling
The following sections provide high-level information about these configuration steps.
For more information, see the Model Type Editor User Guide.
Model Type Flags Setting
Set the values of model type flags so that models of the new model type behave as expected. Each flag represents a Boolean value and can either be selected (set to TRUE) or not (set to FALSE).
New Device Model Type
92 Certification User Guide
In most cases, you set the Visible, Instantiable, and Derivable flags to TRUE.
Visible flag
Makes the model type visible to all Model Type Editor users. If set to FALSE, the model type is only visible to a user with the same Developer ID as the one used to create the model type.
Instantiable flag
Lets you instantiate a model of this model type in OneClick.
Derivable flag
Lets this model type be used as a base for other model types.
In most cases you should set the No Destroy, Unique, and Required flags to FALSE.
No Destroy flag
If set to TRUE, prevents users from destroying a model of this type in OneClick.
Unique flag
If set to TRUE, only lets one model of this model type be instantiated in OneClick.
Required flag
If set to TRUE, a model of this model type must always exist in the SpectroSERVER database.
Attribute Values Setting
Once you have created your device model type, use the Model Type Editor to set the default value of several attributes. Some of these settings are used to configure built-in capabilities that are inherited by deriving from the GnSNMPDev model type. The following section describes the attributes and settings.
CompanyName
Is the name of the company that developed the management module.
Description
Is an attribute that exists in the MMDeveloper group and in the CommonInfo group. The Description attribute in the MMDeveloper group has a default value of Generic SNMP Device Management Module. We recommend resetting this default value to a description of your management module. The Description attribute in the CommonInfo group can be similarly reset or left empty.
Desc_Key_Word
Enables resolution of multiple device model types. If the System_Desc_Verify or Vendor_Object_ID discovery mechanisms identify multiple device model types, a search of sysDescr looks for a substring match for the value of this attribute.
New Device Model Type
Chapter 6: Developing a New Certification 93
DeviceSerialAttr
Is the device serial number. Set the value to the attribute ID of the external attribute that contains the serial number. When the model is created, it reads this external attribute and writes it into Serial_Number.
DeviceType
Identifies the device. A default value is required for this description attribute when the DeviceNameList mechanism is not used for identification. Setting the default value guarantees that a value is present for displaying, sorting, and filtering.
DeviceTypeDiscEnable
Enables or disables DeviceType naming intelligence. The default value (true) is appropriate for most device model types. However, set this value to false under either of the following conditions:
■ A new device model type has been derived from a base model type other than GnSNMPDev. The new type has specialized DeviceType naming intelligence that is inappropriate for the derived device model type.
■ A more appropriate DeviceType name can be set in the catalog for the derived model type.
Disposable_Precedence
Is evaluated during device model type discovery when multiple model types are identified as candidates. The higher value is the chosen model type.
This value is also evaluated when a model is created with the same MAC address as a previously existing model. In this case, the disposable_precedence attributes of both models are evaluated. The model with the higher value replaces the existing model by appropriating its CONNECTs associations.
Enable_IH_Enterprise_Disc
Enables or disables the automated setting of the Manufacturer and
App_Manufacturer attributes based on the enterprise ID term of the device sysObjectID.
The default value, true, is appropriate for GnSNMPDev because it is used to model devices from various manufacturers. However, for a new device model type that is derived from GnSNMPDev with a known device manufacturer, we recommend setting the value of Enable_IH_Enterprise_Disc to false. With that attribute set to false, set the default values of the Manufacturer and App_Manufacturer attributes to the appropriate names.
Manufacturer
Is the name of the vendor that manufactures the device.
MMName
New Device Model Type
94 Certification User Guide
MMPartNumber
Is the part number that you plan to assign to the management module.
System_Desc_Verify
Provides a device model type discovery mechanism that parses the sysDescr for firmware version information. Clear this default value if you are not using this discovery mechanism. It interferes with the other discovery methods if enabled.
System_Oid_Verify
Is a legacy attribute. Refer to SysOIDVerifyList.
SysOIDVerifyList
Used in conjunction with DeviceNameList. Populating this list attribute with sysObjectID values enables device model type discovery intelligence to match the list against the device sysObjectID value. If a match is found, this model type is selected as a possible candidate for modeling.
Vendor_Name
Is the name of the company developing the management module.
Vendor_Object_ID
Provides a device model type discovery mechanism by which a partial sysObjectID match identifies a device model type.
VendorIDVerifyList
Maps devices to device model types based on whether the device supports specific MIB objects. Used during Discovery with VendorOIDVerifyList.
Specify the list of enterprise IDs to compare against the device to model. If a match is found, the corresponding MIB object specified in VendorOIDVerifyList is read from the device.
VendorOIDVerifyList
Maps devices to device model types based on whether the device supports specific MIB objects. Used during Discovery with VendorIDVerifyList.
Specify the list of attribute IDs for the MIB objects to read from the device.
Verify_Mismatch_Model
Causes CA Spectrum to perform checks for a device model type match with the device that is modeled. Set this attribute to true.
New Device Model Type
Chapter 6: Developing a New Certification 95
More information:
Map Using a MIB Object (see page 97) Device Mapping (see page 95)
Map Using Unique sysObjectID Value (see page 95)
Map Using sysObjectID and Strings in sysDesc (see page 96) Map Using Firmware Version Strings in sysDesc (see page 97)
Device Mapping
Each device on the network requires a unique identifier. Most commonly the MIB-II object sysObjectID provides this unique identifier. Vendors typically assign a unique sysObjectID value for a device, creating a one-to-one mapping. Vendors often advertise this information in a product MIB, where you can find the mapping of sysObjectID to device model type.
You can use the Model Type Editor to identify a device in several ways:
■ If your device provides a unique sysObjectID value, use the process described in
Map Using Unique sysObjectID Values (see page 95).
■ If your device does not provide a unique sysObjectID but does provide a unique substring within sysDescr, use the process described in Map Using sysObjectID and Strings in sysDesc (see page 96).
■ If your device does not provide a unique sysObjectID but does provide a firmware version text string in sysDescr, use the process described in Map Using Firmware Version Strings in sysDesc (see page 97).
■ If your device does not provide any of the previously described information, you can map the device to a device model type based on whether the device supports specific MIB objects in a proprietary MIB. Refer to Map Using a MIB Object (see page 97).
More information:
Map Using a MIB Object (see page 97)
Map Using Unique sysObjectID Value (see page 95)
Map Using sysObjectID and Strings in sysDesc (see page 96) Map Using Firmware Version Strings in sysDesc (see page 97)
Map Using Unique sysObjectID Value
If your device has a unique sysObjectID value, you must relate your new device model type to the sysObjectID to help ensure that CA Spectrum selects the new device model type to represent the device. To do this, add the sysObjectID value to the
SysOIDVerifyList model type attribute. If the new device model type represents a family of devices, then add each sysObjectID value.
New Device Model Type
96 Certification User Guide
If another model type contains the same sysObjectID value in its SysOIDVerifyList attribute, it is possible that CA Spectrum will choose the other model type to represent a device with this sysObjectID. If this occurs, you should change the
disposable_precedence attribute value on your device model type to a higher value than that of the other model type. For example, if the other model type has a
disposable_precedence value of 10, change the disposable_precedence value on your model type to 11.
To provide identification to your model, configure the model type to display a different device name for each of the devices that the model type is designed to support. For example, assume your device model type represents the 8480 series of switches made by MySwitch, Inc. Instead of seeing the device name MySwitch_8480XX for all of the switches in the 8480 family, you want to display the model number of the switch, as appropriate. If CA Spectrum is modeling an 8480-09 switch, the model should display the device name MySwitch_8480-09. If CA Spectrum is modeling an 06 switch, the model should display the device name MySwitch_8480-06.
Follow these steps:
1. Set the SysOIDVerifyList attribute equal to the sysObjectID(s) of the devices that the model type represents.
2. Set the DeviceNameList attribute equal to the device names that apply to each sysObjectID listed in the SysOIDVerifyList attribute.
3. Specify the same number of names in the DeviceNameList attribute as there are sysObjectIDs listed in the SysOIDVerifyList attribute. List the names in the same order as their corresponding sysObjectIDs.
4. Clear the System_Desc_Verify default value.
The DeviceNameList attribute only works for device model types that use the SysOIDVerifyList attribute model type discovery mechanism. Verify that both lists have the same number of entries. Otherwise, the DeviceType attribute is not set correctly.
Map Using sysObjectID and Strings in sysDesc
If your device does not provide a unique sysObjectID, a partial or complete match of the sysObjectID in combination with a sysDescr substring can provide unique identification.
You can set up the relevant attributes to enable this functionality on the model type.
Follow these steps:
1. Set the Vendor_Object_ID attribute equal to the partial or complete sysObjectID value returned by your device.
Only the first seven terms up to the enterprise ID are used for comparison. 2. Set the Desc_Key_Word attribute equal to the unique, partial sysDescr value
New Device Model Type
Chapter 6: Developing a New Certification 97 3. Set the DeviceType attribute to be equal to the desired identification string.
4. Clear the System_Desc_Verify default value.
Map Using Firmware Version Strings in sysDesc
If your device does not provide a unique sysObjectID or a unique sub-string within sysDescr, check whether sysDescr provides a unique firmware version. This discovery mechanism searches the sysDescr value for either “Version” or “Revi.” If one of these