Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Campus Design with OSPF and Routed Access Layer


I'm using the document High Availability Campus Network Design Routed Access Layer Using EIGRP or OSPF (

to design a new building to an existing network (3 buildings).

In this document the Distribuion Switch is the ABR. Today there are a lot of routers in my Area 0 (another buildings) and I didn't wanna to increase the area 0 without necessity.

Can I use the Core Switch to do the ABR role or I always have to use the

Distribution Switch as a ABR

Thanks in Advanced

Andre Lomonaco


Re: Campus Design with OSPF and Routed Access Layer


The maximum benefit with regard to route convergenece, fault tolerance and scalability, according to the document, is to superimpose the physical topology of the heirarchical campus model distribution blocks with the logical topology of OSPF areas.

So, the point they are making is that each distribution block can be considered its own area -- stub or totally stub area, to be exact -- and with the distribution switches acting as the ABRs, they can inject a default route into the access layers for the entire network outside the area, thereby descreasing the size of the routing table and speeding up convergence over equal-cost paths between the routed access layer and the distribution switches.

Having said all that, the question I have for you is, if you want to make the core switches the ABRs, what then will be the area boundaries? I would think off the top of my head that that will create a rather flat network, with a huge area with a lot of routers and links and tons of subnets in the routing table. You lose the benefit of logical and physical segmentation.

Dont you think?


New Member

Re: Campus Design with OSPF and Routed Access Layer

Hi Victor, thanks a lot for your response

I agree 100% with you about the benefits of using the distribution as ABRS. What I disagree is about lose create a rather flat network.

Imagine two distributions blocks 100 and 110 and take a look in the attachment (VisaoOSPF.jgp). I think you can reduce the routes in the access and distribution routers using totally stub as usually...

What i really don't like is put the access and distribution routers in the same OSPF heirarchical. I started to have all the functions (aggregation, security, etc) in the core....

Do you agree with me??

More one question, do you prefer configure each distribution block as a stub or totally stub area ?? I read some SRNDs put the distribution block as a nssa area...

Sametimes a lot of options is not so good :)

Thanks again for your reply

My Best Regards,

Andre Lomonaco


Re: Campus Design with OSPF and Routed Access Layer


Now I have a better picture of what you have and what your vision for the future is.

What you're showing me is basically a collapsed core design, where the core router will act as the ABR, inject the default routes into the areas, and execute all the policies that the distribution switches would normally handle. I think it is important to understand how large these areas will be and how many distribution blocks will comprise the area.

Interestingly, though, don't you think that your routing, security and aggregation policies should really be implemented at the distribution level, where it will service the users and devices in their respective area -- and the core should not be doing anything but acting as a superfast packet pusher that interconnects separate network modules?

I mean, this of course is the classic, textbook Cisco hierarchical approach, but every network has its own specifics and there are also budgetary and corporate political constraints to contend with.

Given what you have and where you want to go, what function would the distribution switches have within the areas? They wont be executing any policies and all they will be doing is accepting a default route from the core, which will actually be doing the aggregation. No?


Thanks for the rating, by the way.