Showing results for 
Search instead for 
Did you mean: 

Using OSPF areas, single-router summarization

Level 1
Level 1

Greetings.  Due to acquisition of devices that does not support EIGRP we're preparing to migrate to OSPF.  The topology consists of dozens of sites, each site linked to the service provider's metro ethernet network at L2, all sites directly adjacent to each other as if they're plugged into one gigantic switch.  Each site basically has a /16 assigned, carved up with about ten subnets per site.  A few sites have further downstream sites colocated, with their own /16, also carved-up into around ten subnets.  One branch router exists per site, with no further routers downstream within a site itself.


With EIGRP summarization was easy, but with OSPF's summarization only occurring on ABRs it looks like rather than having approximately a hundred routes for the branch sites I'll end up having closer to a thousand.


I have labbed setting up branch routers as an ABRs, placing the LAN-facing interfaces (SVIs) into newly-defined Areas, allowing me to summarize the /16 for each branch router into Area 0 on the metro ethernet segment.  This is working fine in the lab with having just one router per new area, but obviously this is just a lab, not production.


Is this a common or accepted use of Areas and ABRs?  I assume having a hundred sites directly adjacent to each other means I should take steps to simplify as much as possible.



1 Accepted Solution

Accepted Solutions



the design looks fine to me. If you use stub or totally stubby areas, or summarization, you should be able to keep the database small. It also depends on how stable or unstable your network is...

View solution in original post

14 Replies 14



actually, 30 to 50 routers max are recommended within a single OSPF area, in order to avoid the exact problem you are describing, which is the OSPF database getting too large. You cannot summarize within a single area, as you have correctly stated. One would need to see exactly what your topology looks like, but maybe your best option is to put each site in its own area, and make these areas totally stubby, so the link state database will be as small as possible...

This is an example of what I'm describing.  Obviously there are far more service-provider-facing routers than fit on this diagram.  I've also made up the numbers, but in a nutshell this looks like what I'm working with.




So basically I'm looking at having all of the WAN-facing interfaces in Area 0, the LAN-facing interfaces and possibly the interfaces to colocated sites in new areas, Based on the primary site's Area.  So Site 20 as an example, the LAN interfaces would be in Area 20, so I could summarize Area 20's networks with into Area 0. Site 23 would have Area 23 on its LAN interfaces.


What I'm considering, for a Site like 23, is for the transit networks from Site 23 to Sites 48, 60, and 73 remaining in Area 0, and then putting those sites' LAN-facing interfaces into Areas 48, 60, and 73, again for easy summarization.  Alternately all of those sites could be in Area 23, but that would mean configuring summarization for,, and on Site 23's router, rather than at each local site's router.


I'm also tempted to try to have the two DCs set up as Areas 1 and 2, but we'll see.



the plan sounds feasible. Just make sure that all areas are (obviously) connected to area 0.

Depending on what will be approved, based on what you've said for the number of routers in a given Area, I'm leaning towards a solution where the colocated sites are in the area for the site from which they receive service.  With this arrangement I'll still have over seventy directly-connected sites in one area, but with the summarization at the ABRs hopefully that won't swamp the routers.




It'll still be around 75 routers in Area 0, possibly more if they want the DCs to be in Area 0.  



the design looks fine to me. If you use stub or totally stubby areas, or summarization, you should be able to keep the database small. It also depends on how stable or unstable your network is...

Thank you, appreciate your assistance.

"It'll still be around 75 routers in Area 0, possibly more if they want the DCs to be in Area 0."

On modern Cisco routers, that's unlikely to be a problem, especially as your topology is mostly a simple ring. That recommendation, noted by Georg, not to exceed 50 routers per area, is "old". It was, and still is, much of an "it depends" answer.

Traditionally, what's been considered the Achilles' heel of OSPF has been its usage of Dijkstra's algorithm. As router's have grown in processing performance, they can deal better with larger and/or more complicated topologies. Additionally, later Cisco enhancements, such as iSPF may mitigate the impact of running Dijkstra's algorithm.

Next, traditionally, has been the problem of dealing with large route tables (although it's bit like comparing apples vs. oranges, when it comes to handling large route table, consider Internet BGP). Again, routers have come a long way, and features like CEF have much mitigated forwarding performance issues.

Over the years, Cisco has done much else to allow OSPF to work well, using larger topologies, that would crush other vendors. I.e. I wouldn't be overly surprised that a Cisco OSPF implementation, for your topology, could run well using just one area. That said, I'm not suggesting you don't consider areas.

To your question of what most would do, most, I believe, would suggest some form of stubby areas. Personally, I have a slight preference (assuming you have an address scheme that allows it), using summary addresses on the ABRs. This because I feel the issues created by stubby areas are a bit worse than those created by using summary addresses, but both do have "gotchas".

Considering the limited number of networks you generally have, behind what would be your ABRs, I suspect you probably don't need either summary addresses or stubby areas. The area partitioning, alone, should constrain the impact of running Dijkstra's algorithm (again likely so would iSPF, but using areas is a bit "safer" and would allow usage of summary or stubby areas, if found needed).

I suppose I should add, the routers facing the Metro Ethernet WAN are ME3600X.  They're upwards of a decade since initial launch, and these will be in-service for the foreseeable future.  That's a large part of what's driving my concerns.


Additionally it's not a ring topology, it's full-mesh entirely managed by the service provider.


If I don't use Areas I'll have more than a hundred routers in the Backbone Area.


It's funny, I already sat-for and passed my CCNP SWITCH exam, I was lamenting my lack of OSPF experience and putting-off ROUTE because of that.  Looks like that has come to an end.

Cisco switches tend to have "weak" control plane capabilities (as all the heavy processing is done by dedicated hardware for the data plane). Cisco switches, the smaller one, also don't have the hardware resources to deal with massive routing table issues either. So, for such, you're right to be much concerned about what will be passed about with OSPF. (BTW, do you keep the IOS somewhat current?)

Regarding the number of routers, with OSPF is more an issue of the number of links and stability of those links.

I did miss seeing the "full mesh" in your diagram (oops, mistook the ABR area 0 line as a ring). So each ABR has a p2p link to every other ABR (i.e a true full mesh), or do they share just one (or few) common network segments?

One common network segment, a /24 used for only this express purpose.  It's provider-managed L2 MPLS for what it's worth.

Ok, then you likely have the need to choose your DR and BDR.

OSPF, topology wise, will only see one link. Should make for a very, very small area zero topology.

So total number of routes, for you OSPF topology, somewhere in the thousand neighborhood?

Right now I have about 500 EIGRP routes on the branch router I randomly chose, 89 of which are summarized /16 networks.  Those 89 would be a little under 900 if not summarized, so around 1300 routes total if no summarization is employed.


just like to add you could go a step further and cut down on the link state d//b  advertising by having each site in Stub or NSSA areas setup

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards

I'm evaluating which kind of stub areas would work.  It looks like since I only have one ABR for any given additional Area for all but two areas, I could go with a Totally Stubby configuration and let the ABR handle the routing, even for Areas with downstream routers.


My guess is that the consultant will have a hand in the DCs, mainly on account of the ISPs.  It does amuse me to consider that a Totally Not So Stubby Area might be the best configuration for the DCs.

Review Cisco Networking for a $25 gift card