multiple OSPF areas on ABR best practice

[Buddy_Olli]

Hi,

let's assume customer has an hub and spoke topology where the hub is the ABR and arouns 120 spoke location are connected to it. The hub is connected per area0 to the Datacenter switches. 

Customer asked if it is possible that each spoke location will be put into one area. So that there are 121 areas (120 spoke area + area0). 
See picture:

Is this a valid design ? Is that recommended or are there any considerations or drawbacks ? 
Alternatively we could put all the spokes into one area (i.e.100), so that we only have 2 areas. 

What would be the better design and why ? How about CPU and memory consumptions for both design. What is the better solution ?

Many thanks and Kind Regards,
BuddyOlli

[MHM Cisco World]

I think non of what you sharing is optimal 
NOW 
you need to make spoke ABR 
this done by config LAN behind it as Area X and connect between Spoke and Hub in area 0
this make you do some area range and control which prefix can advertise 
MHM

[Buddy_Olli]

Hi,
thanks. You means something like this:

I didn't understand the benefits exactly. Could you please explain again ?

Many Thanks,
Buddy Olli

[MHM Cisco World]

YES Correct 

In your original post the spoke router is internal and all prefix is LSA1 or LSA2 and in ospf all router in same area have same database' this make hub router have all prefix of all spoke (LAN behind) that to much even high end router can not handle these huge lsa.

Now be make spoke router is ABR 

The hub router will have only lsa3 for LAN behind spoke and even this ypu can use area range and reduce it.

Also you can control if you want to advertise LAN  or not via spoke router since it now ABR.

Hope it now clear 

MHM

[liviu.gheorghe]

Hello @Buddy_Olli ,

the optimal solution is the first one - each spoke in its own distinct area.

The second scenario is not optimal because being in the same area 100, a link down from one spoke will force every router in area 100 to run SPF algoritm. Also all spoke routers being in the same area, the necessary CPU and RAM resources on the spokes will be higher in order to acomodate a greater number of LSA's. In the first scenario, only the ABR's would have to have greater resources which I think is cheaper than having 120 routers with greater resources.

[Buddy_Olli]

Hello,
thanks for the answer. Yes, that's what is also thought. It keeps the SPF algorithm low because if anything happens in area 17, only devices in (i.e. area17) have to recalculate.

Many Thanks,
Buddy Olli

[Giuseppe Larosa]

Hello @Buddy_Olli ,

here the problem is the number of concurrent OSPF areas on the Hub router(s)  121 Areas is not best practice.

All info has to be copied and recreated in each area by the ABR.

Using totally stub areas for each spoke might work but not with standard areas.

The design suggested by @MHM Cisco World  gives you the control of what you advertise in each branch office towards area0 and you can also play with area type using totally stub areas or totally NSSA

Hope to help

Giuseppe

[liviu.gheorghe]

Yes, that's the ideea. Also don't forget that the spoke routers are lower in terms of resources which is leaner on the budget.

[Buddy_Olli]

As  MHM Cisco World   added another solution, i put now the 3 alternatives below.

Solution1 (ABR on Hub, 121 areas on Hub/ABR):

Pro:  It keeps the SPF algorithm low because if anything happens in (i.e. area 17), only devices in area17 have to recalculate.
contra:

Solution2 (ABR on Hub, 2 areas on Hub/ABR):


Pro:
contra: a link down from one spoke will force every router in area 100 to run SPF algoritm. Also all spoke routers being in the same area, the necessary CPU and RAM resources on the spokes will be higher in order to acomodate a greater number of LSA's.

Solution3 (ABR on each Spoke):

Pro: It keeps the SPF algorithm low because if anything happens in area 17, only devices in (i.e. area17) have to recalculate. 
contra:  more expensive, because 120 ABR L3-switches routers with greater resources required.



So in theory solution 3 is best but it requires more resources ? Would a Catalalyst 9300-24T be enough for an ABR on each spoke?

Again, many thanks for your oppinions.

Kind Regards,
BuddyOlli

[liviu.gheorghe]

Solution 3 has another drawback - all 122 routers being in area 0, if one link flaps every router must run SPF which means higher chance of instabilities.

[MHM Cisco World]

Requires more resource!! Check my previous comment 

For 9300 still it SW but it enough for this task.

MHM

[Buddy_Olli]

Hi,
Thanks again.

c9300-24T is too low for working as an ABR ? (solution 3). It only has area0 (towards Hub) and one more (i.e. area_17) locally. 
Is this true ? If that is the case (since the spokes are already 9300-24T switches) the ABR role cannot be on the spoke and then the only solution would be Solution 1 or 2.   

And then i am back to my initial post. ABR on Hub. But with 121 areas or with 2 areas. What would consume more CPU/memory ?

Please note: The Hubs currently are C9500-48Y4C and customer plans to extend them cascading L2 Switches (c9200) for port extension in order to connect all 120 spokes). I fear that they are also not large enough for this task ?!


Solution1 (ABR on Hub, 121 areas on Hub/ABR):

Solution2 (ABR on Hub, 2 areas on Hub/ABR):


I am a little confused now.

As iviu.gheorghe wrote:
the optimal solution is the first one - each spoke in its own distinct area.

The second scenario is not optimal because being in the same area 100, a link down from one spoke will force every router in area 100 to run SPF algoritm. Also all spoke routers being in the same area, the necessary CPU and RAM resources on the spokes will be higher in order to acomodate a greater number of LSA's. In the first scenario, only the ABR's would have to have greater resources which I think is cheaper than having 120 routers with greater resources.

or as MHM wrote:
In your original post the spoke router is internal and all prefix is LSA1 or LSA2 and in ospf all router in same area have same database' this make hub router have all prefix of all spoke (LAN behind) that to much even high end router can not handle these huge lsa.

or as Giuseppe Larosa wrote:
here the problem is the number of concurrent OSPF areas on the Hub router(s) 121 Areas is not best practice.
All info has to be copied and recreated in each area by the ABR.

Are there any other opinions ?

Again, thanks for the discussion.

BuddyOlli

[Joseph W. Doherty]

BTW, I recall just as it once was suggested not to have more than 50 routers per area, recall it was also suggested not to have more than 3 areas on an ABR.

Both those suggestions likely had much to do with the processing capacity of a router, at that time, along with the OSPF implementation then wasn't as sophisticated as Cisco's now is.

As you listed just 2 areas vs. 120+, both have their advantages and disadvantages.  Cannot truly say what I once did is better, but had designed an OSPF area topology where groups of remote sites were placed in the same area, this to limit total number of areas on hub while limiting size of each area.  I.e., perhaps something like 10 areas with 12 remotes in each to 20 areas with 6 remotes in each.

Also, in the prior design, spoke sites were different sizes (from 1 router to a campus), different bandwidth links based on need, geographical across the Americas, so area assignment took all that into account, too.

Again, cannot claim the above truly advantageous over the other possible area designs.  Can say, though, didn't have any OSPF issues.

[Joseph W. Doherty]

Just a few other thoughts.

First, keep in mind OSPF processing is control plane, and L3 switches are often comparable weak for such.

Second, there's often huge differences in Cisco's OSPF implementation compared to many other vendor's implementation when it comes to stability.

Third, there are other OSPF design options that impact how well a particular OSPF topology will behave.  Such as, already mentioned by other posters, kind of OSPF area or ABR address summarization (the latter I used in my prior reply's OSPF topology design).

[Giuseppe Larosa]

Hello @Joseph W. Doherty , @Buddy_Olli 

the suggested approach is likely a good tradeoff:

>> perhaps something like 10 areas with 12 remotes in each to 20 areas with 6 remotes in each.

Regarding the number of routers in a single area the limit of 50 is an old guideline and some providers have 300 routers in area 0 with no issues.

Hope to help

Giuseppe