Cisco Three Layer Hierarchy?

MattMcNabb

I am currently studying for the CCNA and I am struggling with visualizing the application of Cisco's design model. I know that this is a bit outside the scope of the CCNA but ultimately I may be designing a small or medium business network and I would like to be able to apply best practice methods when doing so.

So are there any practical tutorials regarding how to apply the ideas of Core, Distribution, and Access layer design. For instance, where would the Core be in a typical medium sized network? Would this simply be the WAN connections between sites? Is there any need for a Core layer if there is only one physical site?

I am picturing a single site design that simply has switches for host access and routers to provide inter-vlan communication but this doesn't include any Core services. Is this a problem?

Sorry if this seems like a dumb question.

Forsaken_GA

MattMcNabb wrote: »

I am currently studying for the CCNA and I am struggling with visualizing the application of Cisco's design model. I know that this is a bit outside the scope of the CCNA but ultimately I may be designing a small or medium business network and I would like to be able to apply best practice methods when doing so.

So are there any practical tutorials regarding how to apply the ideas of Core, Distribution, and Access layer design. For instance, where would the Core be in a typical medium sized network? Would this simply be the WAN connections between sites? Is there any need for a Core layer if there is only one physical site?

I am picturing a single site design that simply has switches for host access and routers to provide inter-vlan communication but this doesn't include any Core services. Is this a problem?

Sorry if this seems like a dumb question.

It really depends on your scale. If I have alot of internal traffic, I typically do not have my core routers also performing as my internet routers, I deploy separate routers to function as border routers above the Core.

One common mistake newcomers make is not making the distinction between the network (campus network, Enterprise network, etc), and the internetwork. Honestly, I use border routers for pretty much any design, no matter how big or small. I like the flexibility of being able to keep policy for my internal routing and my external routing completely separate. Then the only consideration about external traffic I need to worry about internally is how to deliver it to the border routers, and let them handle it from there.

When I put together a network, the internetwork tends to be a separate module of the network. And depending on the type of connection to the internet you have, you may not have the option of deploying your own gear as the edge device (ie, Comcast Business connections is going to make you put their gear in play, typically, and then you put yours behind that).

At the bottom of the stack you have your access switches. These are where your end devices connect to. Those then aggregate back up to distribution switches, which do all of your policy enforcement, filtering, and etc. The distribution switches aggregate back to the core routers/switches which then handle the routing and switching within the internal network as necessary. All the core does is move packets around, whether that's from one distribution switch to another, or from a distribution switch to the border routers for internet connectivity (and vice versa), doesn't matter, the core just flings packets/frames around as quick as possible.

Now, if your network is small enough, there's nothing wrong with implementing a collapsed core. That's where the same devices perform the core and distribution functions. This is absolutely fine if you don't require the performance of handilng those functions in the same layer, or if the traffic you're doing isn't enough to actually kick over a performance threshold. It all depends on the needs of the business.

I'm personally a big fan of modularizing a network as much as possible. This keeps the design, layout, and traffic flow simple to visualize and simple to troubleshoot, and it keeps any failures localized to that particular module (network wise, anyway. If your database servers are segmented from your web servers, and the database section loses connectivity, obviously it will have an impact on the web servers as well. By the same token, if your web server section loses connectivity, it doesn't effect anything else that needs the database servers - but if the database servers were located in the same module as the web servers, then everything that requires the database servers would die, and so on. How you design is up to the particular needs of the company).

So I set each module up with it's own access and distribution switches. The distribution switches handle any communication needful within the module, and relay everything to the core that needs to talk to somewhere else. Going back to my web server and database example again, the traffic flow is predictable - database server to access switch to distribution switch to core to distribution switch to access switch to web server, and vice versa.

This all works wonderfully for single sites. When you have multiple sites sizeable in nature, then things get a little more interesting. For example, if I have offices in Austin and Atlanta, and the Austin offices need to access resources in Atlanta, how those sites interconnect is a big deal. If I have a private circuit, or an MPLS circuit, I can treat them like they're just another module. If they're coming in over a VPN tunnel, or worse, from directly over the internet, then that starts screwing with my ability to keep things simple, and introduces points of failure that make me cranky. Unfortunately, keeping everything logical and organized is a significant investment in time and money. If either one of those resources is lacking, or unwilling to be expended, that's when you start getting network designs that I can only politely categorize as 'creative'.