[c-nsp] OSPF LSA timers

[Oliver Boehmer (oboehmer)]

Raymond Lucas <> wrote on Tuesday, June 02, 2009 08:10:

> Hi,
> 
> I have been gradually rolling out OSPF across a network including the
> following bit of config:
> 
> router ospf 172
>  ispf
>  timers throttle lsa all 10 100 5000
>  timers lsa arrival 80
> 
> Which was fine until I arrived at a couple of 6506s with SUP2/MSFC2
> running 12.2(17d)SXB9 which don't support those commands.  Seems they
were
> only introduced in 12.2(18)SXF according to Software Advisor.
> 
> We can't upgrade to 12.2(18)SXF due to a lack of memory on the switch
> processors.  I'm not too worried by the "ispf" business, but I have a
> bad feeling about having a couple of devices different from their
> neighbours with the LSA stuff.  To really up the nerves, these 6506s
> are are part of the core.  I can imagine it working well most of the
> time but then failing badly when the pressure is on.
> 
> So I guess my questions are:
> 
> - Am I right to be worried, or will things work fine if I miss these
> commands from these devices?

It'll work most of the time, until you run into situation where you need
to issue more than one LSA update per second (for the very same LSA id).
As the other devices will ignore the 2nd LSA update, you'll have to
retransmit and convergence will be delayed.

> - Since these timers can only be set on a per device basis, as
> opposed to per interface, is there an elegant way to deal with this
> scenario? Obviously I would not be keen to remove the modified timers
> from the rest of the network!

Well, if you really need these timers to meet your convergence targets,
you're out of luck and need to upgrade the devices. I would argue,
however, that you'll be able to get away with less aggressive LSA update
timers (i.e. timers throttle lsa update 10 1000 5000) in most scenarios.
Tuning SPF timers is usually more important..

	oli