Hi,
Port monitoring it's a complex task. There are many possible cases and
parameters you can configure.
I think most important attributes to watch are (I also indicate my
personal best choice):
-> In VNM model:
· Fault Isolation
- Port Fault Correlation: All Connected Ports - Multiple Devices Only)
· Live Pipes:
- Live Pipes: Enable
- Alarm Linked Ports: No
- Suppress Linked Port Alarm: No
- Port Always Down Alarm Suppresion: Enabled
-> In every port model (you can create a policy to configure all ports
with same values. there is an example in
$SPECTROOT/PolicyMngt/Spectrum):
ok to poll (0x11dd8) -> If you enable live links, you change this value to TRUE
PollPortStatus (0x1280a)
AlarmOnLinkDownTrap (0x11fc2)
AssertLinkDownAlarm (0x12957)
GeneratePortStatusAlarms (0x12a54)
Here my approach is to create two policies: One for ports with a
modeled connection and other for unconnected ports:
Values for connected ports:
ok to poll: true
PollPortStatus: true
AlarmOnLinkDownTrap: 1
Values for unconnected ports:
ok to poll: false
PollPortStatus: false
AlarmOnLinkDownTrap: 0
AssertLinkDownAlarm: false
This way I cover most cases, regardless you received or not link up/down traps.
I hope this can help you.
Regards.
James.
On Thu, Apr 28, 2011 at 8:47 AM, Kenneth Kirchner <[email protected]> wrote:
> 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]
>
---
To unsubscribe from spectrum, send email to [email protected] with the body:
unsubscribe spectrum [email protected]
