Here is snippet of Force10 switch port configuration of port facing storage front-end port or host NIC port dedicated just for iSCSI. In other words this is non-DCB switch port configuration.
[/Updated]
And as always, any comment is really appreciated.
interface TenGigabitEthernet 0/12
no ip address
mtu 12000
switchport
flowcontrol rx on tx off
spanning-tree rstp edge-port
spanning-tree rstp edge-port bpduguard shutdown-on-violation
storm-control broadcast 100 in
storm-control unknown-unicast 50 in
storm-control multicast 50 in
no shutdown
MTU is set to 12000 which is the supported maximum and allowing to use Jumbo Frames. I know 9216 is enough MTU for iSCSI however modern switches is capable for larger MTU without performance overhead so why not use it?
Flow-control is enabled for receive traffic so switch can sen PAUSE frame to initiator or target to wait a while in case switch port buffers are full. Transience flow-control is not enabled because switch port buffers are not deep enough to help.
Switch port is set to edge-port to eliminate spanning-tree algorithm because connected devices are edge devices - server (iSCSI initiator) or storage (iSCSI target).
[Updated at 2015-01-19 based on Martin's comment]
Bpduguard can be optionally enabled on switch port as prevention against cabling mistake (also known as an human factor) because iSCSI storage should not send any BPDU.
[Updated at 2015-01-19 based on Martin's comment]
Bpduguard can be optionally enabled on switch port as prevention against cabling mistake (also known as an human factor) because iSCSI storage should not send any BPDU.
Storm control of broadcasts, multicasts and unknown unicasts is enabled to eliminate unwanted storms. Please note that unicast storm may not be enabled because iSCSI generates lot of traffic which can be possible identified as unicast storm.
That's it for iSCSSI network configuration of dedicated ports. When you use shared ports for iSCSI and LAN traffic you should use DCB. DCB configuration is similar to configuration above but replacing flow-control with priority-flow-control (PFC) and leveraging link QoS technology (ETS) based on 802.1p CoS. You can check DCB design justification and sample configuration for iSCSI here,
And as always, any comment is really appreciated.
4 comments:
thank you for this config sample. Is storm-control necessary on an switch used only for iSCSI?
Best regards,
Paul van Wijck
Hi Paul,
when you have dedicated switches for iSCSI SAN you are right that there is only small probability of L2 storm issues.
It is more important on unified (converged) networks where is significantly bigger probability of common network issues.
However, storm controls are just another safety mechanisms to keep your iSCSI network healthy and in optimal state. So let's ask another question. Why not use these safety mechanisms when your switch support it?
And as always, the final decision is up to you.
So to answer strictly your question ... storm-control is not necessary on dedicated iSCSI switches but it is recommended just in case. By the way, the same principle apply for example to Spanning Tree Protocol. Do you need STP on dedicated iSCSI switches when you are sure there are not loops? Maybe not. At least until someone will make the loop in your iSCSI fabric. It is just safety mechanism against human errors. And we are just humans so we are doing errors ... sometimes :-)
I will recoomend "spanning-tree rstp edge-port bpduguard shutdown-on-violation" as protection against cabling errors, because you should never receive bpdu from iscsi storage
Yes, you are right. bpduguard can improve network stability against human mistake. Blog post updated.
Post a Comment