NetOps Reachability Threshold Event Raise missing as Spectrum Alarm
search cancel

NetOps Reachability Threshold Event Raise missing as Spectrum Alarm

book

Article ID: 246312

calendar_today

Updated On:

Products

CA Performance Management - Usage and Administration DX NetOps

Issue/Introduction

I have created a threshold profile as Reachability(%) <=0 generate major alert. We have two tenants in PM, Alarms are being sync from PM to Spectrum to the tenant 1 but not for 2.

DX NetOps Performance Management Portal raises Reachability Threshold Violation Events. The Event Raise and Clear works properly in the NetOps Portal.

The device the Events are raised against is properly synchronized between NetOps and Spectrum.

The Event Raise is never seen as an Alarm in Spectrum. The Event Clear is only seen as an Alarm in Spectrum.

The trigger used to generate the Reachability drop for this test is changing the IP on the DA Pingable item to an invalid IP address.

Environment

All supported DX NetOps Performance Management releases

Cause

Changing the IP Address on the DA only item, not also the Spectrum version of the device model at the same time, triggers creation of a new item for the 'new' Pingable with the new IP Address set. That generates a new ItemID for it before the Event Raise happens. When the Event Raise takes place the new ItemID isn't known as one from Spectrum. Thus the Raise is not seen in Spectrum as an Alarm.

The reset of the IP Address in the DA, back to the correct IP Address also used by Spectrum sets the ItemID back to the one that IP item originally used. Now the Event Clear is triggered against the original synchornized ItemID allowing it to be seen as an Alarm in Spectrum.

Resolution

To resolve this there are two options.

  1. Change the IP Address on the Spectrum model for the device, then change the IP Address on the Data Aggregator item for the device. Both must be changed before the Event Raise to test this scenario in an expected manner.
  2. Recommended test path: Block communication between the test device IP and the Data Collector polling it. This will have the same effect, causing a Reachability drop for testing.
    1. Tips:
      • Run the commands in the terminal CLI of the Data Collector managing the device IP involved.
      • Replace <deviceIP> in the command with the device IP involved.
      • May require root privileges.
    2. To block communications run:
      • iptables -A OUTPUT -p icmp --icmp-type echo-request -d <deviceIP> -j REJECT
      • Sample using IP 1.1.1.1:
        • iptables -A OUTPUT -p icmp --icmp-type echo-request -d 1.1.1.1 -j REJECT
    3. To unblock communications run:
      • iptables -D OUTPUT -p icmp --icmp-type echo-request -d <deviceIP>  -j REJECT
      • Sample using IP 1.1.1.1:
        • iptables -D OUTPUT -p icmp --icmp-type echo-request -d 1.1.1.1 -j REJECT