FW 7.0.2 - Synrep Issues and Errors

Hello,

[tag:no] dcb enable

[tag:no] iscsi enable

[tag:flowcontrol] receive on

You'll also want to set MTU 9216 and portast on all the EQL and server ports.

This PDF covers how to in more detail.

en.community.dell.com/.../download.aspx

FYI: The doc says enable iSCSI, but I found that besides forcing a reboot, it only sets flowcontrol on ports connected to EQL controllers, not servers.   So better to do it manually.

@Pentium3nl:

I don´t think STP/RSTP is your *real* problem. If it helps to disable STP on these ports you are either confronted with a) many global (r)stp recalculations or b) a flappy connection which goes online and offline from time to time. Both things are not good and the real reason should be your target. So i suggest to keep looking for possible causers of a) or b).

@ Don:

Thanks, Don.

I still see absolutely no advantage in turning DCB globally off on switch side. On the array, however, i can do it "on the fly" without the slightest kind of disruption. Again, i am wondering why you removed it from the GUI with V7. I would change that back if i could. But then again, sadly i can´t ;-) I can only suggest.

Best regards,

Joerg

PS by the way, am i the only one who finds these lines at least a little bit scary ->

Hello,

Again, two reasons.  One it's per the IEEE spec.  End node DCB devices need to advertise their willingness.  But it's the switch that decides what's going on.   Similar to the Fibre Channel world.   So if the switch is configured for DCB then it's expecting everything attached is DCB enabled/configured as well.   it's not negotiated on a per end node basis.  You either do DCB or you don't.  You can't mix them.

Hi Don,

i am completely with you on that point. BUT to use DCB in real world, you have to make sure, that a) EVERY switch in the line of traffic EQL-to-initiator carries and supports DCB, b) every target can use DCB and c) every initiator can use DCB. Now let´s say a fresh EQL Version 7 comes to the network, it is attached to a fresh n4064 and thus automatically enables DCB and thus, uses PFC. After the N4064 there are other switches, let´s say some 8024s and others WITHOUT DCB enabled. What will happen? The EQL will enable DCB because it talks to the N4064, but the afterlying switches don´t and the initiatitor don´t, too. So - we find ourselfes in a bad scenario because what i (the user) want is at least flow control. Yes, i agree, pfc would be nice -  but let´s be honest - there are not many initiators in real world at this point which do fully support it.

So - what now? Either I am forced to do a *very* hard modification to my N4064s (which will break network connectivity by the way, just read the intructions i posted earlier) OR i can set DCB off on the CLI of the EQL with Version 7.

Again, i would set this off on the EQL array. At least while DCB is let´s say *in the beginning* state, especially when it comes to the *whole* ecosystem, in detail the initiators.

Best regards,

Joerg

Re: DCB.  Exactly, with DCB it's all or nothing.  Which is key at the switch layer. If the switch thinks it's a DCB environment, then it behaves that way.   If you have isolated switches for iSCSI then DCB isn't a big requirement.   Or if you have devices that don't yet do DCB you have to turn it off on the switch.

Re: New EQL. When that system comes on the network, there's no data on it yet.  It advertises that it can do DCB and that's all that's needed.   In fact every 30 seconds or so, per spec it advertises its willingness to do DCB.

Then you configure the array and configure DCB VLAN.  Done.  So any I/O you do to that array will be properly handled, prioritized and PFC will be enabled.

If you don't and just disable on the array, then in a DCB environment that traffic ends up in the lossy queue and no link layer flowcontrol as a backup.   Which can result in terrible performance and connection drops.  

If you don't and just disable on the array, then in a DCB environment that traffic ends up in the lossy queue and no link layer flowcontrol as a backup.   Which can result in terrible performance and connection drops.

For a 8164/N4064 i don´t believe that is correct. The 8164 factory design (standard config) is preconfigured to respond to DCB and EQLs will select and use DCB. But the 8164 (factory design) has also traditional flow control enabled and will respond to it and use it. I can confirm a 6210S with dcb disabled via CLI connected to a factory standard 8164 behaves perfect, uses flowcontrol and has no connection drops or performance problems. In fact, we did quite a few nasty benchmarks with it and it performed really well.

Now another word regarding "DCB environments" and "the other end of the line". I am not aware of many s/w initiators which really support dcb. So if you don´t use dependent initiators - you probably will not be able to use dcb in many cases.

Best regards,
Joerg

It's not about how a particular switch is configured by default.  It's how DCB is designed to work.

I'm glad you are not having any issues. But others might if they do the same as you.

 Are you sharing those switches with non-iSCSI traffic?

The docs I linked show that with DCB off, you have to enable flowcontrol.    

Re: Initiators.  Correct,  there's some code in Windows 2012 for it, but right now if you want DCB you need to use a HW HBA.  Currently the supported one for EQL is the Broadcom CNA adapter.  

Yes, that is only one adapter. In my opinion a quite remarkable reason for enabling DCB as default in your switches and also in your storage arrays. Because DCB is *always* end to end. And as there is not many on the initiator end this time...

My personal opinion: You would have less problems (at this very time - the future is another thing, i am sure the future is DCB) making it easier to disable DCB or disable it per default and make it explicitly "activatable".

But so - i guess there is no way i can convince you to reconsider the DCB default activation in your switches and/or your storage arrays ;-)

Best regards,

Joerg

Hello,

On that point I totally agree with you.   I wish DCB was not enabled on switches by default.  The end node devices like the array follow what the switch is doing so there's no harm there having it enabled.

When you get a new switch there's always configuration that needs to be done.  VLAN assignment, setting MTU size,  IP addresses etc.    So at that point disabling DCB and enabling flowcontrol isn't a difficult task.