[c-nsp] ISIS/BFD Monitoring

Graham Beneke graham at enetworks.co.za
Mon Sep 18 02:13:31 EDT 2017


We have a similar challenge monitoring OSPF over layer-2 providers who
don't drop the physical port in a link failure.

We run syslog but find that it doesn't provide useful information of
state for the NOC guys. Most of the guys logging faults with vendors
don't understand the states and what they mean.

We have a set of threshold alerts on our NMS which flag when traffic
levels drop extremely low. This works well for major links that always
have traffic.

We also have setup "ip sla" on some links. The status of the ip sla can
then be polled by the NMS over SNMP to detect the state of the link.


On 16/09/2017 09:24, Alex K. wrote:
> Thank you Aaron.
>
> In my humble opinion, syslog is a bit inapplicable. The way I know it, it
> will have an error message like "ISIS session to <neighboring router
> hostname> changed to down" (maybe it do has interface name, I don't recall
> the exact message right now).
>
> Anyhow, not the neighboring router hostname nor interface name, have the
> exact circuit (that went down) information. In our case, it encoded into
> interface description.
>
> To your knowledge, the tools you mentioned, are able to append that
> information to the original syslog message?
>
> בתאריך 16 בספט' 2017 4:57 AM,‏ "Aaron Gould" <aaron1 at gvtc.com> כתב:
>
>> Kiwi syslogd or maybe splunk
>>
>> -Aaron
>>
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/




More information about the cisco-nsp mailing list