OSPF database drops some links instantly, others an hour later

[CriscoSystems]

Here's a thing (ok, two things) I didn't expect. I wanted to experiment with manual OSPF summarization; so I created a bunch of loopbacks on Router A (internal in Area 1) and routed them into OSPF.

Happily, they appeared in Router J's (internal in Area 2) table, as well as in its ospf database (naturall). All was well.

The first mistake I made was to configure the "area 1 range" command on Router A, which isn't an ABR. Router F is ABR for Area 1; so I wa surprised the IOS allowed me to configure the area range command in the first place.

I removed it from Router A and entered it on Router F.

The summary route appeared in J's routing table, as I expected. What surprised me was that all the specific links that had been summarized had also vanished from J's ospf database.

I thought entries weren't supposed to leave the database until they've been dead for an hour. I've brought down links physically yes PHYSICALLY in ospf networks, and while they always leave the routing table promptly, they have remained in the ospf database for hour.

So why did the specific (30-bit) networks get purged immediately when the summary (28-bit) network showed up? What's the reasoning behind holding on to an LSA for an hour after the link is known dead, but flushing a specific LSA when an inclusive summary arrives?

The former isn't in line with the goal of keeping the database lean. And I'm not sure that the latter is in line with keeping the database thorough.

[Giuseppe Larosa · Accepted solution]

Hello Stuey,

>> The summary route appeared in J's routing table, as I expected. What surprised me was that all the specific links that had been summarized had also vanished from J's ospf database.

Router F after the configuration of area range command does the following:

generates a summarized summary route type 3.

sends out the LSAs for the specific routes with a flag or setting that says to all routers "purge them from database"

So this is a case of explicit withdrawl of component routes and for this reason it is so fast.

This is done as part of the area summarization process that is intended to minimize OSPF DB size.

In the other case, there is no node that sends an explicit message that tells to purge the LSAs so they are left there to silently expire at the end of max age.

In other words: one event is the consequence of an explicit configuration action on the node, the other one is a network fault.

Hope to help

Giuseppe

[CriscoSystems]

Grazie come sempre, Giuseppe.

Is the instruction to purge the non-summary routes Cisco-only behavior, or is it in the RFC spec?

[Giuseppe Larosa]

Hello Stuey,

I think the explicit suppression of component subnet LSAs is standard.

the reference is for OSPFv2 as usual

http://www.ietf.org/rfc/rfc2328.txt

see sec. 12.4.3

for example the advertise do not advertise is standard (the do not-advertise feature is the old way to perform inter-area route filtering).

I didn't find explicity a sentence that says after you configure an area range the following happens but it looks like logical to do so.

Hope to help

Giuseppe