Map ports from node1 to node3

Contributors Download PDF of this page

You need to make sure that the physical ports on node1 map correctly to the physical ports on node3, which will let node3 communicate with other nodes in the cluster and with the network after the upgrade.

Before you begin

You must already have information about the ports on the new nodes from the Hardware Universe. (Go to References to link to the Hardware Universe). You use the information later in this section and in Map ports from node2 to node4.

The software configuration of node3 must match the physical connectivity of node3, and IP connectivity must be restored before you continue with the upgrade.

About this task

Port settings might vary, depending on the model of the nodes.
You must make the original node’s port and LIF configuration compatible with what you plan the new node’s configuration to be. This is because the new node replays the same configuration when it boots, which means that when you boot node3, ONTAP will try to host LIFs on the same ports that were used on node1.

Therefore, if the physical ports on node1 do not map directly to the physical ports on node3, then software configuration changes will be required to restore cluster, management, and network connectivity after the boot. In addition, if the cluster ports on node1 do not directly map to the cluster ports on node3, node3 might not automatically rejoin quorum when it is rebooted until a software configuration change is made to host the cluster LIFs on the correct physical ports.

  1. Record all the node1 cabling information for node1, the ports, broadcast domains, and IPspaces, in the following table:

    LIF Node1 ports Node1 IPspaces Node1 broadcast domain Node3 ports Node3 ports Node3 broadcast domains

    Cluster 1

    Cluster 2

    Cluster 3

    Cluster 4

    Cluster 5

    Cluster 6

    Node management

    Cluster management

    Data 1

    Data 2

    Data 3

    Data 4


    Intercluster port

    Refer to Record node1 information for the steps to obtains this information.

  2. Record all the cabling information for node3, the ports, broadcast domains, and IPspaces in the previous table using the same procedure in Record node1 information.

  3. Follow these steps to verify if the setup is a two-node switchless cluster:

    1. Set the privilege level to advanced:

      cluster::> set -privilege advanced

    2. Verify if the setup is a two-node switchless cluster:

      network options switchless-cluster show

       cluster::*> network options switchless-cluster show
       Enable Switchless Cluster: false/true

      The value of this command must match the physical state of the system.

    3. Return to the administration privilege level:

       cluster::*> set -privilege admin
  4. Get node3 into quorum by performing the following steps:

    1. Boot node3. See Install and boot node3 to boot the node if you have not already done so.

    2. Verify that the new cluster ports are in the Cluster broadcast domain:

      network port show -node <node-name> -port <port-name> -fields broadcast-domain

      The following example shows that port "e0a" is in the "Cluster" domain on node3:

       cluster::> network port show -node node3 -port e0a -fields broadcast-domain
       node       port broadcast-domain
       ---------- ---- ----------------
       node3      e1a  Cluster
    3. Add the correct ports to the Cluster broadcast domain:

      network port modify -node <node-name> -port <port-name> -ipspace Cluster -mtu 9000

      This example adds Cluster port "e1b" on node3:

       network port modify -node node3 -port e1b -ipspace Cluster -mtu 9000
      Note For a MetroCluster configuration, you might not be able to change the broadcast domain of a port because it is associated with a port hosting the LIF of a sync-destination SVM and see errors similar to, but not restricted to the following message`:
      command failed: This operation is not permitted on a Vserver that is configured as the destination of a MetroCluster Vserver relationship.

      Enter the following command from the corresponding sync-source SVM on the remote site to reallocate the sync-destination LIF to an appropriate port:

      metrocluster vserver resync -vserver <Vserver-name>

    4. Migrate the cluster LIFs to the new ports, once for each LIF:

      network interface migrate -vserver Cluster -lif <LIF-name> -source-node <node3> -destination-node <node3> -destination-port <port-name>

    5. Modify the home port of the cluster LIFs:

      network interface modify -vserver Cluster -lif <LIF-name> –home-port <port-name>

    6. If the cluster ports are not in the Cluster broadcast-domain, add them:

      network port broadcast-domain add-ports -ipspace Cluster -broadcast-domain Cluster -ports <node:port>

    7. Remove the old ports from the Cluster broadcast domain:

      network port broadcast-domain remove-ports

      The following example removes port "e0d" on node3:

      network port broadcast-domain remove-ports -ipspace Cluster -broadcast-domain Cluster ‑ports <node3:e0d>
    8. Verify that node3 has rejoined quorum:

      cluster show -node <node3> -fields health

  5. Adjust the broadcast domains hosting your cluster LIFs and node-management and/or cluster-management LIFs. Ensure that each broadcast domain contains the correct ports. A port cannot be moved between broadcast domains if it is hosting or is home to a LIF, so you might need to migrate and modify the LIFs as follows:

    1. Display the home port of a LIF:

      network interface show -fields <home-node,home-port>

    2. Display the broadcast domain containing this port:

      network port broadcast-domain show -ports <node_name:port_name>

    3. Add or remove ports from broadcast domains:

      network port broadcast-domain add-ports

      network port broadcast-domain remove-ports

    4. Modify a LIF’s home port:

      network interface modify -vserver <Vserver-name> -lif <LIF-name> –home-port <port-name>

  6. Adjust the intercluster broadcast domains and migrate the intercluster LIFs, if necessary, using the same commands shown in Step 5.

  7. Adjust any other broadcast domains and migrate the data LIFs, if necessary, using the same commands shown in Step 5.

  8. If there were any ports on node1 that no longer exist on node3, follow these steps to delete them:

    1. Access the advanced privilege level on either node:

      set -privilege advanced

    2. Delete the ports:

      network port delete -node <node-name> -port <port-name>

    3. Return to the admin level:

      set -privilege admin

  9. Adjust all the LIF failover groups:

    network interface modify -failover-group <failover-group> -failover-policy <failover-policy>

    The following example sets the failover policy to "broadcast-domain-wide" and uses the ports in failover group "fg1" as failover targets for LIF "data1" on "node3":

    network interface modify -vserver node3 -lif data1 failover-policy broadcast-domainwide -failover-group fg1

    Go to References to link to the ONTAP 9 Network Management Guide or ONTAP 9 Commands: Manual Page Reference for more information.

  10. Verify the changes on node3:

    network port show -node node3