cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3999
Views
5
Helpful
3
Replies

SPF Recalculations - Route flaps

sachinraja
Level 9
Level 9

Hi All

I have constant SPF recalculations, which caues routing table to update (random times).. I have gone through lot of posts here, but wanted to confirm a basic question that I had.

We have routers where the routing table looks like the one given below:

O E1    172.23.0.x/32
           [110/2] via 10.59.x.x, 00:13:50, TenGigabitEthernet1/1
O E1    172.23.32.z/32
           [110/2] via 10.59.x.x, 00:13:50, TenGigabitEthernet1/1
O E1    172.23.57.xx/25
           [110/2] via 10.59.x.x, 00:13:50, TenGigabitEthernet1/1

Area 0 seems to be stable, but there is an area 59 where this SPF re-calculation is happening. I see it on all the routers connected on area 59. My question is:

1) When this re-calculation happens, and when the routing table gets refreshed, is there a chance that there are packet drops to the networks in that OSPF domain ? eg 172.23.0.x/32 shown above?

2) I havent still run debugs on these routers , not looked indepth on interface/ospf flaps, but when this flap happens, what is the impact for the routes being refreshed ? I hope this is partial spf calculation, and may be there are very few subnets which are flapping or for which the LSA is being updated?

Area 59
     Number of interfaces in this area is 76 (1 loopback)
     SPF algorithm last executed 00:20:32.360 ago
     SPF algorithm executed 16549 times

3 Replies 3

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Sachin,

>> SPF algorithm executed 16549 times

1) well if the LSA is removed/purged and then reinstalled, there may be a small time interval  the corresponding route will be missing, and traffic with that destination will follow the default route, if one is present in this OSPF domain, or it will be dropped. In both cases this can be a problem

2) partial recalculation should apply, almost sure with newer devices and IOS versions. I see a tengiga outgoing inteface.

I wouldn't use any debug command.

Looking at the ospf database should be enough to find out the originating nodes, accessing the affected ASBR node(s) should give you a chance to understand what is happening.

If the originating node is a multlayer switch the problem may be at OSI layer2 on the link(s) connecting to the other routing domain ( outside OSPF I mean)

Also LSA sequence numbers will be much higher for affected LSAs, so again the ospf database provides you all the required information.

Hope to help

Giuseppe

Hi Giuseppe

Thanks so much for your reply (as always)..

Just for your info, we also have a couple of more areas on this ABR (Area 154/155), where there are OSPF flaps. We see SPF calculations for those areas because of these flaps (which is understandable). But area 59 is still restarting SPF every now and then. I went thro OSPF database and did not see any sequence numbers which are high.. btw, can the LSA type 1 messages from area 154/155 cause SPF recalculations on other areas connected on that ABR ??

ABR (has area 0, area 59, area 154, area 155) ---> area 154/155 has ospf neighbor flaps...

btw, there is a default route which is not statically defined, but learnt through OSPF too.

Regards

Hello Sachin,

sorry for late answer I guess you have already fixed this issue

>>

can the LSA type 1 messages from area 154/155 cause SPF recalculations on other areas connected on that ABR ??

yes if it becomes an LSA type 3 at area boundary

you are right probably external LSA are not flapping but only LSA type 1 or type 3 and type 4 related to ASBR node

you should find an LSA type 1 flapping in originating area

Hope to help

Giuseppe

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: