<?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: Cluster Peer Unavailable - Data and ICMP Reachable in ONTAP Discussions</title>
    <link>https://community.netapp.com/t5/ONTAP-Discussions/Cluster-Peer-Unavailable-Data-and-ICMP-Reachable/m-p/133662#M29221</link>
    <description>&lt;P&gt;So the solution to my problem here was two-fold:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;1. Existing Peer relationship between our production ClusterA and our DR provider's ClusterB was configured using ClusterA's DEFAULT IPSpace. &amp;nbsp;On the advice of NetApp support I created a separate (dedicated) IPSpace for ClusterA to talk to ClusterC. &amp;nbsp;This means I had to create a new/dedicated IPSpace as well and add a route.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;2. MTU sizes. &amp;nbsp;My downfall here was that my Intercluster LIFs on ClusterA and associated Broadcast domain is set to 9000. &amp;nbsp;However, I confirmed with our DR provider that the ports/broadcast domain at their end is set to 1500. &amp;nbsp;So&amp;nbsp;rather than heed all advice I've ever read/seen here I assumed that if mis-matched MTUs&amp;nbsp;worked for the ClusterA-ClusterB peering it should work for ClusterA-ClusterC. &amp;nbsp;So I only changed ClusterC's broadcast domain and ports to run at MTU 1500. &amp;nbsp;NO GO. &amp;nbsp;When I changed my new broadcast domain on ClusterA and associated ports to 1500 the peering worked.&lt;/P&gt;</description>
    <pubDate>Wed, 16 Aug 2017 17:49:19 GMT</pubDate>
    <dc:creator>nicholsongc</dc:creator>
    <dc:date>2017-08-16T17:49:19Z</dc:date>
    <item>
      <title>Cluster Peer Unavailable - Data and ICMP Reachable</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Cluster-Peer-Unavailable-Data-and-ICMP-Reachable/m-p/133258#M29112</link>
      <description>&lt;P&gt;Attempting to peer two clusters (Cluster #1 and Cluster #2) but cannot get past &lt;STRONG&gt;Availability = Unavailable&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Cluster #1&amp;nbsp;&lt;/STRONG&gt;is a six (6)-node cluster&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Cluster #2&amp;nbsp;&lt;/STRONG&gt;&lt;SPAN&gt;is a two (2)-node cluster&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Tried peering with and without authentication - current peering has &lt;STRONG&gt;Authentication - OK&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Both &lt;STRONG&gt;Data&lt;/STRONG&gt; and &lt;STRONG&gt;ICMP Ping&lt;/STRONG&gt; status are &lt;STRONG&gt;session_reachable&lt;/STRONG&gt; and &lt;STRONG&gt;interface_reachable&lt;/STRONG&gt; respectively on both sides of the peering&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;All ports involved/recognized have the same MTU (9000)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Cluster #1 is currently successfully peered and the source to a 3rd-party provider for DR (SnapMirror)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Cluster #1 displays both nodes for &lt;SPAN&gt;Cluster #2&lt;/SPAN&gt; for &lt;STRONG&gt;Remote Cluster Nodes&lt;/STRONG&gt;&amp;nbsp;- output of&amp;nbsp;&lt;STRONG&gt;cluster peer show -instance&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Cluster #2 only shows Cluster #1's node1 (of six) in &lt;SPAN&gt;for&amp;nbsp;&lt;/SPAN&gt;&lt;STRONG&gt;Remote Cluster Nodes&lt;/STRONG&gt;&lt;SPAN&gt;&amp;nbsp;- output&amp;nbsp;of&amp;nbsp;&lt;/SPAN&gt;&lt;STRONG&gt;cluster peer show -instance&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Cluster #2&lt;/STRONG&gt; DOES, however, show all six IP addresses for each node of&lt;STRONG&gt; Cluster #1 &lt;/STRONG&gt;for&lt;STRONG&gt; Active IP Addresses&lt;SPAN&gt;&amp;nbsp;- &lt;/SPAN&gt;&lt;/STRONG&gt;output&amp;nbsp;of&amp;nbsp;&lt;STRONG&gt;cluster peer show -instance&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 04 Jun 2025 14:46:47 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Cluster-Peer-Unavailable-Data-and-ICMP-Reachable/m-p/133258#M29112</guid>
      <dc:creator>nicholsongc</dc:creator>
      <dc:date>2025-06-04T14:46:47Z</dc:date>
    </item>
    <item>
      <title>Re: Cluster Peer Unavailable - Data and ICMP Reachable</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Cluster-Peer-Unavailable-Data-and-ICMP-Reachable/m-p/133662#M29221</link>
      <description>&lt;P&gt;So the solution to my problem here was two-fold:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;1. Existing Peer relationship between our production ClusterA and our DR provider's ClusterB was configured using ClusterA's DEFAULT IPSpace. &amp;nbsp;On the advice of NetApp support I created a separate (dedicated) IPSpace for ClusterA to talk to ClusterC. &amp;nbsp;This means I had to create a new/dedicated IPSpace as well and add a route.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;2. MTU sizes. &amp;nbsp;My downfall here was that my Intercluster LIFs on ClusterA and associated Broadcast domain is set to 9000. &amp;nbsp;However, I confirmed with our DR provider that the ports/broadcast domain at their end is set to 1500. &amp;nbsp;So&amp;nbsp;rather than heed all advice I've ever read/seen here I assumed that if mis-matched MTUs&amp;nbsp;worked for the ClusterA-ClusterB peering it should work for ClusterA-ClusterC. &amp;nbsp;So I only changed ClusterC's broadcast domain and ports to run at MTU 1500. &amp;nbsp;NO GO. &amp;nbsp;When I changed my new broadcast domain on ClusterA and associated ports to 1500 the peering worked.&lt;/P&gt;</description>
      <pubDate>Wed, 16 Aug 2017 17:49:19 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Cluster-Peer-Unavailable-Data-and-ICMP-Reachable/m-p/133662#M29221</guid>
      <dc:creator>nicholsongc</dc:creator>
      <dc:date>2017-08-16T17:49:19Z</dc:date>
    </item>
  </channel>
</rss>

