Does splitting the areas in OSPF reduce the size of the OSPF DATABASE

[Paheeradan Nagulan]

By splitting up the OSPF areas, I understand we are reducing the Type 1 and Type 2 LSAs in an area. But Type 1 LSAs  are regenerated as Type 3 LSAs and flooded into the other area. So in terms of sizing, is that really reducing the sizing of the LSDB? When talking about SPF Tree calculation, I can see the advantage of splitting the areas.

[M02@rt37 · Accepted solution]

Hello @Paheeradan Nagulan 

Yes, splitting OSPF areas reduces LSDB size per area because type 1 & 2 LSA stay local, and only sumarized type 3 LSA are flooded.

However, overall LSA count in the network may not reduce much since ABr still advertise inter-area routes. So, the biggest benefit is SPF optimization—SPF calculations stay within an area, so failures don't trigger recalculations everywhere, making the network more efficient.

[Paheeradan Nagulan]

Hi M02@rt37,

Yes, I do see the advantage in terms SFP Calculation. Thanks for mentioning that! 

[M02@rt37]

You're sol welcome @Paheeradan Nagulan 

[Joseph W. Doherty]

You correctly note the advantage of minimizing SPF calculations, but as too database size, that's an it depends answer.  If you use stub areas and/or ABR summarization, database sizes can be considerably reduced.

[Paheeradan Nagulan]

Hello @Joseph W. Doherty,

Yes. I agree with you. When I consider stud areas and ABR summarization, I do see the benefit of splitting areas. Thanks for mentioning it.

[Joseph W. Doherty]

BTW, don't forget, the purpose of OSPF areas is for scalability.  Part of the scalability is constaining database sizes, but it's not so much the physical size the database consumes that's impactful, but the additional processing needed by numerous entries.  Because SPF scalability issues, as has already mentioned, using multiple areas mitigates that.  But other scalability issues, caused by having a large volume of LSAs and/or routes, is also mitigated by using areas, but not by default.  That mitigation depends on configuration of areas.

[Paheeradan Nagulan]

Hi @Joseph W. Doherty , Understood. Thanks again!

[Giuseppe Larosa · Accepted solution]

Hello @Paheeradan Nagulan ,

in addition to what other colleagues have noted a multi area OSPF design provides you route filtering control at ABR level you can decide what internal prefixes are propagated to backbone area 0 aka 0.0.0.0.

This capability is limited to internal routes LSA type 1, LSA type 2 are stopped at area boundaries -> LSA type 3 are generated to represent IP prefixes ( so called DV in inter area)  and you can use area range to create summary routes that hide the details of what is happening within an area or even to avoid to advertise some of the component routes.

I see this as a great advantage of multi area design

area filter list can be used to decide using a prefix-list what IP prefixes go propagated or not.

When using stub areas, the best choice is NSSA as it provides the capability to still inject external routes into the NSSA allowing the ABR nodes (0, NSSA-area-id) to convert the LSA type 7 to LSA type 5.

To be noted with all stub area types all LSA type 5 received by ABR nodes via the backbone area are blocked not propagated into the stub or NSSA area.

The sentence about database size reduction is from the point of view of all routers that are internal to a non backbone areas of type stub, or totally stub or NSSA or totally NSSA.

the greatest reduction are the cases of totally stub or totally NSSA where there is a single O IA LSA type 3 0.0.0.0/0 (totally stub) or a single O N2 0.0.0.0/0 (LSA type / for the NSSA case)  representing all external routes ( LSA Type 5)  ( LSA type 4 ASBR nodes used in standard area to decide if the ASBR is alive) and also all LSA type 3 coming from other areas.

Final note about default route generated by ABR nodes:

for stub and totally stub the default route is generated automatically and we can just adjust the metric if you we want to have a preferred exit point to the backbone when two or more ABRs connect the same area.

For NSSA and totally NSSA the generation of a default route to be injected into the area is not automatic. The reason is that we can have the ASBR connecting to the internet placed inside an NSSA area. in this last case the default route is injected as LSA type 7 and converted to type 5 by ABR node(s). For all scenarios where the default route is actually coming from backbone the ABR nodes have to generate it and we need to take care of this with explicit commands.

For NSSA  route summarization has to use summary commmand instead of area range when the ABR is also the ASBR of an NSSA area. ( actually summarization happens on converted LSA type 5 before injecting them in the backbone area).

if the ASBR node is different from the ABR nodes. It is the only node that can perform route summarization of self generated LSA type 7.

Hope to help

Giuseppe

[Paheeradan Nagulan]

Hello @Giuseppe Larosa ,

Yes, when I consider stud areas and ABR summarization, I do see the benefit of splitting areas. Thanks for the detailed explanation. 

[Giuseppe Larosa]

Hello @Paheeradan Nagulan ,

you are welcome. Thanks for your kind remarks

Best Regards

Giuseppe