<div dir="ltr">I am going to buck the trend.<div><br></div><div>DCB shouldn't be enabled and configured on a whim, however, if this is for backup, how long before these backups need to be rehydrated/booted in another DC or moved to a second DC for business availability/continuity purposes? </div><div><br></div><div>As for tuning (jumbo-frames, QoS, Flow Control) the network to the requirements, this is still best practice (as we would for voice) - particularly since iSCSI overhead is heavy (in comparison to FCoE).</div><div><br></div><div>I agree with the KISS principle, but DCBs aren't the place for that because of the complexity that they are (the same would be said for MPLS, VXLAN, etc) it's about business/regulatory requirements that drives a competitive edge. Think "If you're going to do it, do it properly" is more applicable.</div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Regards,<div><br></div><div>Peter Tiggerdine</div><div><br></div><div>GPG Fingerprint: 2A3F EA19 F6C2 93C1 411D 5AB2 D5A8 E8A8 0E74 6127</div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 9, 2023 at 12:19 PM Robert Hudson <<a href="mailto:hudrob@gmail.com">hudrob@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I largely agree with Luke. Given you're on a dedicated iSCSI network, keep it simple. DCB and other services will only add things that you'll later need to troubleshoot and eliminate as the root cause of network issues on your iSCSI network when they invariably happen (it's rare that I've come across a well and consistently configured iSCSI network, and I've been playing in that space since the mid 2000s). Chances are your OS/hypervisor vendor of choice publishes best practices for how to configure DCB - but as noted, DCB is specifically there to deal with converged networks (where your iSCSI traffic is sharing an ethernet fabric with other traffic types), and you don't seem to have that situation.<div><div><br></div><div>Jumbo frames help in busy iSCSI networks by increasing throughput - but you need to make sure every device from one end of the communications to the other fully supports it. Again, follow vendor advice here. Getting this wrong can cause all sorts of "fun".</div></div><div><br></div><div>Flow control, buffer tuning (large buffers tend to help with iSCSI traffic), etc, can all help to eke out a few more small percentage points of performance, but again, the further you drift from the KISS principle, the more fun you're likely to have troubleshooting later.</div><div><br></div><div>Above all - set and document policy in all things, audit against that policy both at initial setup and for drift during the lifecycle of the environment.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 9 Nov 2023 at 12:20, Luke Iggleden <<a href="mailto:luke@iggleden.com" target="_blank">luke@iggleden.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>Hi Andres,</p>
<p>Unless you are running other services on the switch it's not
useful.</p>
<p>Typically these are the only useful changes:<br>
</p>
<p>Jumbo Frames (YMMV), depends on vendor.</p>
<p>Flow Control on (so hosts can issue back off - hopefully without
dropping frames)</p>
<p>Depending on the switch, buffer tuning.</p>
<p>Don't use control plane things, like MLAG, Stacking, STP, etc
etc. Flat fabric.</p>
<p><br>
</p>
<p>Cheers,</p>
<p>Luke Iggleden<br>
</p>
<p><br>
</p>
<div>On 9/11/2023 11:14 am, Andres
Miedzowicz wrote:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal"><span lang="EN-US">Hello everyone,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">I wanted to get some
opinions on the use of DCB and its associated protocols in a
storage-only (iSCSI), non-converged network. Any thoughts
about the pros and cons of enabling DCB in a scenario where
100% of the traffic on a switch is bi-directional iSCSI
storage (virtual machines and backups)?<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Thanks in advance.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Andres<u></u><u></u></span></p>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
AusNOG mailing list
<a href="mailto:AusNOG@lists.ausnog.net" target="_blank">AusNOG@lists.ausnog.net</a>
<a href="https://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">https://lists.ausnog.net/mailman/listinfo/ausnog</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net" target="_blank">AusNOG@lists.ausnog.net</a><br>
<a href="https://lists.ausnog.net/mailman/listinfo/ausnog" rel="noreferrer" target="_blank">https://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
</blockquote></div>
_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net" target="_blank">AusNOG@lists.ausnog.net</a><br>
<a href="https://lists.ausnog.net/mailman/listinfo/ausnog" rel="noreferrer" target="_blank">https://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
</blockquote></div>