A device modeled in Spectrum is sending traps to Spectrum but no events are seen on the model for the trap

Products

• CA Spectrum
• DX NetOps

Issue/Introduction

A device modeled in Spectrum is sending traps to Spectrum but no events are seen on the model for the trap

 

Environment

Release : Any

Component : Spectrum Alarm & Event Management

Cause

There are several reasons why this can occur:

1. The device is not configured to send traps to the SpectroSERVER as thought

2. The traps are being blocked before they get to the SpectroSERVER

3. The trap is getting to the SpectroSERVER but the ip address is not a configured ip on the device

4. The trap is not mapped in Spectrum

5. The trap is a v3 trap and the v3 community string in the trap does not have an associated v3 profile in Spectrum 

Resolution

For each of the causes listed above:

1. The device is not configured to send traps to the SpectroSERVER as thought
ACTION: Double check the configuration on the device to ensure it is configured to send traps to the SpectroSERVER system

2. The traps are being blocked before they get to the SpectroSERVER
ACTION: Check to ensure  firewall is not blocking trap traffic between the device and the SpectroSERVER

3. The trap is getting to the SpectroSERVER but the ip address is not a configured ip on the device
ACTION: For a v1 trap, verify the agent-addr in the trap PDU is an ip address on the device model in Spectrum. For v2 and v3 traps, is is the source address of the trap.

To check the ip addresses Spectrum knows about for the model,

    a. Find and select the model
    b. Click on the Information tab in the Component Detail panel
    c. Find and expand the IP Redundancy subview
    d. Click on the "Configure Preferred and Excluded Addresses" button
    e. Verify if the ip address of the trap is in the list of ip address in this view

In the IP Redundancy subview, check if the "Use Redundancy Preferred Address List For Trap Processing" is set to No. If so, click on the "Configure Preferred and Excluded Addresses" button and see if the ip address of the trap in in the "Redundancy Excluded Addresses" list.

Check for an unmanaged trap event on the VNM model around the time the device sent the trap. If the ip address is unknown, then this event will be asserted on the VNM model.

Also, if the ip address is 127.0.0.1 or 0.0.0.0, the SpectroSERVER will automatically not process the trap.

4. The trap is not mapped in Spectrum
ACTION: Check the events on the model to see if an unmanaged trap event was logged around the time the trap was sent. Verify if this trap is a configured trap in Spectrum. It must be configured in at least one Global AlertMap file.

5. The trap is a v3 trap and the v3 community string in the trap does not have an associated v3 profile in Spectrum 
ACTION: Check the V3 profiles and ensure there is a profile for the v3 community string sent with the trap.