NFS LIF Does Not Fail Over After Broadcast Domain Split
A four-node AFF A250 cluster runs ONTAP 9.14 and hosts 12 SVMs in the default IPspace. Finance requires isolation, so you create IPspace ips_fin, SVM svm_fin, subnet 10.20.10.0/24 and broadcast domain bd_fin. Data LIF lif_fin_01 is created on node1 port e0c-210 (VLAN 210, 10.20.10.11) and lif_fin_02 on node2 port e0c-210 (10.20.10.12), both offering NFS and CIFS. When bd_fin was created, only node1:e0c-210 was added; node2:e0c-210 still belongs to the broadcast domain Default. NFS clients mount 10.20.10.11 successfully. During an SFP replacement on node1, lif_fin_01 goes down and clients lose access for the full 25-minute window instead of failing over. network interface show -vserver svm_fin reports lif_fin_01 down and lif_fin_02 up, and network port show confirms node2:e0c-210 is up in VLAN 210.
1. Why did lif_fin_01 not fail over to node2? Give the commands that prove the cause, then the remediation in the correct order.
Read the worked answer
LIF failover targets are computed from broadcast domain membership inside the same IPspace: a data LIF can only fail over to a port that is in its own broadcast domain. lif_fin_01's candidate list contained only node1:e0c-210, so there was no target and the LIF simply went down. Prove it with network interface show -vserver svm_fin -lif lif_fin_01 -instance (look at Failover Targets) and network port broadcast-domain show -broadcast-domain bd_fin -ipspace ips_fin. Fix in this order: (1) network port broadcast-domain add-ports -broadcast-domain bd_fin -ports node2:e0c-210; (2) network interface modify -vserver svm_fin -lif lif_fin_01 -failover-policy broadcast-domain-wide, or set explicit -failover-target values; (3) re-check that targets now appear. Changing the failover policy first would not have helped while no eligible port existed. Also confirm both ports use the same VLAN and MTU, otherwise the target is listed but unusable.
2. The next maintenance is in two weeks. How do you prove failover works without an unplanned outage, and what determines whether NFS clients stall or recover?
Read the worked answer
Use a controlled move rather than pulling a cable: network interface migrate -vserver svm_fin -lif lif_fin_01 -dest-node node2 -dest-port e0c-210, confirm with network interface show -vserver svm_fin -lif lif_fin_01 -fields status-oper,curr-node,curr-port, run I/O from a client, then migrate the LIF back. A migrate is graceful and exercises the same target selection path as a real failover, so it is the safer pre-check. On the client side, NFSv4.x re-establishes state during the server grace period and usually recovers after a brief pause, while NFSv3 hard mounts retransmit and then continue; soft mounts can surface errors to the application immediately. That explains why the 25-minute event was a down LIF rather than slow failover: with no failover target, no server existed on the address for the clients to reconnect to.
3. The application team wants a second subnet, 10.21.10.0/24, on node3 and node4 for the same SVM. What must be created and what is commonly missed?
Read the worked answer
Ports belong to one broadcast domain each, and broadcast domains are scoped to an IPspace. Create VLAN ports if needed (network port vlan create), create bd_fin_21 in ips_fin, add node3:e0c-210 and node4:e0c-210, create the subnet with network subnet create bound to that broadcast domain, then create the data LIFs in svm_fin. Commonly missed items: clients on a routed network need an SVM route (network route create with the 10.21.10.1 gateway) and the gateway must exist in a subnet known to the SVM; DNS must return both addresses for the NFS name so clients can use both LIFs; and the switch trunk must carry the new VLAN. Verify with an actual mount from each subnet, plus network interface show, network route show and vserver services access-check rather than trusting the configuration alone.