So we have had incidents, on a couple of occasions now, where our Spectrum 9.2H3 will see an interface go "down", but will not generate any kind of event for it. The last time this happened we (CA Tech and myself) speculated that the device was unreachable and when it came back up, it suppressed the alarm of the secondary interface. I don't think any of the event data clearly supported that, but it was the best we could come up with. So that ticket was closed yesterday and it just so happens that today we have a similar issue. An interface was down for nearly 10 hours before someone noticed, no thanks to Spectrum. It is not a good thing to have the credibility of your monitoring tool come into question. I am hoping someone here can share with me (us!) their methods for tracing the non-trap related event path in Spectrum. The trap alarms seem a bit easier to manage due to the external files. The internal workings of Spectrum are mysteries.
I tried to re-model the current device we are having issue with, but the interface is discovered in the down state, so it still doesn't help or indicate an alarm. If this happens again, what steps should I take to isolate the problem? Which attributes should I be focusing on with regard to the parent model and the component model? How can I manually force Spectrum to acknowledge and generate an alarm on an interface that is "down" (red)? Spectrum's current issue is with a Cisco 6509 and I would not be surprised it that is related to the issue, but our previous issue was with a 7206VXR. Also, the previous issue involved a POS interface where as the new issue is with a Gigabit ethernet interface. The similarities are few. Any advice is appreciated. -Ken --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected]
