On 15 September 2020 10:17:09 CEST, "[email protected]" <[email protected]> wrote:
>On Monday, 14 September, 2020 19:38, "Radu-Adrian FEURDEAN"
><[email protected]> said:
>
>> On Sat, Sep 12, 2020, at 11:25, James Bensley wrote:
>>
>>> In your specific case/example; if I have a PE with a single physical
>>> interface connected to some 3rd party wholesale Ethernet NNI, with
>500
>>> sub-interfaces, each running OSPF to a remote CPE; if the physical
>>> interface goes down I don't need 500 SNMP traps or syslog messages
>to
>>> tell me that all 500 OSPF sessions are down. There are two sides to
>>
>> OTOH, if the NNI service goes down (circuits are interrupted), but
>the interface
>> stays up, you will be happy to know that ALL circuits are down (or at
>least which
>> of them went down) when you open a ticket to the NNI provider.
>
>And in an ideal world, of course, your monitoring platform will do
>intelligent root-cause analysis, suppress all the individual circuit
>alarms, generate a single master alarm for the NNI for the NOC to deal
>with, and notify all the impacted customers of the master ticket.
>
>I'd usually want to err on the side of having more data and putting
>appropriate filtering between the data and the person viewing, rather
>than NOT having data it later turns out would be useful.
Yeah well that's the ideal dream scenario. The reality is that many operators
(especially small operators who's entire OSS stack is a single
Observium/LibreNMS/Cacti/Solarwinds/whatever server) can't handle this.
I wonder if Cisco have tried to do what they did with LPTS in IOS-XR and
implement what they consider a "sensible" default, i.e., the control plane is
not fully open and unlimited, and not 100% closed by default, but some rate
limiting is implemented out of the box as a compromise.
I guess the OP's concern is that there doesn't appear to be a command (unless I
missed it?) to change the threshold above which XR starts surprising traps?
Cheers,
James.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
