Is it ever okay to daisy chain switches? No?

[brettp]

What do you seasoned network engineers do? I know, I know. Never daisy chain. Only stack. I need two new switches for a new department they're creating at my work (well, they're combining two existing departments and sticking them in a new location.) I was thinking of simply getting two 48 port gig switches (without FlexStack module.) One department only has gig throughput at the moment, the other has two. Why couldn't I just aggregate 4 gig interfaces between the switches and then aggregate another 4 gig interfaces to the core. That's 4 gig throughput from both switches (or two if you want to take 50% because of the other switch -- but that's not a problem in this case) ... that's even more than they have now without issue. I could even do 2 (or 4) from each switch to the core for added redundancy if I wanted. So you see... there's no real bottleneck in terms of throughput. So is daisy chaining two switches in this case still a bad idea? Stacking would give 40 or so gig throughput between switches, but that's overkill -- especially considering there would be only 4 gig to the core and these are client computers -- they're not talking to each other. What would you do? Thanks!

[Reza Sharifi]

What you are trying to do will work fine for small environment, as long as you don't create a loop on the network, however If daisy chaining is creating a loop, make sure STP is deployed, tested  and works as expected.

HTH  

[johnlloyd_13]

hi,

if it's just a small branch office 2x 48 gig stacked switch (with redundant PS) is fine as compared to daisy chaining the switch.

since the 2 departments aren't talking, creating a VLAN for each department will do the trick.

you should consider in your design the number of current users and a room for future expansion.

[Karsten Iwen]

I would address this "problem" from a different direction:

What are the benefits and drawbacks? Daisy-chaining will provide a single point of failure and if the first switch in the row fails, also the second switch is cut off the network.

If you connect both switches to the core you have better redundancy. For even higher redundancy you could connect both switches together if the uplink from one switch fails completely.

Stacking will give you an additional benefit of a less complex switch-management but also combines both switches to a new failure-domain.

So, why would you want to daisy chain them as you are not forced to (as with two locations that are only connected to each other and there is no cabling from one location to the core)?

[Leo Laohoo]

Over a hundred sites and none of them are daisy-chained (we call this "lollipop"). All access switches go to the site distro.
When one of the cabinets go down, it will affect only users connected to that cabinet.

[Joseph W. Doherty · Accepted solution]

"Never daisy chain. Only stack." Says who? Plus a stack is often a physical daisy chain.

Don't misunderstand that I'm suggesting daisy chains are better than stacks, but in the real world your equipment might not support stacking and/or the physical cabling plant only allows a daisy chain. Real designs often don't implement what everyone might consider the best but what's good enough given what you have to work with.

"I could even do 2 (or 4) from each switch to the core for added redundancy if I wanted."

Okay, if you can do that why do you need to daisy chain the two switches?

[brettp]

This is actually the type of answer I was looking for "Real designs often don't implement what everyone might consider the best but what's good enough given what you have to work with." I've only been doing this (well, thrown into it) for a year. I just was wondering how seasoned engineers would approach it. If it seems that if you're forced to daisy chain, you're just forced to do it... but ideally, perhaps stacking is the best way. As for your other comment, the additional link would just be for additional redundancy.  Anyhow, this is a project starting from the ground up so I can order new stackable switches.

[Joseph W. Doherty]

Yep, one of the most important real world design factors is budget. ;)