How to do switch and uplink sizing?

[at@ps]

Hey all,

Suppose I have a small office with 100 PCs - none of them use high-bandwidth applications, such as video streaming or data-intensive tasks.

How to know the switch's bandwidth needed and the uplink as well?

The purpose of my question is to have an idea how to know the specs of the switch I need.

Thanks,

[liviu.gheorghe]

Hello at@ps ,

depending on your needs, determine if you require a Layer 2 or a Layer 3 switch.

For the Layer 2 switch, you have the Catalyst 1000 Series which offer up to 48 10/100/1000 RJ45 ports and 4 1 G or 10 G SFP uplink ports. The uplink ports can be used to connect up to eight switches in a single stack and manage them via a single IP address for easier  management activities.

For a Layer 3 switch, you have the Catalyst 9200 Series which offer similar port densities as the C1000 and superior capabilities in term of forwarding rates. They also have a dedicated stacking option using separate stacking ports for higher throughput.

You can find detailed information about the two switch platforms here:

https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-1000-series-switches/nb-06-cat1k-ser-switch-ds-cte-en.html?oid=otren019232

https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9200-series-switches/nb-06-cat9200-ser-data-sheet-cte-en.html

Hope it helps.

[at@ps]

Thanks for your response, but I'm not asking about switch models; I'm asking about the bandwidth of the switch!

[liviu.gheorghe]

The switch models have been dimensioned by Cisco based on the number of ports for a wide range of use cases. Take for example the C9200-24T-4X switch - it has a switching capacity of 128 Gbps and a forwarding rate of 95.23 Mpps. As you can see there is a level of oversubscription built into the switch because for the access layer where this switch is supposed to function, not all 24 user ports will do ftp at the same time.

If you would like to calculate the actual usage for your specific needs, you would have to monitor each port for a significant period of time, say 30 days, and record the usage over time and then take each port usage and sum it up to get the actual switching capacity needed. You will have to multiply this value with a factor to accommodate traffic spikes and plan for seasonal variations.

Not an easy process.

[balaji.bandi]

This is hard to say, until you have real KPI statistics in hand. or else you go with estimated only the outcome may be different than expected some times.

This only addreses switch only - you need to look other side of the device where you connecting like ISP router / firewall so on.

check the switch selector :

https://www.cisco.com/c/en/us/products/switches/switch-selector.html?guide=enterprise-e&ccid=cc000098&oid=otres000315

if you have good budget look for Cat 9300 models :

https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9300-series-switches/nb-06-cat9300-ser-data-sheet-cte-en.html

[Joseph W. Doherty]

Laugh, that's the 64 bit question.  It's best approached by using black magic or perhaps reading entrails.  ; )

Seriously, though, it's very hard to deride without having actual usage stats over some time period.  Even then, capacity based on averages can misleading, I like Mark Twain's "There are three kinds of lies: lies, damned lies, and statistics." (and averages are statistics).

If you design a network without any oversubscription, likely you'll never have any performance problems beyond the base throughput per host, but such designs tend to be way, way too expensive, and often, very unnecessary.

So, what is commonly done is designing networks with oversubscription, but, again, we're back to, how much should you allow.

Traditionally, way back, a couple of rules of thumb were user LAN access switches could support about 24 edge ports to 1 uplink port  (same bandwidth for all ports) and where server LAN access switches could support about 8 ports to 1 uplink port (same bandwidth for all ports).  Of course, since the time of those rules, LANs, and their clients, servers, network capacities, and network applications have all "evolved", such rules of thumb might no longer apply (if they ever really did).

In your OP, you mention having 100 PCs, that are not high-bandwidth consumption.  Could you define what that means?  Every packet is transmitted at wire-speed/line-rate.

For switch selection, topology is important, along with where the data actually flows.  For example, on a 24 port switch with one uplink, how much traffic, if any, flows directly between hosts vs. flows up and down the uplink.  If almost 100% of the traffic flows only between edge ports and the uplink, the uplink is the bottleneck, and the switch's performance only really needs to support the uplink port's bandwidth.

However, if the switch is in question, is being used for a core, and the bulk of the traffic is between all the switch ports, then the switch's capability, for moving traffic is possible its number of ports times what the above access uplink port bottleneck switch needed to support.  Big difference!

Or, with 100 hosts, not too difficult, perhaps, have them all connected to a stack or chassis switch.  There its capacity need might be the combination of all the above, yet, what if all that traffic is destined to just one server?  If so, much like the switch uplink being the bottleneck, the whole chassis might only need to support the server's port capacity.

Another wrinkle is whether you use QoS.  Often users will complaint about a poor performing network, yet usage statistics (lies?) show no performance issues.  (This because such statistics don't usually capture the impact of microbursts, but that's something QoS might mitigate.)

So, unfortunately, there's no easy cook book recipe for properly "sizing" network equipment.  In the real world, often networks are designed more around budget, which may be too little or even too much for an optimal sized network.

[Ramblin Tech]

@Joseph W. Doherty offers sound advice here and a subtle perspective I would add for this exercise is to not think of the switch as having an “uplink”, but rather a “downlink”. By that I mean small office PCs tend to be clients that consume data from servers that might be local to the office or in a remote data center. The traffic volume will be overwhelming in the “down” direction from the server toward the client PCs. In this age of cloud-hosted apps, the trend is also away from office-based servers and even corporate data centers and increasingly to cloud providers across the Internet. 

With the premise being that your PCs are clients consuming data, the question becomes: where are your servers and what is the bandwidth bottleneck to them? If there is a local server that offers up most of the traffic load to the PCs, then its NIC will be network bottleneck; make sure your trunks between switches and routers are at least as fast as the server NIC[s] (plus LAG on the trunks for resilience). If your servers are remote (data center or cloud), then the office’s WAN connectivity will be the network bottleneck; again, make sure all of the local network trunks are at least as fast as the WAN (+ trunk LAG resilience). 

As Joe said, network capacity often comes down to budget allocations rather than careful a priori traffic load calculations, and this especially applies to recurring WAN costs. However, with no “video streaming or data-intensive tasks” there should not be a tremendous amount of business traffic over the WAN and any reasonable budget should work. That said, let’s not kid ourselves: unless you have draconian security policies, there will be video traffic on your network coming down to the PCs from all the usual Internet sources. This is where QoS comes in handy in being able to prioritize business traffic over non-business.