How are link down and link up traps and the "BAD LINK DETECTED" and "COMMUNICATION LINK DOWN" alarms generated in Spectrum?

Products

• CA Spectrum
• DX NetOps

Issue/Introduction

This TecDoc describes how link down and link up traps are processed in Spectrum and alerts such as "BAD LINK DETECTED" and "COMMUNICATION LINK DOWN" are generated by Spectrum.

Environment

Release: All Supported Releases
Component: SPCAEM - Events and Alarms

Cause

1. There is additional underlying code used to process the link down and link up traps.
2. The reason being is because traps are processed at the device level.
3. In order to process the link up/down traps on the interface model, when the traps are received, Spectrum reads the value of the ifIndex varbind sent with the trap, checks the status of the associated interface model and if ifOper down ifAdmin up, will assert the critical “BAD LINK DETECTED” alarm on the interface model.
4. In addition, if the AssertLinkDownAlarm attribute id 0x12957 is set to Yes on that interface model, then Spectrum asserts the minor “THE COMMUNICATION LINK IS DOWN” alarm on the associated device model.

 
AssertLinkDownAlarm (0x12957) - Determines if SPECTRUM should generate a yellow alarm on the device model when a link down trap is received for this port.  Valid values are TRUE or FALSE.
 

1. This minor alarm should be cleared when either the 0x00220102 or 0x00220103 events are generated on the device model. It does not use an event discriminator.
2. Most customers find this minor alarm to be useless because the critical alarm is asserted on the interface. That is why the AssertLinkDownAlarm attribute id 0x12957 is set to No by default.
3. One major issue with this alarm is if when the first link down trap is received, the minor alarm is asserted.
4. While this minor alarm is asserted, if another link down trap is received for a different interface, it does not generate a new alarm, it increments the occurrence value of the existing alarm.
5. In addition, if a link up trap comes in, it clears the minor alarm even if there is still a critical alarm on a different interface.

Resolution

Bad link Detected:

Every time the ‘Internal_link_status’ attribute is read (by a user from the UI, or CLI, or by code, stemming from polling, or fault isolation, traps, or even from neighbor devices interested in the attribute, etc) then we recalculate its value.

If we find that the new link status is not ‘Good’, we will check the ‘GeneratePortStatusAlarms’ (0x12a54) attribute, and, if set to ‘Yes’, we will generate the link event (and alarm) on the port model. So the bad link alarm may stem from any of the reasons above, simply reading the internal_link_status from the UI can cause it.

Setting the ‘GeneratePortStatusAlarms’ attribute to ‘No’ is the recommended setting if you don’t ever want to see such alarms on that port.
Bad link detected is generated via Spectrum´s fault intelligence.

Communication link is down:

This means an there is an unstable link such as a flapping port on a device.

The attribute ‘AssertLinkDownAlarm‘ (0x12957) attribute on the interface determines if this is generated and this attribute can be verified by both polling and trap.