This question already has an answer here:

We have a number of custom computer systems that need to be networked and temporarily installed around a football stadium - each computer has it's own network switch. These computers all need to be networked to a central computer. Up to this point, we've been daisy chaining the switches so as not to exceed cable length limits and putting the server in the middle of the chain with 5 computers/switches going off on one chain, and 5 going off in another chain and everything has worked great. I checked network utilization on the server when looking at the network traffic from one computer, the utilization was about 0.13% of the gigabit connection, and all of the switches at each computer located throughout the stadium are gig switches.

We're running into some situations where we need to increase the number of computers/switches and possibly move the server to the end of the chain, meaning the server could be at the end a chain of 20 switches. Home-runs are not an option due to exceeding gig network cable lengths (300ft) and fiber would be much too costly.

So, I know that it's not recommended to daisy chain network switches, but I haven't read anywhere hard and fast that says you can't do it. Further, there is no other traffic on this network other then those computers which send small amounts of data over the network to the server.

Besides not being recommended for a standard office network (which this is not), will we run into any major issues? When daisy chaining multiple switches, is it just a matter of excessive traffic on the uplinks closest to the server, or are there other switch routing/timing/processor issues that we would run into?

Thanks! Mike

marked as duplicate by Greg Askew, womble Sep 24 '15 at 20:30

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    I mean if you look at it from a different prospective ...the Internet as a whole is just a series of switching and other networking equipment thousands of miles apart, so I don't see your use case being an issue. – Nathan C Sep 24 '15 at 17:42
  • 1
    Bring back memories of the great days of coax ethernet you do. – ErikE Sep 24 '15 at 18:54
  • @womble - stacking switch and daisy chaining is a different thing... – ETL Sep 25 '15 at 0:37
  • 2
    @ETL: The question title is poor; the question itself and the answers cover this question entirely. – womble Sep 25 '15 at 1:28

There are no hard limit on daisy-chaining switches. I had a layer 2 network once where a PC at one end of the network, reaching a server at the other end could easily go via about a dozen switches. But there is a practical limit depending on hardware and your network needs.

How many can you daisy chain depends on what's happening on your network and the quality of your switches. A "gigabit switch" doesn't mean a thing really. How much packets can that switch process? How much bandwidth can the switch forward?

Also, what's the network traffic? Are all PCs only sending/receiving traffic with the servers or is there PC to PC traffic?

Assuming the traffic is only to the server, with what you posted, I wouldn't be afraid, but I would make sure to use good quality switches.

One thing to keep in mind is what I personally call the "inverted funnel". If you have PCs mostly sending traffic to a specific point, you can, by daisy chaining arrive to the situation where you have something like this:

PC ---|
PC ---|
PC --- switch1 ---- switch2 --- switch2 --- switch3 --- SERVER
PC ---|               |            |
PC ---|               |            |
          PC ---------|     PC ----|
          PC ---------|     PC ----|
          PC ---------|     PC ----|
          PC ---------|     PC ----|

So in the example above, if every PC is downloading 10M from the server, how much traffic is going through switch3? 13 x 10M = 130M. So if all the links above were 100M links, then you would choke. The above is what I call a "funnel design".

The inverted funnel design would require that the bandwidth between switch1 and switch2 be enough to carry the expected load from all the nodes connected to switch1. Then the link to switch3 from switch2 would have to be enough to carry the load of switch2 and switch1, etc. So the link between the switches would have to be greater than the link from the nodes to switch. Example: 24x100M ports switch has 2 x 1G connection to next switch. That being obviously based on expected bandwidth usage, not the port speed.

If you have gigabit ports but all nodes are using only a few Kbps, then it may take a bit to saturate - bandwidth-wise.

You have to do similar math on packet quantity.

  • 2
    There isn't a limit to connecting them, but you can run into issues with spanning tree. – Zoredache Sep 24 '15 at 18:09
  • Aside from bandwidth bottlenecks, with enough switches the end-to-end latency will increase, so at some point there can be a practical limit that will vary based on the traffic one is trying to send and other aspects of the topology. – Todd Wilcox Sep 24 '15 at 18:58
  • @Zoredache - good point, however from the post, I feel he does not have spanning tree, I feel he does not have managed switch but I could be wrong... – ETL Sep 24 '15 at 20:19
  • Well that is the tricky part, I have seen networks using switches that had spanning tree running that never got configured properly, because they basically had lower end switches smart/managed switches that they treated like dumb switches. In situation like described, I would not want to assume that there was no spanning tree, or that it was disabled. – Zoredache Sep 24 '15 at 20:38
  • So what is spanning tree? – Mike Sep 24 '15 at 22:53

There isn't really any limits about connecting switches, but you should be aware that there is limits of the spanning tree protocol is limited to 7 hops.

Twenty switches between two systems seems unusually large, you probably should consider breaking things up into VLANs at that point. You can do this using the layer 3 features of a switch even.



Option #1: As long as you are using switches (especially on such a low-load network), it should just work. Hubs would cause trouble, but that is not your case.

Option #2: If you run into any weirdness (the longer the chain, the higher the number of devices that could lose/drop/destroy your L2 frames), consider combining the solutions - make extended star topology - daisy chain switches up to some level around one switch and connect that by fiber (media converters are not that expensive). This way you need just a few fibers and still retain reasonable chaining.

Option #3 inspired by Zoredache: get L3 switches and just route (L3 switch) everything. IP is designed to deal with even higher numbers of hops. Although this may not be an option if you are using broadcasts, multicasts, or some exotics.

  • Yeah, that's a possibility. We do have media converters and could branch out from different locations. It would just mean running the fiber in addition to the cat5e. If we can pull it off with daisy-chaining without any ill effects, then I don't mind do that. I know it's frowned upon, but we're moving xyz position data about 10 times a second, so this is a very small amount of data relative to the bandwidth capability of the switches – Mike Sep 24 '15 at 22:57
  • @msoultan Actually, I'm not frowning. I think you'll do fine with what you have. But as it's rather uncommon setup, so your mileage may vary. If you run into any weirdness, adding fiber or two may help a great way (reducing number of hops from 20 to 3 or 4 should help a lot). – Fox Sep 24 '15 at 23:53
  • I think Option 2 would be the best long term solution for OP. Use fibre to link "local" nodes around the physical venue back to the central node where the server is located. Season with VLAN's and LACP trunks to taste. – fukawi2 Sep 25 '15 at 2:08

Short of what was already mentioned by @Zoredache and @ETL; the only other thing I would consider when daisy-chaining network switches is the consideration of how large you want to extend a single broadcast domain within your network.

Barring of course other constructs like VLAN's and trunks, of course.

Note For the record, I upvoted both @Zoredache and @ETL's answers since they would be more important considerations. This was more of an addendum.

  • 1
    I see where you're going, but the volume of broadcast traffic is a function of the number of hosts in a single broadcast domain, not the number of switches in a single broadcast domain. – joeqwerty Sep 24 '15 at 20:02
  • I'd like to think of it as potential hosts within a single broadcast domain. But true, by themselves, a large series of daisy-chained switches will NOT affect the volume of broadcast traffic. – Get-HomeByFiveOClock Sep 24 '15 at 21:58
  • Right, I knew what you were going for but wanted to add a bit of clarification. A +1 answer for pointing it out. – joeqwerty Sep 24 '15 at 23:08

I doubt you would see any timing, processor or routing issues. Those are usually router issues and wouldn't be caused by excessive switches.

You could go with some repeaters (extenders) http://www.dummies.com/how-to/content/network-basics-repeaters.html and those would give you the distance.

Your main concern will be with how many TOTAL computers are on the same broadcast domain. That is when you will start to notice connection issues.

  • 1
    In this case, it's 12 computers, 12 switches. So really it comes down to a latency issue. I'm going to give it a try with a bunch of switches and see if we run into really long delays. If it's tolerable, then I'll probably roll with it. One big problem with this setup is that if you lose one part of the chain, it kills everything after it, and that could be problematic - other solutions above such as the star topology could help that.... – Mike Sep 25 '15 at 2:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.