What is an Enterprise Campus?

In its simplest form, an campus is just a group of one or more buildings within the same geographical location, were people come together, to communicate and work together.

A Campus Enterprise Network is focused on user access and being able to access internal and external resources. Essentially to get them online and working as soon as possible. They may have BYOD, IOT, Corporate devices etc which may or may not be within our control.

In a campus user mobility is often guaranteed depending on the geographical scope of that location. For example if is a big campus environment such as a College, you may be working in the science building during the day on floor 3, and then later studying at the library in a separate building on the first floor. This geographical challenge should not impact a users experience of using the campus network. They should be able to seamlessly roam around these buildings and have good wireless and wired network access.

Physical Considerations

Unlike a datacentre which is typically a single building which has consistent, single floor with consistent racks and neat cabling, cable trays, power resiliency and very nice neat cabling which is typically also labelled. Its very consistent and easy to manage.

An enterprise typically does not have this luxury. For example, I have worked at MSPs where we have had customers with network racks that have been poorly maintained, cables everywhere, no labels, just a poor design as more and more users come onto the network.

This may be due to physical constraints such as:

1. Lack of cable trays
2. No racks available or compact switches which have to be mounted to a wall. This I have seen is common with enterprises using Meraki for branch sites.
3. Unable to lay cabling in the wall and patch them into the patch panels on the racks.

We must also take into consideration the floor plan on the building. A user will not be sitting next to a noisy switch. Typically we will have to route cables either up a wall or find some way to get them onto the floor where the users are. This has a major impact on the design.

Logical Network Considerations

3 Tier Hierarchy

In traditional campus network designs we typically will see a network which consists of the below 3 Layers:

Access Layer

The Access Layer comprises of typically Layer 2 switches which end user devices connect into. For example, IP Phones, PC's, Laptops, IOT devices etc will plug into a switch. Typically cables will be routed to a floor where the user can plug an ethernet cable into their device and they will be patched into an Access Layer switch. At this Layer you can expect to run some of the below most common features and protocols on switches:

Phase 1 — Foundation (Switch related)

1. Switch Stacking
2. VLAN Segmentation & VACLs
3. Trunk links (native VLAN)
4. EtherChannel / LACP
5. UDLD
6. Spanning Tree (Root Guard, Loop Guard, PortFast, BPDU Guard)
7. Errdisable Recovery

Phase 2 — Device plugs in (User related)

8. PoE / PoE+
9. LLDP / CDP
10. Voice VLAN
11. 802.1X & MAB
12. Port Security

Phase 3 — Traffic flows (Switch Related)

13. DHCP Snooping
14. Dynamic ARP Inspection (DAI)
15. IP Source Guard
16. IPv6 First-Hop Security (RA Guard - IPv6 coming in the future)
17. Storm Control
18. Protected Ports (PVLAN Edge)
19. QoS Trust Boundary

We will be covering them all in depth in regards to technical aspects in future blog posts. However, In this series I will go over all of them briefly so that you understand why we use these protocols at these layers and what problems they solve and at the end see all the components that make up a typical access layer at the switch level.

Phase 1 - Foundation

Switch Stacking

What is switch Stacking?

Switch stacking is a process of taking a two or more physical switches and bundling them into a single logical switch.

The problem without Switch Stacking

The main purpose of switch stacking is to increase the capacity and management of a network.

The main issue without switch stacking is if you had 100 brand new (or existing) switches, the Network Administrator has to manage each switch individually. Each switch would need their own SSH configuration, VLAN configuration, Trunk configuration and more. This takes up a lot of time - You can automate this, but even with automation you would need basic IP connectivity and SSH connectivity to each switch in terms of configuration. This is not to mention that troubleshooting would be a nightmare.

The reason why each switch needs their own VLAN config/trunk config etc is because out of the box each switch is in its own broadcast domain. They are all in VLAN1. By default they'd be able to talk to each other if plugged in. But there would be no segmentation. But manually configuring or even automating as mentioned can be a pain.

What Switch Stacking solves?

Switch stacking as mentioned allows for bundling switches into one stack which allows for ease of management. Lets say we for example that we can bundle 10 switches into a single stack, if we had 100 switches we would only have to manage around 10 switch stacks vs 100 switches. With switch stacking we only manage the master switch in that stack.

This helps a lot in ease of management. There are many protocols used for switch stacking ranging from, Stack wise to Virtual Switch Stacking which govern how many switches can be in a single stack and all the rules for that protocol.

Switch Stacking In Practice

You will see switch stacking a lot in enterprise networks. Certain Cisco Catalyst Switches support this while you can also use this with some Meraki models and manage the stacking configuration on the Meraki dashboard.

In terms of monitoring we typically monitor the Stack Master.

In terms of upgrading its typically a case of TFTP the software to the stack master and during the upgrade process depending on the model of the switch you will either have to manually copy the software to all other switches in the stack, or in 9300s it will distribute it from the master during the upgrade.