NetApp - ONTAP LIF resynchronisation procedure
NetApp Solution · Config document · referenced from Troubleshooting
The procedure used when metrocluster check show reports lifs warning: find the LIF that the partner cluster cannot place, verify the network on both clusters, repair the placement and replicate the SVM configuration again.
| Item | Value |
|---|---|
| Shown here for | Site 2, SVM DC2-S-VCVSM005 with LIF DC2-S-VCVSM005_nfs_lif1, on 5 June 2019 |
| Runs on | DC2-A-XNAS001, the cluster that owns the SVM |
| Also applies to | Any SVM of either site, with its own names |
| Applied with | SSH to the cluster management address |
| ONTAP version at the time | Not recorded in the notes |
The command set
# --- Before anything else, outside this command set ------------------------- # On the network switches of both datacenters: MTU 9000 and the correct # VLANs on all ports where the NetApp nodes are connected. # On both clusters: the same network interfaces, Ethernet ports, broadcast # domains and IPspaces. # --- Find the failing check; on DC2-A-XNAS001 ------------------------------- # Expected ok for all five components; here "lifs" showed "warning" metrocluster check run metrocluster check show # One line per LIF and check; look for a result other than ok. # Here: DC2-B-XNAS001, DC2-S-VCVSM005-mc, port-selection, warning metrocluster check lif show # Details for that LIF. The field "Additional Information/Recovery Steps" # said: Discovery of LIF with address 10.12.40.30 failed from destination # cluster. Ensure that the destination cluster has ports that have # connectivity to the LIF on the source cluster. metrocluster check lif show -instance -lif DC2-S-VCVSM005_nfs_lif1 # --- Verify the network on the source cluster ------------------------------- # Placement of the LIF: node, port, home network interface show # The expected VLAN port must exist on both nodes, in the right IPspace and # broadcast domain, link up, MTU 9000, healthy network port show # --- Repair ----------------------------------------------------------------- # Repair the LIF placement for the sync-source SVM in the destination cluster # metrocluster check lif repair-placement -vserver <vserver_name> -lif <lif_name> metrocluster check lif repair-placement -vserver DC2-S-VCVSM005 -lif DC2-S-VCVSM005_nfs_lif1 # Resynchronise the SVM with its partner SVM # metrocluster vserver resync -cluster <source_cluster> -vserver <vserver_name> metrocluster vserver resync -cluster DC2-A-XNAS001 -vserver DC2-S-VCVSM005 metrocluster vserver resync -cluster DC2-A-XNAS001 -vserver DC2-S-VCVSM005-mc # --- Verify ----------------------------------------------------------------- # No recovery step left for the LIF on either cluster metrocluster check lif show -instance -lif DC2-S-VCVSM005_nfs_lif1 # port-selection ok for the LIF on DC2-B-XNAS001 metrocluster check lif show
The second resync, with the name of the -mc copy and the source cluster A, is in the notes as run; they do not record its output, and the copy lives on cluster B. The same metrocluster vserver resync was used at site 1 against the event vldb.aggrBladeID.missing, followed there by metrocluster vserver show.
The two vendor articles the notes refer to are "Discovery of LIF with address (IP_Address) fails from the destination cluster" and "How to troubleshoot MetroCluster check LIF errors".
Checked against ONTAP 9.19.1
| As built | Today |
|---|---|
metrocluster check run, metrocluster check show, metrocluster check lif show | All still have pages in the command reference |
metrocluster check lif repair-placement -vserver <vserver> -lif <lif> | Still has a page in the command reference |
metrocluster vserver resync -cluster <cluster> -vserver <vserver> | Still has a page in the command reference |
The research confirmed that the commands exist in the 9.19.1 reference and did not compare their options or output with 9.3, so nothing more is claimed here. See metrocluster check lif repair-placement.