Hamzah, can you post them here?
Hamzah, can you post them here?
On redundant links one way to have some protection while keeping costs down would be to link the top and bottom switch in a cabinet back to the core by separate pairs within a single run so that if either switch failed the rest of the switches in the cabinet could still communicate with the core. You are still at risk of a fibre cut taking out the cab, but usually if that happens they find some way to cut both fibre runs anyway.
I hope this helps as it is a resource which i will be referring to.
Best case is to run a multi core to each cabinet and run each switch directly to the main Core or distribution layer. then link them together with copper or fiber as a redundant link, you may also want to run a link from each cabinet to another i would use fiber this helps if your entire multi core goes down. but this is far more expensive, and more complicated but allows a lot more stability.
If you don't have stacking switches or chassis based switches, then switch->switch ->switch->switch is a legitimate arrangement. If you are concerned about bandwidth, you can use 2/4 port LACP trunks between them. With the switches at either end of the chain connected by fibre back up to the core, spanning tree will keep one of the middle switch->switch links down, and you get load balancing across your uplinks.
If your comms rooms are sufficiently small then of course you could have an uplink per switch. However two switches with separate single 1GB/s links back to the core will not perform as well as two daisy-chained switches with a single 2 port LACP trunk.
how do you prevent switching loops? STP cuts off the redundant links so no load balancing can be being done and without STP you make your self a loop?
and you cant say 100% that STP will cut the middle link.
I understand the idea but from a redundancy, bandwidth point of view and even a hop's point of view a switch to Many other switches always trumps daisy chaining them. and yes LACP trunks help a lot in any configuration but the data through is always higher if the star is used rather than a buss, your not having as high a contention ratio on each of your switches, E.g 1-48 or 2-48 instead of 2-86 2-144 or even 2-192 and at far fewer hops your reducing the processing time taken to transfer the data packets through each switch as each will want to process the data its self before forwarding.
Networking is difficult an no one can realy say they have the best design it depends on requirement situation and cost ultimately.
Assuming you've got your root bridge configured sensibly, out at the edges spanning tree chooses to block one of the inter-switch ports in the chain, because the best path back to the root bridge is shortest from the two end switches, it leaves in effect two smaller chains attached back to the core.
That said, every reasonably sized network I have seen (apart from my current one) employs in effect a matrix of connections between the cabinets with a little daisy-chain for the edge-most switches. In these networks MSTP or EAPS was used to achieve the best throughput and resiliency.
But I agree there is no correct answer, we're just thowing about ideas, what we'd do and what we do do. My current 1Gb/s lan (predominantly a star with quite a bit of daisy-chaining at the edges) cost an order of magnitude less than the BSF one I last looked after. It is simpler, and less resilient, yet operationally I cannot tell the difference, other than I don't need to pay for a CCIE when we want to add a switch.
Finally for a different perspective to us lot concerned with small numbers of users.... In some cases it is not always faster for each switch to have it's own single link back to the core: Per Second Measurements Don’t Cut It - Server Fault Blog
Don't confuse Stacking Switches with Daisy Chaining of switches.
A True Stack uses a stack interconnect that offers management of the entire stack and should offer backplane speeds across the entire stack. Daisy chaining require individual management and only port speed between switches.
I discovered that our supplier had put 8 layer deep daisy chaining with no redundancy on our sister site ( that was within 3 hrs of finally getting the password out of them ) they argued it was acceptable until I sent them a diagram out of Cisco Network assistant highlighting the bottlenecks and multiple points of failure.
We run (in reducing quantity),
Core -> Distro -> Edge -> User
Core - > Edge -> User
Core -> user
There are some good ideas and thoughts being thrown about here. :)
Core - > Edge -> User << that was the way I had this planned in my mind, it depends how big the building is going to be I suppose, where they decide to locate the rooms etc etc
So do stacked switches use the interconnect to communicate between each other? at what speed does that operate at?
I found this video quite interesting. https://www.youtube.com/watch?v=o56VKAwPHFQ
the speed is dependant on the brand/model but often is at the full backplane speed of the individual switches so much much higher than 1Gb ports. Good ones you can link the top of the stack to the bottom so that any failure in a member or a cable will not take out more of the stack.
Last set I had was 6 years ago though
I'm not confusing stacking with daisy-chaining. Because I've never really been a networking guy, and having looked after procurve, cisco, 3com and extreme as well as having to translate for SLT and governors my language is often confused.
7 Deep daisy chain? Owch. I wouldn't want to be the project manager on the receiving end of explanation as to why that was a bad idea.
My problem with having a big stack of switches is that in my experience they can be a single point of failure... I have on several occasions had a switch in a stack go bad and take out the connectivity for the whole stack.
There are, broadly speaking two types of stacking. The Good type that generally uses dedicated modules and cabling running at 10-40Gbs, in which the switches behave as one, allowing you to have, say, an LLDP group with ports across different switches in the stack. The other type is simply a managment convenience to present one management interface for a number of devices, this commonly uses any 1Gbe port to link the devices. With this latter type there isn't much operational or architectural difference between a stack and a daisy-chain, I suspect it just looks better in a network map.
The deepest part of my network is 3 hops with 2Gb/s the whole way to the core. In the event of a failure in that particular cab of either the top or bottom switch RSTP will unblock a port in the middle of the cabinet and the network will become 4 deep. I feel I ought to point out (again) that this network was an order of magnitude cheaper than the MSTP based 10GbE with daual 8800 Procurve Core monster that had a 'better' design. Would I prefer to have A5500 stacks at the edge? Yes, but the current design (and the monitoring of performance) shows that I really don't need them.
A final point from me: I would strongly recommend though that you engage with a specialist network company for the design and implementation for layer 1,2 and 3. Make sure they are engaged in the process before architects put pen to paper.
After getting the password, I got onto the CLI, nothing much seemed to make much logical sense as I worked my way hopping from switch to switch.
So I fired up Cisco Network Assistant ( I hardly ever use it ) and mapped out the horror!
There is some redundancy, but it's not consistent and in some areas not redundant at all.
So is stacking switches (a true stack) akin to RAID then? RAID 5 for example, the stack can suffer 1 loss and still communicate. In the attached image (ph34r my paint skills) is the dashed line (cable) needed for redunancy? for example if switch 2 fails then switch 1 wont be able to communicate with any of the other switches but switches 3-6 will still be able to communicate with each other.
Found this which explains it nicely.
It depends on the technology on the switches. That schematic might represent a true stack, or a daisy-chain with STP hopefully keeping one of the ports blocked.