<?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: Fabric MetroCluster sporadically selectes non-HA pathes to shelf in ONTAP Discussions</title>
    <link>https://community.netapp.com/t5/ONTAP-Discussions/Fabric-MetroCluster-sporadically-selectes-non-HA-pathes-to-shelf/m-p/18962#M4462</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;After rechecking cabling I realized that it did not correspond to pictures in tr-3548. Although nowhere is stated that cabling shown is mandatory (and not just an example) I changed it to be precisely as shown in tr (specifically Appendix G, figure 22). I did not observe Mixed-HA warning any more since then.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Of course it may be just a coincidence.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I wish NetApp were more explicit about requirements. E.g. – does it matter that port 0a is connected to ESH B and port 0b to ESH A? Or could it just as well be reversed? Etc …&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Tue, 07 Jun 2011 17:33:45 GMT</pubDate>
    <dc:creator>aborzenkov</dc:creator>
    <dc:date>2011-06-07T17:33:45Z</dc:date>
    <item>
      <title>Fabric MetroCluster sporadically selectes non-HA pathes to shelf</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Fabric-MetroCluster-sporadically-selectes-non-HA-pathes-to-shelf/m-p/18953#M4459</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I believe I have seen similar problem posted recently.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;FMC with 2 x FAS3140, 7.3.4 (factory delivery), 4 HBA used. After fully booting node it complaints that some disks are not multipathed. Indeed, out of 4 available pathes Data ONTAP selectes two going via the same switch (i.e. both to A/B side of shelf). After several unplugging and replugging A and B channels for this stack it suddenly setlles on correct A/B pathes. But is not clear why it selects suboptimal pathes nor how to force path re-selection using less intrusive means.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Is it a known issue? I am going to update to 7.3.5.1P3 anyway (but am a bit uneasy as it still is not explicitly listed in compatibility matrix); it is the first time system is booted after assembling and switch interconnect is finished.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 05 Jun 2025 06:53:40 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Fabric-MetroCluster-sporadically-selectes-non-HA-pathes-to-shelf/m-p/18953#M4459</guid>
      <dc:creator>aborzenkov</dc:creator>
      <dc:date>2025-06-05T06:53:40Z</dc:date>
    </item>
    <item>
      <title>Fabric MetroCluster sporadically selectes non-HA pathes to shelf</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Fabric-MetroCluster-sporadically-selectes-non-HA-pathes-to-shelf/m-p/18957#M4461</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I had this before too.&amp;nbsp; Basically, if you have the switch ports configured correctly (see the TR... 3548, iirc), then basically, it is probably a ESH and/or disk fw issue.&amp;nbsp; When you upgrade, have somebody close to the system.&amp;nbsp; Shelf fw upgrades on fabric-attached metroclusters have never worked correctly for me, so you might need someone to re-seat the ESH modules to get them to boot correctly.&amp;nbsp; Then, of course, you will have aggregates to sync up, etc.&amp;nbsp; It could be a long, rather involved process.&amp;nbsp; I think your Brocade Fabric OS needs to be at 6.1.1 or so too for 7.3.5.1, but you can easily check the matrix for that.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The path selection algorithm for disks on metroclusters is unfortunately not as refined as one would hope.&amp;nbsp; FWIW, I haven't had the problem for a long time, but it was a real PITA with support when it happened.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Good luck.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 02 Jun 2011 23:15:35 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Fabric-MetroCluster-sporadically-selectes-non-HA-pathes-to-shelf/m-p/18957#M4461</guid>
      <dc:creator>shaunjurr</dc:creator>
      <dc:date>2011-06-02T23:15:35Z</dc:date>
    </item>
    <item>
      <title>Re: Fabric MetroCluster sporadically selectes non-HA pathes to shelf</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Fabric-MetroCluster-sporadically-selectes-non-HA-pathes-to-shelf/m-p/18962#M4462</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;After rechecking cabling I realized that it did not correspond to pictures in tr-3548. Although nowhere is stated that cabling shown is mandatory (and not just an example) I changed it to be precisely as shown in tr (specifically Appendix G, figure 22). I did not observe Mixed-HA warning any more since then.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Of course it may be just a coincidence.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I wish NetApp were more explicit about requirements. E.g. – does it matter that port 0a is connected to ESH B and port 0b to ESH A? Or could it just as well be reversed? Etc …&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 07 Jun 2011 17:33:45 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Fabric-MetroCluster-sporadically-selectes-non-HA-pathes-to-shelf/m-p/18962#M4462</guid>
      <dc:creator>aborzenkov</dc:creator>
      <dc:date>2011-06-07T17:33:45Z</dc:date>
    </item>
    <item>
      <title>Re: Fabric MetroCluster sporadically selectes non-HA pathes to shelf</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Fabric-MetroCluster-sporadically-selectes-non-HA-pathes-to-shelf/m-p/18965#M4463</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The requirements before software disk ownership were even wierder.&amp;nbsp; The documentation for fabric-attached metroclusters has always been very incomplete.&amp;nbsp; I made a big stink once and got 3548 cleaned up a lot because the information there conflicted with other setup guides.&amp;nbsp; The confusion isn't nice when you are stuck in the middle of an installation either.&amp;nbsp; But, I digress...&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Even with normal and stretch metroclusters, you have a sort of "backwards" hookup of your normal 0a and 0c ports to the B modules.&amp;nbsp; I'm no metrocluster expert but we have a half dozen of them in varying configurations.&amp;nbsp; The inflexiblity (and frankly immaturity) of the disk fabric is still one of the elements that irritates me the most.... besides the wild experiment with MPO interconnects for stretch clusters... &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Anyway, I hope most of the unclear parts of metrocluster setups are clear in 3548, but if not, feel free to ask or open a case, or both...&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;span class="lia-unicode-emoji" title=":winking_face:"&gt;😉&lt;/span&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 07 Jun 2011 23:12:04 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Fabric-MetroCluster-sporadically-selectes-non-HA-pathes-to-shelf/m-p/18965#M4463</guid>
      <dc:creator>shaunjurr</dc:creator>
      <dc:date>2011-06-07T23:12:04Z</dc:date>
    </item>
  </channel>
</rss>

