Spectrum Policy setting interface Alarm attributes so as not to raise Alarms, however, some alarms are still raised.

Products

• Network Observability
• Spectrum

Issue/Introduction

A Spectrum policy is set to configure the following attributes to No or Never to prevent alarms being raised:

AlarmOnLinkDownTrap
AssertLinkDownAlarm
GeneratePortStatusAlarms


However, Interfaces under the GC with the policy applied still generate alarms, even though the attributes have been set accordingly:

Environment

DX NetOps Spectrum all currently supported releases

Cause

There are two possible causes:

1. Timing. All the alarms in this list (21 Jun, 5 Jul, 15 Jul, 25 Jul) predate the current day (4 Aug). Policy attribute changes in Spectrum are not retroactive — they stop new alarm generation going forward, they don't clear or suppress alarms that were already asserted before the attributes were set. If the policy was applied recently, these could simply be old, un-cleared alarms still sitting in the list. Worth checking: when was the policy actually applied to the GC, relative to these alarm timestamps? If all of them predate the policy, this isn't a missing attribute — it's just alarms that need to be manually cleared/acknowledged (or that will stop appearing going forward).
   
   
   
2. The "BAD LINK DETECTED" may not be governed by those three attributes. AlarmOnLinkDownTrap, AssertLinkDownAlarm, and GeneratePortStatusAlarms control the standard link-up/down and port-status alarm paths. "BAD LINK DETECTED" is a distinct alarm class in Spectrum (tied to physical-layer/duplex-mismatch or error-rate detection on the interface, not simple oper-status), and it's often gated by a different attribute than the ones your policy currently sets. If new instances of this alarm keep appearing after the policy was applied, that's the real signal something's missing.

Resolution

To confirm which case you're in, open the Root Cause or Events tab on one of these alarms (right-click the alarm → Root Cause, or the Events tab in that same Component Detail window) — it'll show the exact event/condition code that triggered "BAD LINK DETECTED". That event code, looked up in the Event Configuration Editor, will tell you the specific attribute the CT checks before asserting that alarm — and that's the attribute to add to the policy if it's not already one of the three you have.

Additional Information

KB : How to Configure Port/Interface alarming in DX NetOps Spectrum when a port/interface model goes down?