OSPF Mesh - Single or MultiArea

[J_Vansen_S]

Hi All,

We are in the process of upgrading & re-designing an existing university campus network from 1G to a mesh of 10G core backbone.

The objective of the project is basically high availability & redundancy.

Based on my draft diagram, end results will be connected as drawn.

My doubt is; whether i should stick to only use OSPF Area 0 for all the routed device or to split it to MultiAreas?

We are talking about 7 core routed devices with about 10 networks/vlan behind each Building

Will multi-area ospf benefit me in this design?

I have a hard time figuring out how to segregate it into different areas & also slightly confused on how i would go about configuring multiarea in a mesh topology, because every router more or less interconnected to each other.

Fyi we are using Catalyst 3850 as routed devices for the campus

Appreciate any advise

[Julio E. Moisa]

Hi

You could keep a single OSPF area (area 0) on your topology, it depends of the amount of routers, models and their resources. Also I recommend select manually the most robust routers to be the DR and BDR OSPF Routers. As it is a partial mesh, you could select the main building as DR and building 1 as BDR, Also the link between them should be taken in consideration because it could be a transit link if one of the router fails. The link between Building 2 and 3 could be removed, the building 4 could connected to building 1 instead building 3. Other tip could be the use of security into OSPF processes.

The following link could be useful:

https://orhanergun.net/2017/03/ospf-best-practices/

Please rate the comment if it is useful.

:-)

[Joseph W. Doherty]

Will multi-area ospf benefit me in this design?

Not likely.

I have a hard time figuring out how to segregate it into different areas & also slightly confused on how i would go about configuring multiarea in a mesh topology, because every router more or less interconnected to each other.

Well you could place "Main",  #1 and #3 in area zero, and have #2, #4, #5 and #6 each in their own area.

[Richard Burts]

While it is certainly possible to implement this network as OSPF with only one area I would suggest that there might be benefits to a multi area implementation. Bear in mind that if you implement as a single area then a change in one subnet in one building will cause all of the OSPF router to run the update algorithm to update its Link State Database and to calculate new content of the IP routing table. If you implement multi area then a change in a subnet in one building will not impact OSPF routers that do not connect to that area.

If you want to implement multi area my suggestion would be to configure area zero to include all the links that connect the routers. And then to configure a separate area for each building for all of the subnets in that building.

HTH

Rick

[Joseph W. Doherty]

Rick is correct, a route change, even out on an edge, will impact all the routers within the same OSPF area.

However, for just 7 (?) routers, I don't believe the complexity of a multi-area design is worth its trouble to implement.  (Although what Rick suggested, I believe would be a much better approach for a multi-area design than what I used as an example of such a design.)

What Rick didn't mention, by default, a multi-area design may still impact all routers, as route changes flow between areas.  The latter can be controlled by using ABRs to summarize and filter what flows between areas, but again, I believe that's a bit complex for just 7 routers.

In other words, when Rick wrote "If you implement multi area then a change in a subnet in one building will not impact OSPF routers that do not connect to that area.", isn't 100% correct without taking advantage of what can be done with multi area designs.  Also, a route update across areas is likely to have less impact to an OSPF router than a route change within the same area.

Further, to minimize the impact of some link changes within an OSPF area, later Cisco OSPF implementations support iSPF.  To also minimize the risk of OSPF churn, you can enable route dampening and/or tune OSPF timers.

BTW, an old rule of thumb was to have no more than 50 routers within a single OSPF area.  In actual production networks, the ideal number of routers per OSPF area depends on many variables, with actual topology, platforms, and stability possibly these three being the most notable.  Again, it would be an unusual network of 7 routers the actually needs what a multi-area OSPF design provides.

[Richard Burts]

Joseph makes a valid point and I should have written a bit more carefully about the difference of handling changes within an area and handling changes from a different area. We both agree that processing a change of any subnet within the area requires running the Dijkstra algorithm to converge the area and agree on the least cost paths available. And it must be run on every router that belongs to that area. Processing a change from a different area is done without requiring the Dijlstra algorithm and so is a much less impact, but I overstated when I said no impact.

As I think about this discussion I will also offer the observation that if the original poster were to decide to use multi area OSPF, with each building having its own area, and if they choose to configure each non-backbone area as totally stubby, then my original statement would actually be true. With totally stubby areas a change from area 1 would have exactly no impact in area 2.

Joseph also makes a valid point about the size of the network. If there are only 7 routers (as seems to be the case) and if there are about 70 subnets in the network, then it is a real judgment call whether the benefits of multi area outweigh the effort needed to implement it. My instinct is to prefer multi area and to believe that even though the benefits are not large that they justify the effort of using multi area. But I acknowledge that choosing single area is also a valid option.

HTH

Rick

[Joseph W. Doherty]

With totally stubby areas a change from area 1 would have exactly no impact in area 2.

Agreed.

As I think about this discussion I will also offer the observation that if the original poster were to decide to use multi area OSPF, with each building having its own area, and if they choose to configure each non-backbone area as totally stubby, then my original statement would actually be true.

Not exactly.

Area zero routers (BTW all 7 routers [if I correctly understand what Rick is suggesting]) would "see" the stub area route change unless you summarized the stub's routes to the backbone.

We both agree that processing a change of any subnet within the area requires running the Dijkstra algorithm to converge the area and agree on the least cost paths available. And it must be run on every router that belongs to that area. Processing a change from a different area is done without requiring the Dijlstra algorithm and so is a much less impact, but I overstated when I said no impact.

Yep, we do agree, although again, if the ISPF feature is enabled (http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/ospfispf.html), a change out on the edge, which is what Rick's multi-area design (nicely) addresses, requires much less Dijlstra processing.

. . . then it is a real judgment call whether the benefits of multi area outweigh the effort needed to implement it.

Rick's 110% right on this, and this is part of the "art" of network engineering.  Some issues are not really right vs. wrong, but philosophical - good for endless debates ;)

[J_Vansen_S]

Thanks to all for your recommendation.

Based on Julio;s suggestion to remove fiber link between building 2 & 3, and connect building 4 to building one; i have a nice star topology going on.

Then again based on my understanding to incorporate multiarea is it correct to do it as attached diagram? Anything else facing my building LAN, i would assign it as a different area. There won't be any more routing devices going on behind each building, just switching.

[Joseph W. Doherty]

Then again based on my understanding to incorporate multiarea is it correct to do it as attached diagram?

I believe that's what Rick was suggesting.

Are all the links between routers p2p?  If so, BTW, you won't have a DR/BDR (I'm not suggesting that's a bad thing).  Also, you can use /31s if you want for your p2ps.

PS:

Since your going by Julio's suggestion, I've just now glanced at his reference, and it too recommends against a multi-area OSPF design unless you really need it.  The author notes he is both a CCIE and CCDE.  The latter is a "design expert".

Your 2nd topology design will work, but again for my two bits worth, you're adding OSPF complexity I don't believe is warranted in your case. However, your physical topology is better.