06-08-2011 10:37 AM - edited 03-07-2019 12:42 AM
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
06-08-2011 01:04 PM
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
06-09-2011 06:36 AM
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
06-16-2011 12:39 PM
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
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: