<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Backplane Traversal in ONTAP Discussions</title>
    <link>https://community.netapp.com/t5/ONTAP-Discussions/Backplane-Traversal/m-p/148911#M33137</link>
    <description>&lt;P&gt;Hi&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Unlike 7 mode (for FCP only as well) the data for the incorrect path is not going on the IC/PB. it goes via the cluster network, by default on the AFF200 it's ports e0A and e0B which are 10GB each&amp;nbsp; (can also use other ports - on the same speed).&lt;/P&gt;
&lt;P&gt;it should add very small latency (around 1ms).&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;as NFS v3 is stateless. i would place the LIF on the same location as the volumes. and let the LIF failover to&amp;nbsp;handle redundancy. in NFS v4 or if pNFS involved - need to read some docs, but in general from my&amp;nbsp;experience the LIFS fails-over faster than the aggregates... (assuming ARP cache on the switches not creating any problems).&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Gidi&lt;/P&gt;</description>
    <pubDate>Sun, 16 Jun 2019 22:25:30 GMT</pubDate>
    <dc:creator>GidonMarcus</dc:creator>
    <dc:date>2019-06-16T22:25:30Z</dc:date>
    <item>
      <title>Backplane Traversal</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Backplane-Traversal/m-p/148898#M33132</link>
      <description>&lt;P&gt;AFF200 Active/passive, with one SVM on the active node, that also owns the data aggr.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Say I put a SVM lif on the passive node. 10Gbe SFP+. How will that affect performance? How high is the throughput of IC? I am running switchless. The access protocol is nfs.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Thanks&lt;/P&gt;</description>
      <pubDate>Wed, 04 Jun 2025 12:28:03 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Backplane-Traversal/m-p/148898#M33132</guid>
      <dc:creator>AllanHedegaard</dc:creator>
      <dc:date>2025-06-04T12:28:03Z</dc:date>
    </item>
    <item>
      <title>Re: Backplane Traversal</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Backplane-Traversal/m-p/148911#M33137</link>
      <description>&lt;P&gt;Hi&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Unlike 7 mode (for FCP only as well) the data for the incorrect path is not going on the IC/PB. it goes via the cluster network, by default on the AFF200 it's ports e0A and e0B which are 10GB each&amp;nbsp; (can also use other ports - on the same speed).&lt;/P&gt;
&lt;P&gt;it should add very small latency (around 1ms).&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;as NFS v3 is stateless. i would place the LIF on the same location as the volumes. and let the LIF failover to&amp;nbsp;handle redundancy. in NFS v4 or if pNFS involved - need to read some docs, but in general from my&amp;nbsp;experience the LIFS fails-over faster than the aggregates... (assuming ARP cache on the switches not creating any problems).&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Gidi&lt;/P&gt;</description>
      <pubDate>Sun, 16 Jun 2019 22:25:30 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Backplane-Traversal/m-p/148911#M33137</guid>
      <dc:creator>GidonMarcus</dc:creator>
      <dc:date>2019-06-16T22:25:30Z</dc:date>
    </item>
    <item>
      <title>Re: Backplane Traversal</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Backplane-Traversal/m-p/148918#M33139</link>
      <description>&lt;BLOCKQUOTE&gt;&lt;HR /&gt;&lt;a href="https://community.netapp.com/t5/user/viewprofilepage/user-id/38137"&gt;@GidonMarcus&lt;/a&gt;&amp;nbsp;wrote:&lt;BR /&gt;
&lt;P&gt;it should add very small latency (around 1ms).&lt;/P&gt;
&lt;HR /&gt;&lt;/BLOCKQUOTE&gt;
&lt;P&gt;This is extremely HUGE latency for an all flash array.&lt;/P&gt;</description>
      <pubDate>Mon, 17 Jun 2019 03:58:32 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Backplane-Traversal/m-p/148918#M33139</guid>
      <dc:creator>aborzenkov</dc:creator>
      <dc:date>2019-06-17T03:58:32Z</dc:date>
    </item>
    <item>
      <title>Re: Backplane Traversal</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Backplane-Traversal/m-p/148929#M33140</link>
      <description>&lt;P&gt;Know the saying - Never assume it's a one way street?&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I just tried running a 4k 100%&amp;nbsp; random&amp;nbsp; 100 % read on a IOmeter load, while failing over the LIF to the other controller.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Either the 10Gbe&amp;nbsp;network is the limiting factor or the indirect connection is not being affected by the failover.&lt;/P&gt;
&lt;P&gt;24x 960GB&amp;nbsp;SSD&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="fail.png" style="width: 777px;"&gt;&lt;img src="https://community.netapp.com/t5/image/serverpage/image-id/9097i5716EDB482BF64AC/image-size/large?v=v2&amp;amp;px=999" role="button" title="fail.png" alt="fail.png" /&gt;&lt;/span&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="direct.png" style="width: 778px;"&gt;&lt;img src="https://community.netapp.com/t5/image/serverpage/image-id/9098iDCEB4F861CE0AE92/image-size/large?v=v2&amp;amp;px=999" role="button" title="direct.png" alt="direct.png" /&gt;&lt;/span&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 17 Jun 2019 07:53:36 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Backplane-Traversal/m-p/148929#M33140</guid>
      <dc:creator>AllanHedegaard</dc:creator>
      <dc:date>2019-06-17T07:53:36Z</dc:date>
    </item>
  </channel>
</rss>

