This is a quick write up on how to make sure that your iSCSI traffic gets the proper buffering on the switch ports if needed.
I assume the majority if not all of the traffic on the port is going to be iSCSI so we aren’t going to focus on queuing but instead focus on buffers of congested ports.
I am using an ESXI host with a vSwitch, which means I can not tag DSCP at the vSwitch level, I’d have to move to a DVS. Also my NAS (Synology) doesn’t tag DSCP so I will just use an input service-policy.
So let’s begin, first of all let’s make sure our ISCSI traffic is properly classified and put into the correct queue.
ip access-list extended ISCSI
permit tcp any any eq 860
permit tcp any eq 860 any
permit tcp any any range 3260 3264
permit tcp any range 3260 3264 any
class-map match-all ISCSI
match access-group name ISCSI
policy-map ISCSI
class ISCSI
set dscp cs4
mls qos queue-set output 2 threshold 1 100 100 1 3200
mls qos queue-set output 2 threshold 2 100 100 1 100
mls qos queue-set output 2 buffers 90 6 2 2
G1/0/13-14 are my host’s dedicated storage ports, and g2/0/21-22 are my Synology dedicated storage ports.
interface range g1/0/13-14, g1/0/21-22
queue-set 2
service-policy input ISCSI
Now I chose to mark my ISCSI traffic as CS4 (DSCP 32), which is non-standard but it was the only traffic I was doing QoS for on my 3750x.
3750x#sh mls qos maps dscp-output-q
Dscp-outputq-threshold map:
d1 :d2 0 1 2 3 4 5 6 7 8 9
————————————————————
0 : 03-03 03-03 03-03 03-03 03-03 03-03 03-03 03-03 04-01 04-01
1 : 04-02 04-01 04-02 04-01 04-02 04-01 02-01 02-01 02-01 02-01
2 : 02-01 02-01 02-01 02-01 02-02 03-01 02-01 02-01 02-01 02-01
3 : 02-01 02-01 01-03 01-03 02-01 02-01 02-01 02-01 02-01 02-01
4 : 01-03 01-03 01-03 01-03 01-03 01-03 01-03 01-03 02-03 02-03
5 : 02-03 02-03 02-03 02-03 02-03 02-03 02-03 02-03 02-03 02-03
6 : 02-03 02-03 02-03 02-03
Now as we can see from the table above, DSCP 32 corresponds to queue 1 threshold 3.
That is why I configured a custom queue-set (2) so that queue 1 gets 90% of the interface buffers and threshold 3 can get 3200% of that 90% by tapping into the common-pool if it needs to (and if available).
We can easily verify it by running “show mls qos int g1/0/21 statistics”
In the above output queue 0 is actually queue 1 in the config. So anything we configured for queue 1 will show up as queue 0 when running the above show command.
We see here the majority of my enqueued packets were in queue 1 threshold 3. There were a few packets in queue 2 threshold 2 and 3, which I assume were something with the control-plane of iSCSI but am not sure (nor do I care to check).
That is it, not any bursts of traffic will have a much better chance of being absorbed and sent out instead of being dropped and re-transmitted.