### Human: Can you tell about NCC Health Check: remote_site_latency_check. ### Assistant: This check was introduced in NCC 3.9.0 and validates the latency between primary and target clusters.. The NCC health check remote_site_latency_check checks if the latency to the target cluster is lesser than the maximum value (5ms) allowed for AHV Synchronous Replication.If the latency is higher than 5ms, synchronous replication may fail. This check provides a summary of the latency to the target cluster(s).Running the NCC CheckYou can run this check as part of the complete NCC health checks
ncc health_checks run_all
  Or you can run this check individually

ncc health_checks run_all
  This check is scheduled to run every 6 hours and only runs on Prism Central. An alert will get generated after failure. 

Sample outputFor Status: PASS

ncc health_checks run_all
  For Status: FAIL

ncc health_checks run_all
 

ncc health_checks run_all
   

Output messaging

Check ID110022DescriptionCheck if the latency to target cluster is lesser than the maximum value allowed for AHV Sync RepCause of failureTarget cluster is unreachable or the connection to target cluster is not goodResolutionEnsure that the target cluster is reachable and latency is below 5ms or choose another target clusterImpactSynchronous Replication will be affectedAlert IDA110022Alert TitleChecking if latency to target cluster is lesser than the maximum valueAlert MessageLatency to [remote site] is greater than 5ms. If the check reports a FAIL status in regards to latency being too high, verify the latency between the sites. This can be done by running the ping command bi-directionally: 
From CVM on source cluster to CVM on remote cluster

nutanix@cvm:~$ ping x.x.x.22

From CVM on remote cluster to CVM on source cluster

nutanix@cvm:~$ ping x.x.x.22

You can also run the tracepath command bi-directionally to try to isolate where in the network path the latency increases or drops:From CVM on source cluster to CVM on remote cluster

nutanix@cvm:~$ ping x.x.x.22

From CVM on remote cluster to CVM on source cluster

nutanix@cvm:~$ ping x.x.x.22

If latency is showing above 5ms when running the commands, ensure your network environment is stable (physical switches, cabling, and device configurations) and consult with your networking team to resolve the latency issues. If latency for this particular remote site cannot be reduced, please choose another target cluster.To verify if the latency issue is intermittent or persistent, you can review the /home/data/logs/sysstats/ping_remotes.INFO logs on each cluster. Output within the ping_remotes.INFO log will be similar to the following (the IP in the log will be the remote cluster VIP):


nutanix@cvm:~$ ping x.x.x.22

Review the log and see if you can find any patterns for high network latency observed every hour, and so on. If there is a pattern for high network latency, try to isolate what could be causing the latency spikes.  


If the check reports a FAIL status in regards to the latency not being found, this indicates that the connection to the remote site is unreachable. The remote site can become unreachable if the following occurs:
1. The remote cluster becomes unstable2. The remote PC VM becomes unstable3. The Availability Zone (AZ) gets disconnected
To verify if the issue is with the PC VM or the remote cluster (target cluster), you can review the ping_remotes.INFO log on the source cluster. If the issue is with the remote cluster, messages similar to the following will be displayed within the log:

nutanix@cvm:~$ ping x.x.x.22

If unreachable messages are seen in the log, please check on the status of the remote cluster and also verify that there are no connectivity issues with the remote cluster Virtual IP Address (VIP). The VIP can be viewed by logging into Prism Element on the remote cluster and clicking on the cluster name - this will display the 'Cluster Details' - verify that the IP listed for the 'Cluster Virtual IP Address' matches the IP address shown in the ping_remotes.INFO log of the source cluster. If there is a discrepancy with the IP addresses, consult with your network team to verify any recent networking changes. If the remote cluster VIP has recently changed, the Protection Policy for this remote cluster will need to be recreated. Steps for creating a Protection Policy can be found in the "Creating a Protection Policy" section of the Leap Administration Guide: https://portal.nutanix.com/#/page/docs/details?targetId=Xi-Leap-Admin-Guide:dra-protection-policy-create-t.html If the log is not showing unreachable messages, then the issue is either with connectivity to the PC VM or the AZ has become disconnected. You can check the connectivity to the PC VM by running the ping command. If the ping command is unsuccessful, verify that the PC VM is powered on and check to see if there have been any recent networking changes. If the ping command is successful, check the status of the Availability Zone. Log into both the source and remote PC to make sure the AZ is configured and showing with a status of reachable. You can access this information by typing "Availability Zones" into the search bar or by to the menu and selecting Administration > Availability Zones. Steps for creating an AZ can be found in the "Pairing Availability Zones" section of the Leap Administration Guide: https://portal.nutanix.com/#/page/docs/details?targetId=Xi-Leap-Admin-Guide:dra-az-pair-t.html 

In case the mentioned steps do not resolve the issue, consider engaging Nutanix Support at https://portal.nutanix.com/. Additionally, please gather the following command output from the Prism Central VM and attach it to the support case:

nutanix@cvm:~$ ping x.x.x.22. ### Human: Now explain this as a Nutanix support agent summarizing the answer step by step. In case, you don't know the answer say - I don't know.