Designing a redundant switching infrastructure

Question

Ultimately I've been tasked with the installation of a serviced office with upwards of 1000 staff, potentially being spread across 50+ VLANs.

The hardware bought was out of my hands, but it's fairly decent high-end switching that should be able to achieve what we require. See below diagram to hopefully aid my description (Layer 3, MLAG etc.)

Essentially we will have two core 24 port switches, which we would like to put into high availability. My idea would be to use MLAG, but I'm looking for guidance in that regard. These each have 4 port add-in for 10GB fibre.

We will have 3 stacks, A, B and C. C being in a remote office. Each stack will be connected to the core via the 10GBe fibre ports. The top and bottom switch in each stack, connected to CORE01 and CORE02 respectfully.

(Green cables are stacking cables, blue and orange uplinks to CORE1 and CORE2 respectfully).

I'm really looking for some guidance on the best way to configure these for redundancy.

MLAG between the two core switches? (these cannot be stacked, no stacking ports) for redundancy, the 3 stacks as below, with two uplinks split across each core? These would both be trunk links carrying all VLANs as tagged VLANs?

Or simply just redundant links and enable STP? Or something completely different?

Do we connect the two CORE switches via Fibre (meaning we can only use one fibre connection from stack C to the core) or just use 1GBe Ethernet between them? Really looking for some advice and/or best practices for a large setup like this.

Answer 1

That is a good way to design and you may want to consider adding a third layer to your design.

Your core switches appear to be a core/distribution setup and you really want to separate your core switches so they aren't affected by spanning tree loops, yes they do happen.

You could implement ospf between your cores and the distribution switches which could then be split between buildings, floors, geographically, etc. Your vlans spanning tree roots are then on the distribution switches. You could then test your vPC/MLAG solution without taking out the whole network :-)

Not really sure which vendor solution has been selected but they should have documentation available for design and best practice for high availability/redundancy.

Side note: some designs even take routing to the access switches thus containing spanning tree loops to the access switch stack but I think the expense is best spent on a couple of beefy core switches.

And you can test it all in GNS3 (or similar app) prior to deploying :-)

Answer 2

MLAG or stacking are good solutions since they can utilize the redundant links. Note that both depend on the hardware you're using - they're at least vendor-specific and usually model or series-specific as well. You need to consider a support agreement, covering repair or replacement during the deployment period since changing the model/series is likely to break your redundancy concept.

RSTP or MSTP are hardware-agnostic solutions for redundant links. However, without the stacking rings your setup would be chaining switches which isn't considered a good architecture. With STP you'd connect each Access switch to each core switch and rely on the spanning tree to sort out the redundant links and handle failover.

MSTP with its multiple instances would allow you to arrange your VLANs so that you could utilize both links between Core and Access (each instance forms its own spanning tree).

MLAG between the two core switches? (these cannot be stacked, no stacking ports) for redundancy, the 3 stacks as below, with two uplinks split across each core?

Generally, yes - depending on the exact models and their capabilities.

These would both be trunk links carrying all VLANs as tagged VLANs?

Generally trunk links with those VLANs required.

Do we connect the two CORE switches via Fibre (meaning we can only use one fibre connection from stack C to the core) or just use 1GBe Ethernet between them?

Fiber or twisted pair doesn't matter, just the bandwidth/link speed does. You'd want the faster ports on the heavier utilized links, usually found in the center of the network ("fat tree").