[c-nsp] Reasons for "random" ISIS flapping?

[Pete Lumbis]

I'm not 100% sure I think the "connected" rate limiter works like uRPF. If
it's not on the right interface we ignore it. That's one of the compelling
reasons to run the other rate limiters.

I don't know if this was mentioned before, but I'd also strongly advise
against tight protocol timers like you are running and allow BFD to do that
work. Because BFD is done either in hardware or under the interrupt the
likelihood of a false positive like this is MUCH lower, especially with
these very small CPU events. By running BFD and tight protocol timers you
are actually putting more load on the CPU. I'd suggest 1sec hold /3sec dead
protocol timers at the lowest.


On Wed, Aug 28, 2013 at 5:06 AM, Peter Rathlev <peter at rathlev.dk> wrote:

> On Wed, 2013-08-21 at 23:29 -0400, Pete Lumbis wrote:
> > Was the traffic from a connected source? The rate limiter you
> > mentioned only applies for local sources
> >
> http://www.cisco.com/en/US/docs/ios-xml/ios/security/m1/sec-cr-m2.html#wp1716645027
>
> I guess technically it was from a "local source", since it was the
> neighbouring router that put it on the LAN and it thus hit the device
> from the LAN side.
>
> > The key would be to understand the punt reason for that traffic, most
> > likely through a NetDR capture.
>
> Only problem is that it lasts only for up to one second, so I'm not even
> sure EEM scripts could catch it.
>
> > As a wide net here are some rate limiter numbers I found. YMMV.
> >
> > mls rate-limit all ttl-failure 100 10
> > mls rate-limit multicast ipv4 fib-miss 10000 250
> > mls rate-limit multicast ipv4 partial 500 250
> > mls rate-limit multicast ipv4 connected 2500 250
>
> Thanks. We're using something not unlike this on most devices, but the
> affected one only had the "connected" rate-limiter at the time. We've
> corrected this and also stopped the original source. We'll have to wait
> till next time (if there is a next time) to see if this actually
> helped. :-) So far it looks good.
>
> --
> Peter
>
>
>