Over the past week we have seen a number of BAD LINK DETECTED alarms, yet there has been no trap from the device nor any change in the interfaces status. One interface in particular has generated this alarm 4 times in the past 5 days. I will upload screen shots of the interfaces Information screen from Spectrum. As well as downloads of the Events.
The link is configured as an inactive failover in a lag group but the device does not support LACP functionality.
So Spectrum sees this as a monitored link even if it has been down since discovery. The initial alarm was cleared but reasserted by Inference Handlers when the parent device lost management contact with Spectrum. As the device has some SNMP problems, it loses connection with Spectrum occasionally and Fault intelligence asserts a link down on this interface via inference handler.
Release : 10.3
Component : Spectrum Core / SpectroSERVER
Since there is a connection to a device model on this down interface any changes in the status of that device would be looked into by the fault isolation logic. I've found that all of the BAD LINK DETECTED alarms coincide with DEVICE HAS STOPPED RESPONDING TO POLLS alarms for the device model. All of the stopped responding alarms were short in duration. To avoid this short outages from alarming, increase the polling parameters for timeouts and retries. This has avoided the "stopped responding to polls alarms" on the device as well as the erroneous bad link alarms on the interface.