Cisco Campus Network Design Basics


(Rene Molenaar) #1

This topic is to discuss the following lesson:


(Michael M) #2

Very Very good article Rene. Im so impressed and smiling right now.
I have seen designs where the firewalls are sitting on an access layer switch. Does it make sense to do that? Isnt there a “rule” that says that access layer switches should be used for your end stations or servers not for firewalls?


(Rene Molenaar) #3

Hi Michael,

Glad to hear you like it :slight_smile: Security will depend on which access layer we are dealing with. For example, we could have a “switch block” with a distribution + access layer that is only used for end devices like computers / laptops. You probably don’t want to use any firewalls there…not because there are no risks but it will be very expensive.

You can configure your switches for some of the security risks on the access layer here:

- Port Security: against MAC spoofing / setting a limit to number of MAC addresses per port.
- DHCP Snooping: so nobody can spoof a DHCP server on the access layer
- IP Source Guard: so nobody can spoof an IP address.
- Dynamic ARP inspection: against ARP poisoning.
- Storm Control: against broadcast storms or excessive traffic.
- Access-lists: for simple filtering.

If you have a “switch block” for your server farm then it’s possible that you want some extra security (firewalls) on the access-layer.

Rene


(Srinivas R) #4

Hi Rene,

A well written article on campus network design.

How can we have redundancy for each VLAN at the access layer?

Thanks,

RS

 

 


(Rene Molenaar) #5

Hi RS,

Glad to hear you liked it.

There are a number of things you can do in the access layer. First of all, we use protocols like HSRP / VRRP / GLBP so that hosts in the access layer have a redundant gateway, redundant uplinks to the distribution layer is easy with Etherchannels.

An access layer switch that fails will still result in hosts without connectivity. You can get around this by using stacked switches and connecting your hosts to two different switches, this might be interesting for certain devices (servers) but a bit too expensive for regular hosts.

Rene


(aicha m) #6

Hi Rene,

I am planning to change the design of my network and add more switches, but I am stuck. My end goal is to make everything virtual. Do you have any advice on how to do that?

Thanks
Aisha


(Rene Molenaar) #7

Hi Aisha,

When it comes to Cisco IOS switch virtualization, you can choose between VSS and stackwise. I would suggest looking at the current catalyst models that support this. How big is your network?

Rene


(Abdool Y) #8

Rene i see on some designs on the Core and Distribution where they have L2 and L3 in between the two switches.
What is the purpose for both L2 and L3 connectivity?


(Rene Molenaar) #9

Hi Abdool,

The “recommended” campus design nowadays is to keep VLANs only locally to the switch, and not to span them across switches. The advantage of this is that you can route anything and you don’t have to use spanning-tree to create loop-free L2 topologies. Routing protocols like OSPF or EIGRP are also fast compared to spanning-tree.

However, sometimes we do need to span VLANs over multiple switches…perhaps you have some applications/devices that have to be in the same VLAN to communicate with each other. That’s why you might see L2 trunks in between the distribution and/or core layer.

If you have a L2 trunk, adding L3 is really easy…you only have to add some SVI interfaces for each VLAN and you have L3 connectivity :slight_smile: We often use this for protocols like VRRP/GLBP/HSRP and perhaps routing protocols like OSPF/EIGRP.

Rene


(Muhamad M) #10

hey Rene! you are great…
thanks for everything.
this is the best network learning site that i’ve seen .
Please continue this project.


(florian k) #11

Hi Rene,

thanks for this post! Its good.
Just two questions:

  1. You mention at the one picture that vlan10 could become isolated if there wasnt an uplink between the two distri switches and if one link from the access to the distri would fail. But there would still be a second uplink to the distri switch, so how would be vlan become isolated.

  2. at the same pic you say that the link between the two distris is needed as FHRP protocols will use it for mgmt packet exchange, but couldt they also do it via the access layer? I know this wouldnt be best practice at all but it would work, right?

Thanks

Florian


(Lazaros Agapides) #12

Hello Florian.

Can you be more specific concerning the diagrams and the lesson that your question refers to? I was unable to find what you are referring to in the “Cisco Campus Network Design Basics” lesson.

Thanks!

Laz


(Helen N) #13

Hi Rene
I have a lot of doubts about LAN packet filtering I know that is to being done in the distribution layer but having many access lists becomes complex to manage.

Waht you recommend for filtering between LAN users do you have any documents about this?

Thanks a lot


(Lazaros Agapides) #14

Hello Srinivas

Redundancy at the access layer has to parts. One is the uplink from the access layer to the distribution layer. This can be configured so that there is redundancy for each VLAN by having each access switch physically connect to multiple distribution switches (most often 2, but more can be implemented). These links in the vast majority of situations would be trunks, and as such, VLANs can be configured to be allowed on these multiple trunks thus allowing for multiple paths from the access layer to the distribution layer for each VLAN.

The other part of redundancy at the access layer, which I suspect your question was more centred around, has to do with the connection of each end device to the access switches. In most cases, each end device will be connected to an access port and thus will only have one VLAN assigned to it. The only way to have redundancy here is if the end device has multiple NICs and connects to two access ports of the same VLAN. The end device would have to have the ability to do NIC card teaming (which creates a virtual NIC that manages the two links as one) or you would have to configure some routing commands in the end device so that alternate routes, i.e. alternate NIC cards can be used if one of the two goes down. Such a configuration is usually created for servers which have high availability requirements. This is seldom done for end users because of cost (double the port usage, therefore double the number of access switches) and because that kind of redundancy is not necessary for the vast majority of end users.

I hope this has been helpful!

Laz


(Brian C) #15

Hi Rene,

I am back! lol…

I wanted to explore the comment on recommendations to design VLANs only locally to the switch. We have a basic campus design with the core being in the data center, but managed by myself. we have two stacks of 4 switches. one in the west closet one in the east closet they connect to a double stack of switches that is our distribution switches.

On our access switches we have VLAN for VOIP and for DATA and for Printers and wireless private and wireless guest. So we have a few VLANs for this. If we was to not have VLANs spanning the access switches we would have many more VLANs that would connect up at our distribution switch where we have Switched Virtual Interfaces (SVI). From here we have OSPF that routes to our Core switch in the data center.

we have around 300-380 PC devices which connect into phones on shared cable into the access switches. I am curious as to thoughts on not spanning VLANs over access switches and when this should really be applied as it does add a little bit of complexity to the VLAN design though nothing that is to vexing.

I am just trying to make heads of this recommendation of not to span VLANs and where the grey area is at on this and how to best judge decisions in regards to this in my own mind.

I almost forgot to ask how this would be effected by subnets or would there be no effect. in other words if you had a subnet for your voice traffic would you not have to create another subnet for the new VLAN if you broke your traffic up into different VLANs. The reason I say that is because using a SVI you would need a different gateway for each SVI VLAN so that would mean you would have to have different subnets for each of those VLANs which would create more complexity that I first thought.

Respectfully,

Brian


(Lazaros Agapides) #16

Hello Brian

In general it is good practice to keep your VLANs as local as possible. The reason for this is if you have VLANs spanning multiple access switches, then any broadcasts that occur will be using up bandwidth in your distribution layer devices, and maybe even in your core layer devices. Broadcasts can include DHCP requests, routing protocol advertisements and IGMP traffic to name a few.

It is a good idea to break up your network segments so that they are as physically local as possible. That means that each access switch stack will have its own voice VLAN and its own data VLAN and if it needs to communicate with the voice or data VLAN on the other access switch stack, it will have to be routed at the distribution layer via an SVI.

Adding more VLANs will obviously add more administration overhead, so there are cases where you can safely break this rule. For example, the management VLAN can span all your access layer switches for convenience, since very little traffic will be going over the network on this VLAN. It is a delicate balance between network efficiency and ease of administration.

The quick answer to this question is yes, your subnets would be affected. You would require a separate subnet for each local VLAN that you would create. So if you have a voice VLAN 30 on the east access switch stack and a voice VLAN 31 on the west access switch stack, then you’d need a separate subnet for each VLAN, and communication between these two VLANs would require routing via an SVI as your gateway.

As you say, this configuration does add complexity but it allows your network to run more efficiently. Ultimately you must balance complexity with ease of administration so that the result will best provide for your needs.

I hope this has been helpful!

Laz


(Brian C) #17

Thanks Laz!

So if I can only sneak this into my network I would. if it was not for the changing of subnets which are server side handles the DHCP it would be pretty easy for me to just upgrade over the weekend and nobody would even be the wiser. However, I would have to come up with subnets and that would be much more noticeable =(

We don’t have a ton of computers so its probably not needed enough to cause a bunch of headaches but its good to understand it in case the change is something we are forced to do later because of traffic or performance. I really want to do it lol…

I am addicted to networking just like a gamer might be addicted to MMO. I even try to find places to volunteer at for free to be around other network people. I am the only network guy at my global company which is a shame but I am just glad I was able to wiggle my way into it as I use to be system administrator on server side only for them but soon as out network engineer left I managed to get my foot into that spot.

I see so many things done wrong and since I am the new guy its harder to get the management to listen to me even on silly things like we should separate the voice traffic in Europe from the data traffic like we do in the US. I will keep banging at it till they give in or I decide to give u the money and just go to a company where I can work with good networker engineers who I can learn from and grow with.

Or maybe I will get lucky and get both!!!


(Lazaros Agapides) #18

Hello Brian

It really sounds like you’re a hard core networking guy. That’s great! You know, I’d say that Cisco engineers in general share a unique camaraderie that’s unlike anything else. Others can’t understand why we like networking so much! It’s just cool! I understand you completely.

As for the opposition you face when suggesting best practices in networking, it’s usually the case where you’d have the administration opposing changes “since everything already seems to work.” It’s when things fail because of lack of redundancy, or voice and data on the same VLAN or other similar issues that they come back and say “well why didn’t we do it right the first time?” It’s a matter of making them understand the issue in simple terms, which is not always easy! :slight_smile:

I’m glad we can be of help to you here at Networklessons. This really is a great place for network-loving engineers to dig deeper into the things we like so much…

Keep at it and looking forward to continuing our discussions!

Laz


(AZM U) #19

Hello Laz,
I have a OSPF design question mainly and I am going to use the below topology as the reference.

In this design, I have a pair of Campus core and a pair of data center core routers. Here I am running OSPF area 0 between Campus core and Data center core devices. Also I am using different areas between Core switches and different Distribution blocks. I am configuring Totally NSSA in all the areas other than area 0 so every area will have only the default route from the core switches. Core routers will advertise each other only the summary routes of different distribution blocks. For instance, Campus core pairs will advertise summary of different distribution blocks to the Data center core routers and vice versa. Therefore, every distribution switch will have only one route in their routing table that is only the default route and core routers will advertise only the summary routes of different distribution blocks to each other. What do you think about this design? Do you think I should modify anything or it is one of the best practices?

Thank you so much in advance.

Best Regards,
Azm


(Rene Molenaar) #20

Hi Azm,

Using totally NSSA on your distribution layer is fine, these devices only need a default route to get anywhere else. You need to take a closer look at your core layer though…

There’s the “build triangles, not squares” saying. For example, your data center core1 router will always use campus core 1 to get to distribution layer 1 or 3. If you have an additional link from data center core 1 to campus core 2 then it can use both campus core 1 + 2 and load balance traffic. The same thing applies for data center core 2 to campus core 1.

Rene