One single TRAP associated to several devices raising an Alarm

Products

• Spectrum
• Network Observability

Issue/Introduction

CA Spectrum SpectroSERVER had created multiple same alarms due to one single TRAP received. It appears this single TRAP was mapped to many Spectrum device models for this SpectroSERVER. Each alarm then needs to be managed even that TRAP was sent by one device only. It is not possible later on to find out which device had truly sent the TRAP. 
 

CA Spectrum TRAP processing intelligence will receive the inbound TRAP and will then check for the sender IP-address in the SpectroSERVER modeling. 
Expecting the management address is unique (or overall the device configurations may not cover duplicate IP-address configurations) the inbound TRAP is then asserted to one single device. Unfortunately this is not always the case. 

Background here is the discovered device "DeviceIPAddressList" (see Spectrum device model attribute "DeviceIPAddressList") covering all known(configured) IP-addresses for this device context. By this item a single IP-address could be found for many devices - even per each of these devices the primary management address is unique and not indicating any conflict. 

Receiving the TRAP then goes through all "known devices" covering in the "DeviceIPAddressList" the TRAP source(sender) IP-address.
Therefore the TRAP is asserted to multiple devices. 

Environment

This applies to all supported CA Spectrum platforms.

Resolution

Solution is per:

1) manual workaround via: https://ca-broadcom.wolkenservicedesk.com/external/article?articleId=14576

    This is a manual workaround to make use of CLI to purge off single/specific entries from the device DeviceIPAddressList table attribute. 

 

2) The underlying functionality is in parts "FAD"/functioning as designed by default -

    but CA Spectrum with release R10.2.1 and higher already covers an improved functionality. 

 

   This is triggered/managed via attribute "UseRPAForTrapProcessing" for the 

   SpectroSERVER's ./SS/.vnmrc settings: UseRPAForTrapProcessing=true

 

Using this setting will then control the inbound TRAP processing to assert the TRAP to only those devices covering in the IP-redundancy (Primary Address list) the given TRAP source IP-address.

 

Additional Information

Find more info also here: https://techdocs.broadcom.com/us/en/ca-enterprise-software/it-operations-management/spectrum/23-3/managing-network/modeling-and-managing-your-it-infrastructure/primary-ip-address-modification.html