Hi all. I remember back in the older days where when you daisy chained hubs together, you used to loose like 50% of the bandwidth capability every time you daisy chained another hub at the end. Do you guys know if thats the case now with switches or not?
it shouldn't be for all cases.
For example C3750 have specific connections Stackwise that run at 32Gbps allowing to interconnect their backplanes in a efficient way.
The problem can be on the uplinks.
up to 9 C3750 can be put on a single stack
See the following link:
Hope to help
Yes, because you are always ultimately dividing the uplink bandwidth of the first switch.
When you cascade a second switch, you ahve all teh potential traffic of the second switch squeezed through the one port of the first switch.
If you cascade yet another switch to the second switch, then you are squeezing all of the potential traffic from teh third switch into a single port of the second switch, adding the second switch's traffic, then squeezing it even more to get it into the single port of the first switch.
This is a really bad, stupid, idea for a production network. It's a chain of single-points-of-failure, and swamps the upstream switches in time of congestion.
Yes, I agree. Certainly not something I would do, but I have a customer asking me this and I cant recall what the answer is. Just thought some of you could answer the question.
Using a daisy chain topology with switches, instead of a star topology, might also increase latency because of the possible additional number of hops.
Explain to the customer why it's bad, and that you do not want any part of connecting or supporting that configuration.
It will end up being a gut-wrenching nightmare of support. If you touch it, you'll own it; it'll suck mightily and you'll suffer horribly.
Seriously, it's a Very Bad Thing and it *will* bite them big-time in the end. They'll tell you that it's not important, it's temporary, it's not a primary network ... or any of a thousand excuses to get you to do it ... but if you touch it, you'll own it, and *THEN* it'll be the most critical network in that hemisphere of the world ... and if YOU don't fix it (always for free or cheap, "since you're the one that messed it up")... evil will befall you (lawyers-a-plenty, Vito with a lead pipe, whatever).
No kidding, run like hell if they make any noise regarding the continuation of this kind of config.
5 points for this fantastic explaination.
It's such a good description that I can see such things happening in from of my eyes :)
the chain of single points of failure is indeed true.
if a switch in the middle of the chain is powered off the single stack becomes partioned with two new stacks claiming to be the same thing with the same management ip address.
You can provision an uplink on the first switch and one on the last one, but actually if something happens to one of the switch in the middle it will be panic.
By the way, we have only two stacks in a single site and we opened a TAC case because one of the two stacks is not able to be accessed via telnet or to setup any TCP connections client/server side. If you reload it for an hour you can telnet to it later nothing and it is related to the stack
I hadn't understood the sense of BW halfed in cascading on the first post.
thanks for sharing your thoughts about this.
Cascading by stacking and cascading by Daisy-Chain are not the same thing.
Switches with "stacking ports" generally have higher bandwidth channels to connect the stack. "Stacked" switches usually operate as a single device, like blades in a chassis. In many cases, the stacking channel has redundant connections or a circular hookup, such that if any link is broken, there is still a path.
Using the host ports and stringing them from switch-to-switch-to-switch ("daisy-chained") has many drawbacks (as mentioned above), and is operating well out of design specs.
The bottom line: "Stacked" is OK (by a stacking port, designed into the device), Daisy-chained = Very Bad Thing" (switch-to-switch by host port).
Just to play devil's advocate and stir the pot a bit... ;)
There are sometimes uses for a daisy-chain configuration...this is essentially the simplest part of a ring, which in many cases is a valid configuration. If your customer is looking to implement a service provider ring or something similar, a traditional 3-layer campus network (core/distribution/access) topology may not be as reasonable as a ring.
Of course, as the above posters so vehemently stated, I'd never advocate a chain with a SPOF...if you are doing this you'll want to set it up in a ring, and if you're smart about it I think you'd do it in several discrete rings with routed interconnects, so as to further minimize damage.
If you are looking at configuring something akin to a service provider ring, take a look at resilient ethernet protocol - REP for short. :)
"Seriously, it's a Very Bad Thing and it *will* bite them big-time in the end. They'll tell you that it's not important, it's temporary, it's not a primary network ... or any of a thousand excuses to get you to do it ... but if you touch it, you'll own it, and *THEN* it'll be the most critical network in that hemisphere of the world ... and if YOU don't fix it (always for free or cheap, "since you're the one that messed it up")... evil will befall you (lawyers-a-plenty, Vito with a lead pipe, whatever)."
That was freakin hilarious, man! LOLOLOL
I'm givin' ya 5 points just for making me laugh my a-- off. LOL
We need a bit more of this sort of stuff on this thing...
Moreover, you're right!