Configuring Fault Management for Pingables

Contents
casp1022
Contents
Device fault isolation is faster and more reliable when device models have knowledge of each other as neighbors. When a fault occurs, each device model that is lost sends an ARE_YOU_DOWN action to all of its neighbor models. Depending on the answers that neighbor device models send, the lost models either turn gray or red.
Establish neighbor relations by creating a Connects_to association between a device model and the port model of another device. The act of pasting a device model on the interface of another device model adds each device model to the other's neighbor list.
Pingable models lack ports. As a result, in older versions of
CA Spectrum
, neighbor associations could not be established for Pingable models without the use of an inferred connector, like a Fanout. However, it is a best practice to create a relationship between models that is resolved directly. Placing both neighbor models in a Fanout means that fault resolution occurs indirectly. Fanouts and other inferred connector model types resolve faults differently and less directly during fault isolation.
Connect Pingable Models
You can connect Pingable models to each other in the topology view. Connect models to create a Connects_to association between them and receive more status information. You can connect Pingable models using one of the following methods:
  • Establish neighbors by drawing pipes between device models. Drawing a pipe between two Pingable models establishes a Connects_to association between the two models, making them neighbors.
  • You can create a Connects_to association between two Pingable models using the
    CA Spectrum
    Command Line Interface. Use the following syntax:
    ./create association rel=Connects_to lmh=<model handle of Pingable A> rmh=<model handle of Pingable B>
When the Connects_to association is established, you see a gold pipe between the two connected models. When a fault occurs, each Pingable model sends the other an ARE_YOU_DOWN action.
Mapping Traps from Other Models to Pingable Models
You can map traps from multiple IP addresses to a single pingable model using the Command Line Interface (CLI) update command. You create the mapping by adding the IP addresses to the deviceIPAddressList (0x12a53) attribute on the pingable model.
Before you can specify the mapping, you must add the following option to the .vnmrc file if the option is not already included in the file:
enable_traps_for_pingables=TRUE
You can also remove mappings with CLI, and you can configure OneClick to display IP addresses mapped to Pingable models.
To map traps from other IP addresses to a pingable model
  1. Connect to the
    SpectroSERVER
    with CLI.
    For more information about using CLI, see the section.
  2. Invoke the update command:
    ./update
  3. Add additional IP addresses to the deviceIPAddressList attribute (0x12a53) for the Pingable model you want to designate as a trap destination. The following example shows three IP addresses added to the attribute:
    update mh=<pingable's mh> attr=0x12a53,iid=10.253.8.34,val=0 update mh=<pingable's mh> attr=0x12a53,iid=10.253.8.65,val=0 update mh=<pingable's mh> attr=0x12a53,iid=10.253.9.17,val=0
  4. Verify that the IP addresses were added:
    show attributes attr=0x12a53 mh=<pingable's mh>
Enable a Device IP Address View for a Pingable in OneClick
If the Device IP Address List category is not included under the Information tab for Pingables, complete the following procedure.
To enable a Device IP Address view for a Pingable in OneClick
  1. Open the view-pingabledetails-config.xml file located in the following directory:
    <$SPECROOT>/tomcat/webapps/spectrum/WEB-INF/topo/config/
  2. Uncomment the following line:
    <field-subview idref="devipaddrlist-subview-config"/>
  3. Restart OneClick.
    The Device IP Address List category appears under the Information tab for Pingable models. If you map IP addresses to a pingable model, the addresses appear in the list.
Remove an IP Address Mapping from a Pingable Model
When addressing schemes change in your environment, keep model information up to date. Use the
CA Spectrum
Command Line Interface (CLI) to remove an IP address mapping from a Pingable model.
Follow these steps:
  1. Connect to the
    SpectroSERVER
    with CLI.
    See the section for more information about using CLI.
  2. Invoke the update command:
    ./update
  3. Remove the IP address from the deviceIPAddressList attribute (0x12a53).
    update mh=pingable mh attr=0x12a53,iid=10.253.8.65,remove
  4. The following example shows one IP address removed from the attribute:
    Verify that the IP address was removed:
    show attributes attr=0x12a53 mh=pingable mh
Pingable Model Names
Pingable, or non-SNMP managed, device models are defined in Spectrum as devices capable only of communication through Ping.
The Model Naming configuration that controls how Spectrum determines the names of models it creates is found on the VNM model for each Landscape. It is found in the VNM models Information tab, in the SpectroSERVER Control section.
The primary two configurations that impact model naming are:
  • Use Fully Qualified Host Name
  • Model Naming Order
User Fully Qualified Host Name has a Yes or No setting. If a devices name is device.company.com, if that is set to Yes, it will be named with, device.company.com
If that is set to No, it will be named with
device
. The default setting is No. Model Naming Order default settings are:
  • SysName: SysName is obtained from the MIB Object of the device that lists its SysName value 
  • IP Address: IP Address is the IP Address of the device 
  • Name Service: Name Service is the DNS name of the device, also found through the 'nslookup <IP_Address> command.
 
The default Spectrum Naming configuration for determining Model Names noted above will result in Pingable models being named with IP Addresses. If that order is changed after the Pingable models are created, they will be ignored when the 'Reevaluate All Model Names' function is launched and will not be renamed.
 
There are two other methods of creating Pingable models. The first, the 'Model by Type' option from the Topology tab will also ignore those naming configurations and will create a model named with IP address if the devices name is not specified when setting up the 'Model by Type' option.
The second, Discovery Configurations launched from the Auto Discovery UI, does honor the Model Naming configuration settings. Some examples of model names when using the Discovery configurations are as follows using the example of the device with Fully Qualified Host Name of 'device.company.com':
Model Naming configuration settings: 
Use Fully Qualified Host Name = No 
Model Naming Order set to:
  • IP Address
  • Naming Service
  • SysName
Pingable model will be created with IP Address as the models name.
Model Naming configuration settings: 
Use Fully Qualified Host Name = No 
Model Naming Order set to:
  • Naming Service
  • SysName
  • IP Address
Pingable model will be created with 'device' as the models name.
Model Naming configuration settings: 
Use Fully Qualified Host Name = Yes 
Model Naming Order set to:
  • Naming Service
  • IP Address
  • SysName
Pingable model will be created with 'device.company.com' as the models name.
If you have already discovered the Pingable models prior to properly configuring the Model Naming configuration options and they need to be changed, we are left with two options:
  1. Delete and rediscover, through a Discovery Configuration in the Auto Discovery UI, the Pingable models
  2. Manually rename the Pingable models