Skip to main content
NetApp Knowledge Base

How to create and configure Cluster Peering with designated InterCluster LIFs using IPSpaces

  1. Last updated
  2. Save as PDF
Views:
17,947
Visibility:
Public
Votes:
8
Category:
snapmirror
Specialty:
dp
Last Updated:

​

​

Applies to

  • NetApp ONTAP 9
  • Cluster peering
  • IPspaces
  • Intercluster LIFs
  • SnapMirror

Description

  • Use IPspaces to control which intercluster LIFs participate in a cluster peer relationship when clusters use different networks
  • In clustered Data ONTAP 8.3.1 and later, the full-mesh connectivity requirement is scoped to the intercluster LIFs in the IPspace used by that peer relationship
  • If intercluster LIFs for separate peer networks remain in the same IPspace, new peer creation can fail and existing or new SnapMirror transfers can report Cluster Session Manager (CSM) or remote system errors
  • Within one IPspace, ONTAP still expects all intercluster LIFs that belong to that IPspace to have connectivity to the peer cluster

Procedure

  1. Confirm that the cluster uses more than one intercluster network and that the peer relationships should remain isolated by IPspace
  2. Review the example below to understand why additional intercluster LIFs in the Default IPspace can violate the full-mesh requirement
Example scenario without custom IPSpaces
  • An existing cluster peer relationship exists between Cluster A and Cluster B
  • All intercluster LIFs are in the Default IPspace and use the same network path

Example of an existing cluster peer relationship between Cluster A and Cluster B

  • Cluster C is introduced on a different, non-routable network and requires a cluster peer relationship with Cluster A
  • Cluster A needs additional intercluster LIFs for that new network

Example of Cluster C requiring new intercluster LIFs on Cluster A

  • If the new intercluster LIFs remain in the Default IPspace and cannot reach Cluster B, the configuration violates the full-mesh requirement for that IPspace
  • Typical symptoms include failed cluster peer create operations, unhealthy peer status, or SnapMirror failures that report CSM or RPC: Remote system error
  • Within one IPspace, ONTAP does not let you pin specific intercluster LIFs to specific peer clusters

Connectivity expected when all intercluster LIFs remain in the Default IPspace

Using IPSpaces to segment cluster peer relationships
  1. Create a new IPspace for the peer relationship that uses the separate network
    ::> network ipspace create -ipspace <new_ipspace>
  2. Create a broadcast domain in the new IPspace
    ::> network port broadcast-domain create -broadcast-domain <new_bcast_domain> -mtu <mtu> -ipspace <new_ipspace>
  3. Move dedicated physical or VLAN ports into the new broadcast domain. Remove hosted LIFs first if required
    ::> network port broadcast-domain remove-ports -broadcast-domain <old_bcast_domain> -ports <node:port>
    ::> network port broadcast-domain add-ports -broadcast-domain <new_bcast_domain> -ports <node:port> -ipspace <new_ipspace>
  4. Create at least one intercluster LIF per node in the new IPspace and use ports that belong to that IPspace
    ::> network interface create -vserver <new_IPSpace> -service-policy default-intercluster -address <IP> -netmask <mask> -home-port <port> -home-node <node>
  5. Create routes for the new IPspace if the peer network requires them
    ::> network route create -vserver <new_IPSpace> -destination <IP/Mask> -gateway <gateway> -metric <metric>
  6. Create a new cluster peer or modify the existing cluster peer to use the new IPspace
    ::> cluster peer create -peer-addrs <peer_IC_LIFs> -ipspace <new_IPSpace>
    ::> cluster peer modify -cluster <peer_cluster_name> -ipspace <new_IPSpace>
  7. Verify that the peer relationship is healthy and that transfers complete successfully
  • Use dedicated ports for each additional IPspace
  • Use more than one eligible port per node so failover targets remain available
  • Remember that the full-mesh requirement still applies within each IPspace

Additional Information

Internal Notes

internalNotes_text

Sign in to view the entire content of this KB article.

New to NetApp?

Learn more about our award-winning Support

NetApp provides no representations or warranties regarding the accuracy or reliability or serviceability of any information or recommendations provided in this publication or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a customer's responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.