12-03-2019 02:35 PM
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.
Thanks.
Solved! Go to Solution.
12-04-2019 08:19 AM
Hello,
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...
12-04-2019 12:34 AM
Hello,
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...
12-04-2019 06:44 AM
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 10.20.0.0/16 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 10.48.0.0/16, 10.60.0.0/16, and 10.73.0.0/16 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.
12-04-2019 06:58 AM
Hello,
the plan sounds feasible. Just make sure that all areas are (obviously) connected to area 0.
12-04-2019 08:09 AM
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.
12-04-2019 08:19 AM
Hello,
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...
12-04-2019 09:05 AM
Thank you, appreciate your assistance.
12-04-2019 10:45 AM
12-04-2019 10:57 AM
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.
12-04-2019 11:35 AM
12-04-2019 12:51 PM
One common network segment, a /24 used for only this express purpose. It's provider-managed L2 MPLS for what it's worth.
12-04-2019 01:34 PM
12-04-2019 01:52 PM
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.
12-04-2019 09:17 AM
Hello
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
12-04-2019 11:07 AM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: