ISIS Fast Flood

Unanswered Question
Jan 21st, 2009


I was reading IOS 12.2SR documentation for ISIS protocol and I came across ISIS Fast Flooding LSP configuration! It is bit dark for me to understand so any one has any idea about it? how does it works and how can i have an advantage to use it for fast convergence?

Is that all about to trigger SPF calculation after receiving defined amount of LSP?


Devang Patel

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Giuseppe Larosa Wed, 01/21/2009 - 13:57

Hello Devang,

the context is that of fast convergence.

the parameter of fast-flood is a number of LSPs that need to be flooded = propagated to other IS-IS nodes before starting local SPF calculation.

So it tells the router before running SPF wait to have flooded out last X LSPs.

The reasoning is that doing so reduces the overall number of SPF executions in the network (this is to avoid to have to execute SPF more times then needed)


flooding for OSPF and IS-IS means the process of propagation of new LSAs /LSPs

the concept is :

The router should always flood (at least) the LSP that triggered SPF before the router runs the SPF computation.

We recommend that you enable the fast-flooding of LSPs before the router runs the SPF computation, in order to achieve a faster convergence time.

The first requrement is to pass fresh link state info to other nodes just after having verified that is acceptable.

So it is a trigger for SPF calculation after sending out X LSPs

Hope to help


marikakis Thu, 01/22/2009 - 03:53


I agree with Guiseppe that delay in the flooding procedure might cause SPF to be executed more times. It is faster to run SPF once for, let's say, a group of 5 LSPs arriving close in time, than to run 5 SPFs, one for each LSP. Still, why send only a few LSPs and not even more so we can run SPF only once? Network needs to converge at some point, so we cannot wait forever. We need to start computing our shortest path tree reasonably soon.

I think there is an additional delay factor in the convergence procedure that is attacked with this feature and has to do with parallel computation as opposed to serial computation. Doing our SPF and informing others to start doing their own SPF work cannot be done at the same time. The less we send to neighbors, the faster we can start our SPF, but neighbors have to wait for us to finish so they can become informed about current status (serial computation) and this slow LSP propagation will move like a slow wave towards the neighbors of our neighbors and so on. If we just send them a little something before we start our SPF, they can start doing work at the same time we are computing our own SPF (parallel computation).

So, I think more work can be done in parallel if neighbors are given something to work on while we are doing our own work, but we only give them a "little something", because we need to start working soon to update our own forwarding state. With this scheme, SPF could still be run more than once in some nodes (because we are not giving them all the information we hold), but still changes are propagating fast across the network. This is clearly a tradeoff situation.

Kind Regards,


devang_etcom Thu, 01/22/2009 - 08:31


Thanks for reply but still I am trying to understand the function of it! as we are talking about sending few lsp and start SPF! can some one explain me the default function of this one and how will it make difference by putting lsp fast-flood?

How neighbor will come to know about when to start spf? how local router will decide when to start spf?


Devang Patel

marikakis Thu, 01/22/2009 - 14:55


Sorry about any confusion. In the link already posted by Guissepe you can see the following:

"If you are running SPF and if you have configured very short values (less than 40 milliseconds) for the initial delay that is set by the seconds argument of the incremental-spf command, the SPF computation might start before the LSP that triggered SPF is flooded to neighbors."

Incremental SPF is documented in the following document:

"The default number of seconds for incremental SPF to begin is 120 seconds."

Now, I am not sure how 40ms initial delay can occur since documentation suggests that the 'seconds' argument refers to seconds. In any case, what I understand is the following:

1. In many cases, default behavior is set to reasonable values based on lab and live network studies.

2. Default behavior might apply to you or it might not.

3. The feature you are asking about applies to the case where someone actually tries to modify default behavior using the incremental-spf command. That is, if you start changing protocol defaults, you might also need another button to tune things even more.

Kind Regards,



This Discussion