Cascading Switches. Will it affect performance?

Question

I am really new to large scale networking and all I know is the basics. I will be doing a network for a huge workspace consisting of multiple offices. There will be a total of 308 Clients, with at least 12 clients per office.

I am following this diagram:

I will be using CISCO SG500-28 Managed Switch as my main switch, where another switch CISCO SG250-18 Managed Switch will tap in.

For ease of installation, I plan to use CISCO SG250-18 Managed Switch for every part or a sector, then Desktop Switches will connect to this.

My question:

1. Is this okay?
2. Does a cascade of switches affect overall performance?
3. Can the last node obtain gigabit file transfer speeds from the other nodes?
4. Can the Main Switch handle every client?

Answer 1

Is this okay?

Hardly ideal. I assume since you are using cheap, obsolete switches, that you're on a very limited budget. You'll have to weigh the factors below.

Does a cascade of switches affect overall performance?

The problem with cascading switches is that you are concentrating traffic on the links to upstream switches. For example, the last switch has 26 x 1G ports. So if more than 10 PCs try to download something at the same time, you've maxed out your capacity on that switch. All the upstream switches will also be maxed out before you even consider the PCs attached to them.

Can the last node obtain gigabit file transfer speeds from the other nodes?

Yes, but only if everyone else is not sending any traffic. Otherwise, no.

Can the Main Switch handle every client?

The main switch has the same problem: your servers are plugged into 1G ports. So that limits how much data they can send/receive. Everyone is competing for a piece of that 1G bandwidth.

Now, all this may be OK if all you're doing is reading and editing Word documents. But if you're doing some sort of transactional processing (payments, reservations, etc.) for a business, this network design may not be sufficient. We can't answer that question for you, and even if we could, it would just be our (my) opinion, which is off-topic here.

Answer 2

There are several reasons for not chaining switches, all of which relate to performance with the parameters effective throughput, resilience, latency.

As Ron has aptly pointed out, more aggregation means more bandwidth competition - all users behind a core switch port compete for the bandwidth of that single port. In another perspective, the longer a potential path in your network is and the more ports are involved, the more total bandwidth is bound by a flow along that path. To keep paths short, a tree is a better approach than a chain.

Some might argue that latency increases when more L2 hops are necessary - while this is true it only becomes noticeable with longer chains. A gigabit switch has a forwarding delay of at most 10 µs (usually much less), so for a chain of 2 or 3 switches it doesn't matter too much unless you're running very latency-sensitive applications.

Additionally, chaining switches introduces more single points of failure and increases their impact - if reliability is a concern. When a middle switch or its link fails, all switches and users behind it are separated from the network.

Most often, there's not only a single deployed cable from the core cabinet to the next. So, use those to create direct links to the core from more remote cabinets. Instead of chaining the switches, try to cross-patch a remote switch, so that it can connect directly to the core.

Answer 3

Additional comments:

Remember to allow for growth too - no new switch should be installed fully populated. There should always be some spare ports. I've seen recommendations from 50% full to at least 20% empty ports. That includes your core switch stack.

Stack? Yes if your budget stretches that far, the core switch should be a stack of two switches and every server has a redundant channel bond. And each link out to distribution switches should be a pair as well. Of course this adds to the capital costs significantly.

Also remember to look ahead - talk to management and see if there are any plans for more space, or additional offices/desks or cameras, phones that need POE, the future uses of wireless, guest wireless, additional Access points, and so on. All this should be factored into a long-term plan.

UPS - your servers and core switches should be UPSed - and monitored so everything shuts down cleanly.

Training - you and others may need additional training for this new switching. Don't hesitate to include that as a cost.

Depending on your environment, and the "cost" of an outage should indicate whether you beef up the redundancy or cheap it, being aware of the risks.

Answer 4

This design is ok only if you are willing to accept a single point of failure for all office switches, web farm, sql, file-server and internet.

This design is ok only if you are willing to accept periodic spanning-tree hits every time links flap. By the way, the Cisco SG series doesn't support rapid-pvst, so you have to live with one spanning-tree for all vlans (I'm assuming you're using vlans, no?).

Honestly it's going to get worse if you add redundancy to this 100% switched network because then you have more spanning-tree to deal with. But I'm guessing nobody hired you to be a network engineer... you seem to be a coder who is likely moonlighting as a network guy. Thus, bask in the plausible deniability of the bad design!

Improve this design by adding redundancy and some routed segmentation between the offices. Keep in mind that if you do routing, you'll need to renumber the segments that are behind a router; you'll also need something that supports SVI's or dedicated routed interfaces.

A routed hub and spoke topology would be better but it require more fiber density than you can get on the SG series, and it would require running fiber (which may not have been done yet). It would also require things that support dynamic routing on fiber interfaces. SG series switches have a rather limited routing table size.

Is this okay?

I wouldn't do it that way, but many things depend on requirements. If your employer is really cheap, maybe it's the best you can do.

Does a cascade of switches affect overall performance?

Others addressed over subscription in this topology; then again if your uplinks are 10% utilitized all day long it wont matter. That said, you can't scale a design like this very well.

Can the last node obtain gigabit file transfer speeds from the other nodes?

As long as there isn't congestion along common paths.

Can the Main Switch handle every client?

It depends on how much load your clients are generating.

Honestly I'd be more worried about the questions you haven't asked... I elaborated on some of those above.

BTW, in a setup like this where you've run copper to every switch in the topology, uplink ports are not necessarily obvious unless you standardize that "the first two ports are my uplinks" (or something like that). You might not care now, but wait until you get your first broadcast storm and have to track down where it's coming from. Trust me... be sure it's easy to find the uplinks. It's also good to label your uplinks with source / destination on both sides.

Answer 5

When you design a network, You need to consider it in two ways.

• Technical
• Business

Specially your business can have critical functionalities and non critical functionalities. Your technical design should be fulfill their business requirement and if there is no business requirement means, there is no requirement for Network as well.

According to that your cascade design may create some draw back. If any failure on upstream switch, It will affect to all device which connected with It. If you want solve that issue you can config stack on upstream switches, but SG500 switches are not supported stacking. Additionally VSS also support for improve redundancy.

When you design a Network you should consider about about below point.

• Simplicity
• Redundancy
• Security

Based on your requirement, this may be okay or not okay. Check with your business and technical requirement.