How many switches can be stacked/interconnected?

I would like to know how many switch can be stacked with fiber channel to get a best transfer rate between computers.

I have 200 computers connected to 12 3Com switches. All switches have two fiber ports.

Is the best way to have fiber backbone switch and connect fiber channel from every switch to the backbone? Or connect switch 1 to switch 2 to switch 3 to ... switch 12 to switch 1 again?

Thanks!

Solution 1:

Let's get some terminology aside first.

"Fiber channel" (or "fibre channel", as it's more typically known) is a specific networking technology used in storage area networks. I think, when you say "fiber channel", you're really saying "ports on an Ethernet switch that fiber optic cables connect to". If you're really talking about fibre channel then, let me know... (but, to my knowledge, 3Com has never made a fibre channel switch).

The term "stacking" typically refers to an interconnection between Ethernet switches through a (typically proprietary) dedicated interface that extends some significantly high fraction of the capacity switch's switching capability to another switch (extending the "switching fabric" outside the box to another switch). Often, stacking interfaces operate at multi-gigabit speeds (40Gb/sec on the Dell PowerConnect 6200-series switches, for example).

There is no "hard limit" to the number of Ethernet switches in a network. You can add as many as you want. Latency will increase as the number of "hops" between any two endpoints goes up and, obviously, you're increasing complexity and odds of failure as you add more switches.

Switched Ethernet LANs can't scale indefinitely. Excessive broadcasts or flooding of frames to unknown destinations will limit their scale. Either of these conditions can be caused by making a single broadcast domain in an Ethernet LAN too big.

Broadcast traffic is easy to understand, but flooding of frames to unknown destinations is a bit more obscure. If you get so many devices that your switch MAC tables are overflowing, switches will be forced to flood non-broadcast frames out all ports if the destination of the frame doesn't match any entries in the MAC table. If you have a large enough single broadcast domain in an Ethernet LAN with a traffic profile that hosts talk infrequently (that is, infrequently enough that their entries have aged out of the MAC tables on your switches), then you can also get excessive flooding of frames to unknown destinations.

At the scale you're talking about (200 computers), there isn't going to be a problem with flooding of frames to unknown destinations. Whether or not you have broadcast problems will depend on the specific protocols and applications used. If you're using off-the-shelf Microsoft OS's and applications, I'd hazard that your level of broadcast traffic is just fine.

In general, a "star" topology that minimizes "hops" between switches is the most effective Ethernet topology. Placing servers or other highly-utilized resources in the center of the star will minimize traffic overall. If your switches support aggregating multiple links together, you can use this feature to increase bandwidth on inter-switch links. You should be using a tool (even a simple one like MRTG) if your switches support monitoring with SNMP to determine where your bandwidth utilization "hotspots" are.

You can create "loops", provided your switches support the spanning-tree protocol, to handle failures of switches or inter-switch links. That's a little more advanced topic, and not something I'd recommend you approach until you have more experience.

Solution 2:

The maximum number of switches that can be stacked (not a ring - a string or a star, unless you're using STP with failover on the backplane ports) depends on the switch. As an example, the 3Com® Switch 5500G-EI 24-Port supports 8 stacked using an 8 port SFP expansion module. Some switches connect in serial, one to the next. Other switches like the 5500G connect in a star configuration with a "parent" management switch and up to 8 "child" switches.

Use VLAN's to reduce broadcast domains.

Many well designed network office networks don't need a shared backplane. The majority of traffic goes to one of three destinations - file server, internet or printer. A single shared backplane is really only "required" for internal peer to peer traffic. I've never seen a situation with a single shared backplane that didn't segment anyway with VLANs. The shared backplane makes it easier to do physical moves on the network. Network re-configuration after a physical machine is moved to a new office (port) can be done remotely on the switch's management console without re-plugging cables. The shared backplane starts making sense when you have many physical servers and many clients need to connect to multiple servers. These days, this can be solved with bigger boxes and virtualization, reducing the count to a one or two physical servers per client (still could have many physical servers, just no clients that need "full speed" access to all servers, i.e. segment servers by department or service needs.)

In a common network setup, bandwidth is increased by installing a higher bandwidth NIC or trunk/bond multiple ports and NIC's where aggregate traffic is, usually the file server. In the example 3com switch you'd use a 10g NIC in the server and 1g NIC's in the clients

If there is no peer to peer traffic and no daisy chaining of switches (each switch connects to it's own NIC on the server) there will be no performance improvement with a shared backplane. If VLAN's aren't used the shared backplane may even be slower due to a larger broadcast/collision domain.