Can I use a Catalyst 2960-S for iSCSI?
I need to set up a modest iSCSI SAN with a few ESX hosts and one storage array. Can I get by using a Catalyst 2960-S or do I need to upgrade? Are there any special tweaks I need to make to the switch in order to handle iSCSI? The switch will be dedicated to the SAN; no other traffic except management will be present.
Speaking as someone who started working in an environment where 2960 switches were used for iSCSI - don't do it! We experienced regular target logouts due to full buffers. @nicotine 's answer below is a very good one.
@JStretch: ¿ tag edit ? Thoughts on making these "cisco-catalyst" instead of the specific model numbers? I've been editing lower-level users' tags... but didn't want to step on your toes :)
@Craig I'm no one special; feel free to hack up my posts. I've edited the tag, good idea!
@pauska Given that there are many environments where a 2960S is an *upgrade*, is it *always* a mistake to use this class of switch for storage traffic? (even for small sites)
@ewwhite it's hard to say - a small shop with a not-so-fast SAN and not many hosts could probably work just fine on them. Our troubles started when we added a EMC VNX to the mix, which was a much much faster SAN than our previous one. Maybe Cisco isn't the best way for those SMB customers. I know that newer Dell PowerConnect models have alot more buffering plus DCB features.
Given that the Cat2960-S is a desktop/access switch, with very, very small buffers, you would likely experience a lot of output drops. A datacenter switch, such as a 4948E, would be a better choice for an iSCSI application.
To understand the reasoning behind this, you have to remember that an ethernet switch is either transmitting, or not transmitting on a specific port. If traffic arrives on port 1 for port 2, and port 3 is already sending traffic to port 2, the traffic from port 1 has to be buffered until there's a gap in the traffic from 3 to 2. If the buffer fills, additional traffic will be dropped. The term "microburst" is used to reference traffic that, over time, is well below the limit for the interface, but occasionally bursts to cause output drops.
I am not as familiar with the 2960-S platform, but enabling QoS (without extensive tuning, see comments below) on it would probably be a bad idea; that would actually increase the number of output drops. Enabling QoS splits your very small buffers into 4 even smaller buffers, and most traffic will hit only one of them.
Agreed on everything except about turning on QoS. At least on the Catalyst 3560/3750 the buffers can be tuned to perform better with mls qos than without it. This document is a good reference but it's for the 3560. https://supportforums.cisco.com/docs/DOC-8093
Edited answer to reflect that. I'm unsure you'll actually get BETTER buffer performance with tuning -- the default when QoS is disabled tries to be as "fair" as possible and assumes all traffic is the same class. Enabling it and tuning it may allow you to allocate more TX buffer to your downstream port, but QoS is in and of itself "managed unfairness"