OSPF SPF Calculations ABR / Internal Routers

[chira.cipri@gmail.com]

Hello, 

I have a question regarding what does and what does not trigger an SPF calculation. 

I have the topology attached in the picture below. All routers have OSPF enabled on all interfaces. All areas have default status. Routers R1,R3 are internal routers of area 0. Router R4 is an internal router of area 1. Router R2 is an ABR, with interfaces  Fa0/0 and Fa0/1 belonging to area 0 and Fa1/0 belonging to area 1. 

My question is the following.

Should a flap on interface Fa1/0 of R2 (simulated by a shut/no shut) trigger an SPF calculation in area 0 ? 

From my understanding, the answer should be no. The SPF algorithm is run per area. R2 being an ABR keeps 2 separated databases, one for area 1 and one for area 0. 

However, checking the number of SPF calculations and both R1 and R3 and analyzing debug ouput, it seems that shut / no shut on Fa1/0 of R2 triggers SPF calculations on both of them.

What is the rule here ? A flap on ABR leads to SPF calculations in all the areas to which the ABR belongs to ?  From the debug output on R1, I see the SPF calculation is triggered by a change to the type 1 LSAs. I thought ABRs kept a different type 1 LSA for each area to which they belong ? 

The devices are all Cisco 3745 routers running IOS 12.2 done using GNS3. 

[Peter Paluch]

Hello,

Very good thinking!

It is true that because of an interface flap in Area 1, the topology in the Area 0 does not change, so it would seem that Area 0 does not need to reflect in any way.

However, R2 is responsible for advertising every network reachable in Area 1 using LSA3 into Area 0. If you flap f1/0 on R2, the network on R2 becomes unreachable and comes back again. Both these events cause R2 to advertise a new LSA3 for this network into Area 0. Consequently, Area 0 routers have to run their SPF to process the new LSA3 and update their routing tables.

You are very correct that as far as Area 0 is concerned, nothing inside Area 0 has changed. What has changed is a leaf node behind R2 where the topology is no longer visible. Therefore, OSPF can invoke a limited recomputation which is known in IS-IS as Partial Route Calculation (PRC) in which the entire topology does not need to be recalculated, only the placement of the leaf nodes is reexamined. This is not really mandated by the RFC 2328 where OSPF is standardized - it depends on the sophistication of the particular implementation of OSPF whether it can make use of the PRC.

The bottom line is: True, Area 0 has not changed, but an information about a network in a different area has changed, and therefore Area 0 still has to update its routing tables through SPF.

Feel welcome to ask further!

Best regards,
Peter

[chira.cipri@gmail.com]

I'm still puzzled. Quoting the CCNP OCG, page 337, Ch 8, The OSPF Link-State Database

To take the analysis a little deeper, remember that an internal router, when finding the
best interarea route for a subnet, uses the intra-area topology to calculate the cost to
reach the ABR. When each route is identified, the internal router adds the intra-area cost
to the ABR, plus the corresponding Type 3 LSA’s cost. A change to the Type 3 LSA—it
fails, comes back up, or the metric changes—does impact the choice of best route, so the
changed Type 3 LSA must be flooded. However, no matter the change, the change does
not affect the topology between a router and the ABR—and SPF focuses on processing
that topology data. So, only changes to Type 1 and 2 LSAs require an SPF calculation. 

 And for the record, if I shut / no shut an interface on R4 (internal to Area 1, not show in topology), this does not trigger an SPF calculation in Area 0, even though the Area database gets changed (adding and removing the type 3 LSA).

[Peter Paluch · Accepted solution]

Hello,

Oh, right, I guess now I know what's happening :)

If you shut down f1/0 on R2, R2 stops being an ABR because it no longer has active interfaces in multiple areas. Each router advertises whether it is an ABR in its own LSA1 in the Options field using the 'B' bit. If you shut down f1/0 on R2, it stops being an ABR, and needs to both flush all LSA3 it has originated, and flood an updated LSA1 in which the 'B' bit is cleared. When you bring up f1/0 on R2 again, it becomes an ABR again, and needs to flood again an updated LSA1 with the 'B' bit set.

That would explain why you see the SPF being executed in Area 0, and the reason for the SPF being an updated LSA1 from R2.

It should be noted that there is a certain freedom in what to understand under "SPF". In a very literal sense, SPF involves recomputing the topology, so any change to LSA1 or LSA2 in the given area causes an SPF run. The calculation performed as a result of an updated LSA3, LSA4, or LSA5 is not SPF in the strict sense, but some resources use "SPF" in a (slightly imprecise) way as "any part of OSPF best path selection algorithm", even if it does not involve recomputing the whole topology.

Once again, feel welcome to ask further!

Best regards,
Peter

[Giuseppe Larosa]

Hello Peter,
I strongly agree with you: given the network topology and the fact R2 is the only ABR(0,1), fas1/0 is the only link in R2 that is part of area 1. So shutting fas1/0 causes two things:
R2 router LSA in area 0 header changes a flag as you explained telling it is not anymore an ABR node;
R2 purges any LSA type 3 it has generated for the area 1 internal topology and these summary LSAs can be or not a "summarization" they represent prefixes with prefix length but topology details are hidden.

Thanks again for your contribution
Best Regards
Giuseppe Larosa

[chira.cipri@gmail.com]

Confirmed with packet capture, the reason for the SPF calculation is an updated type 1 LSA with the B bit set to 0. That was the trigger for the SPF calculation.

Late reply, I know :)

[Joseph W. Doherty]

BTW, to add to Peter mention of PRC, later Cisco OSPFv2 implementations support an "ISPF" option within the OSPF process.
Also as an aside, if on R2 you summarized area 1 routes, area 0 routers would not "see" any indication of the area 1 topology changes.

[Peter Paluch]

Hi Joe,

Indeed, the support for incremental SPF, or iSPF, has been with IOS for quite some time. I would, however, draw a difference betwee iSPF and PRC. iSPF is still an SPF run, that is, the Dijkstra algorithm run over the link-state database; however, it is started and run only for a subset of all nodes and links. PRC, on the other hand, involves only operations on leaf nodes, not really running Dijkstra at all.

Best regards,
Peter

[Joseph W. Doherty]

Peter, I guess you don't work much in environments with some equipment that's so old it doesn't support ISPF. ;)

[Peter Paluch]

Joe,

As of matter of fact, lately I started supporting customers running some quite ancient versions of operating systems :)

The ispf command has been around since 12.0(24)S:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_isis/command/irs-cr-book/irs-a1.html#wp2737150805

But yes, it generally isn't available in pre-12.3T releases.

Best regards,
Peter

[Joseph W. Doherty]

"But yes, it generally isn't available in pre-12.3T releases."

Right - generally only available in IOS releases, say released in the last 15 years or so? Such aren't ancient, they're only broken in. ;)

[Peter Paluch]

Hi Joe,

I defer to your life experience and expertise :)

Best regards,
Peter