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

Pete Lumbis alumbis at gmail.com
Thu Aug 29 12:00:05 EDT 2013


I don't see it as an either/or question. You still need BFD for failure
detection. Nothing happens until a failure is detected. (r)LFA fixes the
rest of the convergence equation, mainly the time it takes to notify
neighbors and recompute a path and what can be the biggest delay,
re-programming the data plane on hardware platforms.

Since LFA does this all ahead of time you can keep traffic flowing as soon
as the failure is detected (+ the time it takes to move a single pointer).
It's also not a replacement for IGP tuning (like SPF calc delay) but it
makes it a lot less important.

Overall I'm a big fan of LFA, if you can spare the TCAM/hardware adjacency
space for it (remember, you are programming two entries in for every path
that is backed up. The original primary and the backup path). It's TE-FRR
for the rest of us.


On Thu, Aug 29, 2013 at 10:14 AM, Mark Tinka <mark.tinka at seacom.mu> wrote:

> On Thursday, August 29, 2013 03:54:47 PM Pete Lumbis wrote:
>
> > I don't want to confuse aggressive IGP hellos with
> > aggressive  IGP protocol tuning. I'm all for tuning SPF,
> > et al. timers under the protocol. It's the only way you
> > get fast convergence. My beef is with sub-second hellos,
> > which BFD does a better job of.
>
> Yes, agree - BFD takes care of the Hellos.
>
> Any thoughts of dumping BFD in favour of (r)LFA?
>
> Mark.
>


More information about the cisco-nsp mailing list