Cisco Campus Network Design Basics

Hi Rene
If we have multiple vlans environment , then what about SVI creation. SVI will be created on each Distribution layer switch or only single distribution layer switch.

Hello Muhammad

The VLANs that are used by each of the distribution and access switches will be created within them. However, the SVI for each VLAN should exist on only one device, typically the distribution layer switch that serves the VLAN. That way there is only a single location where inter VLAN routing takes place. Now if you use a redundant gateway protocol such as HSRP, then you will have two devices (or more) with an SVI interface for routing purposes, but they will share the responsibility using a virtual IP. You can find out more about HSRP at this lesson:

I hope this has been helpful!

Laz

1 Like

Hi Rene,
Could you give an example of commands sequence for calculation of a switch fabric capacity? e.g. Cisco 2960 series. Thanks in advance.

Hello Vadim

There are no commands that you can use to determine the internal capacity of a network device. The best way to find out what you need is to look at the datasheets of the devices in question. Specifically, the 2960 series can be found here:


Based on this document, you can look at two values that will give you information about the fabric speeds:

  1. Forwarding Bandwidth - This is the maximum bandwidth in bits per second that the the switch can forward simultaneously internally
  2. Forwarding rate - this is the maximum number of packets that can be transmitted in packets per second (or millions of pps). This takes into account the processing power needed to switch each individual packet.

I hope this has been helpful

Laz

Hello Rene/Laz
I have some questions and I am going to use the below diagram as the reference.

In this topology, I have three different sites that are geographically located at three different places. As you see in the diagram, every single site has their own internet connection and they are hosting their public facing servers by using their own Public IP addresses. Now the requirement is to have internet redundancy for every single site. For instance, if the internet connection at
SITE -C goes down, it should be able to use SITE -B or SITE -C as the backup path. In this situation, how can I have redundancy for public facing servers among these three sites. Meaning If the internet connection goes down at
SITE -C, still internet traffic should be able to access the public facing websites that are being hosted by SITE -C by using SITE -B or SITE -C internet connection. Please shed some light on it.

Thank you so much in advance.

Best Regards,
Azm

Hello AZM

I order to achieve such redundancy, you will need to use BGP in a dual or multi-homed configuration. Specifically, this means that the IP addresses of your web servers must be advertised via all three ISP connections, with varying attributes to indicate which is the primary, secondary, and so on, route to get to your servers.

Now there are several “administrative” issues involved here. If your public IP addresses are provided by your ISP, and you have different ISPs at each site, you may not be able to route IP addresses of one ISP via another ISP. If the public IP address range is your own, then you can advertise this freely however you like, assuming you are running eBGP between your equipment and each ISP’s equipment. Much of what you can and can’t do in this area has to do with the policies of each ISP, and for this reason, an extensive chat with them describing what you want to do will go a long way in finding the best solution.

In such a situation, controlling outbound traffic is easy. If an ISP fails, you route traffic via the secondary route. You have control over your own equipment to be able to reroute such traffic. The challenging part of incorporating such redundancy that you describe has to do with incoming traffic. Such a situation requires you to attempt to control incoming traffic, that is, the way that each ISP will route traffic that is destined for your servers.

The first rule about controlling inbound traffic is Attributes that you would use to that you do not have ultimate control over how traffic enters your BGP Autonomous System. All of your eBGP peers can override all of your attempts to influence incoming traffic. Having said that, however, there are four ways in which you can attempt to influence incoming traffic to achieve the redundancy you need: Leaking more specific routes, MED, AS-PATH prepending and Community/Local pref agreement.

You can find out more about each of these in Unit 3 of the BGP lessons. Here’s a link to the attributes lesson:


Also, you can find out about the dual and multihoming scenarios at this lesson.

I hope this has been helpful!

Laz

You the man Laz!!!

Azm

1 Like

I was wondering if someone could shoot me some advice on Network design. More Specifically collapsed core/distribution model with Multiple Vlans ( including Voice ). For example for the attached Network diagram, I’m trying to decide best route:

  • Links between the Distro and Access layer should I have them /30 with DHCP running on the Access layer switches for computers connecting to it ( Data VLAN ). With a Voice Vlan SVI and “ip helper-address” to the core for VoIP DHCP.
  • Or have the Core be the main DHCP server for everything and set the Core SVI’s to xxx.xxx.xxx.xx1 and access layer SVI’s to xxx.xxx.xxx.xx2 and “ip helper-address” back to the .1 Core SVI.

New_Design.pdf (80.0 KB)

Hello Aaron.

The following lesson includes network design principles that you can use for such projects:

Having to do with your specific question, it depends on your implementation. For most campus networks, and based on your diagram, I would prefer to have routing occur at the core/distribution layer and have the DHCP servers there as well. DHCP and routing should take place in the access layer ONLY if the network is exceptionally large, offloading some of the L3 implementation from the distribution layer to the access layer. However, since you’re implementing a collapsed core model, this doesn’t seem to be the case here.

What IP addresses you use to address the access layer switches in this case is irrelevant to the design, since access layer switches in this scenario would only provide layer 2 functionality.

I hope this has been helpful!

Laz

Hi All
For my College project I have to design a network for a factory. I have reviewed the lesson on campus design (but my network is similar to jsut having 1 building on the campus). I have to configure the network using packet tracer 6.2.

I have decided that I am going to have at least 5 switches, and use trunking to allow the switches to talk to each other. I would also like to build in redundancy.
I will have 3 standard vlans, vlan 10 for network Management, vlan 1000 for discards, and vlan 999 for trunking.
So ideally, I want all the switches to use the same ports for network management, so was thinking for instances that I would always assign ports fa1 for trunking, and ports fa2 and fa3 for Network management, and I would do this on all swicthes to be consistent.
I do have a vlan plan, but I am struggling with getting some sort of consistency, and am not sure the plan is the best. Apart from the 3 basic vlans, (trunking, discarding, and network management), would you then limit the vlans on the switches? Currently I seem to have a lot of vlans on different switches which seems to be a mess.
I am using the C3560 switch as it has 24 ports.
When you build the network do you start by making sure the switches can talk to each other , or do you configure each switch with its vlan first?

Hello Keith

Let me start from the end of your post. Where do you start? Start by drawing out your design on a piece of paper. It often helps me to see the boxes and connect them physically with lines so I can see the network taking shape. Now I don’t know how much detail you are given about the factory in order to decided how many switches you’ll need, but I’ll include more detail than you’ve given, just for completeness. Ask yourself the following questions:

  1. How many users are in the factory? How are they distributed? Will five switches of 24 ports each suffice for all the users and their distribution throughout the building? Remember that users cannot be more than 100 meters (cable distance) from each switch.
  2. Switches should be connected to each other via trunks that carry (initially) all VLANs in your topology. I say initially because in the future you might find that some VLANs are limited to a certain area of the network, and you can remove them from some trunk links to avoid unnecessary broadcasts reaching parts of the network that will never use them.
  3. The physical connections can be made in one of two ways. Either you connect all five switches in a ring topology, and have one of the switches connect to the Internet, thus providing redundancy if one link breaks, or you can have a single switch as the central one, and make two physical connections between that central switch and each of the other four switches, providing redundancy this way. This is somewhat more resilient, but costs more in links and port usage than the first option.
  4. Next, you can choose how many VLANs you will use. Will you separate the network into VLANs based on location or on department? You can make an administration VLAN, a marketing VLAN, a manufacturing department VLAN, a Voice VLAN etc. But you should have a management VLAN and a native VLAN. You can configure these VLANs in all switches, and allow all VLANs across the trunks so you can add them to any port you like.

A note about the management VLAN. Why do you need physical ports for the management VLAN? You can just create an SVI port on each switch within the management VLAN and allow access to each switch via IP addresses assigned to those ports.

Also, what do you mean by VLANs for “discards” and “trunking”? I assume you mean the native VLAN for discards, meaning frames without tags. A trunk on the other hand is configured to carry multiple VLAN, so a specific VLAN is not necessary to specify for use with a trunk.

I hope this gives you a good starting point. As you begin your design, if you have any more questions, please feel free to ask!

I hope this has been helpful!

Laz

Hi Laz
thanks. Thats very useful. The factory is 100m by 60 m over two floors. (But the upper floor has only 100m x 10 m of floor area.

For the switch topology I have followed the example in the Campus Network Design basics. I have 1 switch block with one core switch, two distribution switches and 4 switches for access.
These are all connected via trunking. So I am happy with this aspect, as I have built in redundancy. I have configured all these switches (But I only need to configure 5 ).
I would consider adding a second core switch (But this may be overkill). I might add this in at the end (time permitting). Of course , this being a virtual exercise, cost is not an issue.
I have configured the network manager vlan 10 wjich is assigend 2 ports fa1 and fa2 on each switch.
We do not actually know the number of users in the factory, but we do know that there is about
10 offices , a showroom, and a testlab, plus the factory floor. We do not have to configure ip phones fortunately.
Our lecturer always used physical ports for the management lan, so this is why I am using a port for this.
Again my notes always use vlan 999 for trunking and vlan 1000 from discard. As I understand it, these do not need to be related to physical ports.
I will definitely have a manufacturing vlan, and an office vlan. My instinct tells me its best to separate out the office vlan by floor, and configure the ground floor and first floor vlans to talk to each other, I think I need a vlan for the warehouse, one for the showroom, and one for the testlab. I will also need to set up a wireless printer on each floor, and a wireless router for office staff, which should connect to the network. I also need to set up a guest wireless router which should have no access to any office equipment. Of course I also have to set up passwords on switches, ntp, syslog, dns, etc.

(As you can see , this is quite a comprehensive exercise for 1 module in a part-time course).
Thanks for the help and advise. I think I am on track at the moment.

Hello Keith

The whole project does indeed appear to be very comprehensive. It’s great that you’re tackling it so well and integrating everything that you’ve learned. I wish you success, and let us know how it turns out!

Laz

I’d like to run L3 switching between my core and access layer switches, but am missing something… Attached is a first draft of a diagram. I understand having one Vlan per switch and it stays there, and that’s what I plan to do, but what if I have a Vlan 40 that is my servers and printers vlan and I need vlan 40 ports on each of the switches shown?

Or would it be best to config the Port channels at a L2 and trunk them, and forget this idea? I will not be doing a lot of interoffice communication. Most of my traffic is internal endpoint to cloud…

L3_Switching.pdf (135.7 KB)

Hello Aaron

The answer is: “it depends”. The idea of keeping a VLAN confined to one switch is not an unbreakable rule. It is a general guideline that is good to follow to avoid needless transmission of broadcast traffic to areas of the network that wouldn’t use it. If you can achieve it, it’s great. If the needs of your network require it, then use it, but to a minimum as much as possible.

Having said that, if you have VLAN 40 as you say, and you have several servers on that VLAN, it would’t be a good idea to connect those servers to various ports on the access switches. If this was done, then your links between the core and access switches would be weighed down with additional traffic. Even a device on the same access switch as the server would have to connect via the core, which means communication needlessly going up the link and coming back down the same link, wasting bandwidth. Servers should be consolidated onto a single (or more for redundancy) switch within the datacenter, which alleviates any problems of VLANs spanning multiple access switches.

As for printers, some administrators keep them in the same subnet as the users while others separate them into different VLANs. If you keep them on the same VLAN as the users, it’s easy to confine the VLAN to a particular access switch. If you want to put them in their own VLAN, it helps in the organization and administration of the network but it doesn’t provide any more benefits than that. Even so, if you choose to do so, in most cases, printing over the network doesn’t impact the network very much (except if you have high volume printing due to the nature of your business) so spanning VLANs for printers is not a big issue.

I am all for routing between the core and access layer. It gives you more flexibility and options for security (access lists can be applied at the location where the routing takes place for example). However, I would still make the aggregated links into trunks to allow for the management VLAN to pass. This allows all network devices to have an IP address in a single subnet just for the purposes of management (CLI access via Telnet or SSH).

I hope this has been helpful!

Laz

1 Like

Thank you… Much appreciated…again…;).

1 Like


According to this image, Can someone shed light on this phrase " Also each VLAN can use both uplinks which allow load balancing. "

Thanks in Advance,
Sajith

Hello Sajith

In the previous topology to this one shown in the lesson, VLAN 10 existed on both access switches, and the distribution switches between them had an L2 link. This means that there was a loop on VLAN 10 between Access switch 1, Distribution Switch 1, Distribution Switch 2 and back to Access switch 1. The same was true of VLAN 10 on Access switch 2.

In comparison to the previous topology, this topology has an L3 link between the two distribution switches. This means that there is no longer an L2 loop between the switches mentioned. This means that both uplinks from the VLAN 10 access switch can be used simultaneously without causing a loop.

Now in order to load balance between these, we require that some devices use an SVI on Distribution switch 1 as their gateway and some use an SVI on Distribution switch 2 as the gateway. This way, traffic can be separated between the two links.

From the moment that an L3 link between the distribution switches exists, we can’t use technologies such as link aggregation or HSRP, and since the access switches are L2, routing cannot be used to load balance. The fact remains though that both links can be used simultaneously.

I hope this has been helpful!

Laz

1 Like

How would the 2 tables look for Access switches and those of Distribution/Core switches look if you were to take into consideration the Nexus series of Cisco switches?

Hello Don

Nexus switches are specifically designed for use in the core of the network as well as for datacenter implementations. All Nexus switches would definitely go in the distribution and/or core layer table. They have features that are specifically geared towards streamlining of network core maintenance, harmonizing configurations across multiple platforms, providing redundancy and resilience to the network, as well as delivering high performance hardware such as CPUs and memory, for demanding operations including QoS, a multitude of access lists, and load balancing to name just a very few.

I hope this has been helpful!

Laz

1 Like