service policy for iSCSI ports on 3850

[tato386]

I have a stack of 3850-24XS switches configured with several VLANs including one VLAN dedicated for storage/iSCSI traffic.  The servers are HP Proliant and the storage array is Dell EqualLogic. All iSCSI ports are 10GB fiber using 3rd party SFP modules. I would like to apply the Dell recommended service policy to the iSCSI access ports but I am concerned that the policy is desgined for a dedicated storage switch which mine are not. I would like to confirm that applying this policy solely to the iSCSI access ports will not negatively affect the remaining access and trunk ports which do not have any service policies attached.

On a side note, I have noticed that the stack's iSCSI vlan interface shows a fairly high PPS rate. This surprised me because very little traffic should be going thru this interface.  The bulk of traffic should be between the host and storage access ports and the iSCSI vlan port is really only there to give the storage array access to Internet for updates and/or to call home, send alerts, etc (I don't use a dedicated management interface for the array). Is this normal behavior?  I have attached a file with stats.

Thanks,
Diego

qos queue-softmax-multiplier 1200
lldp run
spanning-tree mode pvst (I currently have rapid-pvst)

#policy-map single-queue-buffer
   class class-default
   bandwidth percent 100
   queue-buffers ratio 100

# iSCSI VLAN access ports #
flowcontrol receive on
service-policy output single-queue-buffer

[Reza Sharifi]

Since you are applying the policy to individual interfaces and since the iSCSI devices are in a different vlan, it should not effect other ports and/or other vlans.  That said, after adding QOS to these ports, I would keep an eye on them for a period of time to make sure everything is functioning as excepted as sometimes, QOS config can produce strange behavior.

HTH 

[Joseph W. Doherty]

"Since you are applying the policy to individual interfaces and since the iSCSI devices are in a different vlan, it should not effect other ports and/or other vlans."

BTW, I'm not positive about the 3850 QoS architecture, but I suspect it's a bit like the prior 3750 architecture. If so, on the 3750s, QoS buffer resources are independent of VLANs. they're global. I.e. one port using buffers deprives other ports of those buffers.

[tato386]

Sounds good, I will give it a try.

What do you think about the PPS on the vlan interface?  Is that normal?

Thanks,

Diego

[Reza Sharifi]

Hi Diego,

The largest number is see in the output you posted is 11,988,000 which is less than 12Mbps.  I personally don't think that is too much of a concern, Just be careful when you deploy QOS specially on the 3850s, as they are not designed to be used for servers, storage, VM, etc.. They are mainly used for user campus environments and not so much for data centers.

Anyway, good Luck!

[tato386]

I understand these switches are not designed for iSCSI but I needed/wanted a bunch of 10G ports and the Nexus stuff (or any iSCSI specific 10G switch) is -way- too expensive.

From what you guys are telling me it sounds like I should apply the policy on all physical ports not just the ports dedicated to iSCSI traffic, correct?

Also, my concern with the file I uploaded was with the fact that there appears to be a significant amount of traffic on the vlan interface itself.  I would think the vlan interface would only come into play when data from iSCSI vlan is routed to/from other vlans.  There should be practically no traffic coming/leaving the ISCSI vlan so those numbers seem odd to me.  Maybe the vlan interface is counting/aggregating traffic count on all the  iSCSI vlan access interfaces?

[Joseph W. Doherty]

"I would like to confirm that applying this policy solely to the iSCSI access ports will not negatively affect the remaining access and trunk ports which do not have any service policies attached."

See my reply to Reza's posting. Further, if, as I suspect, 3850 buffers are a global resource, "no service policy" on a port, really means some kind of "default" policy, which might not be as optimal, for the switch as a whole, then having a explicitly defined policy.

Second, as Reza notes, the Catalyst 3K series of switches are designed for user edge devices, and so you might find problems supporting something like a "busy" iSCSI port or other kind of "busy" server port on one (especially w/o some config "tweaking").