### Human: Can you tell about NCC Health Check: remote_site_config_check. ### Assistant: NCC 3.5.0. The NCC health check remote_site_config_check verifies the mapping configuration of a remote site and a vStore (container).. The NCC health check remote_site_config_check verifies the mapping configuration of a remote site and a vStore (container).

This health check uses the data from the cluster configuration to check if the local site configuration matches the remote site configuration:

The check looks for the Controller VM (CVM) IP addresses of the local site on the cluster configuration of the remote site. (A process within the cluster maintains the Controller VM IP addresses.)NCC then checks the parameters of the cluster configuration and examines how they are configured on both sites.
	The number of vStores provided in the mapping is the same for the source and the remote site.The specified vStores are available on the remote site. This is checked on both the local and the remote sites.The vStore mapping is correct on the local and the remote sites.The network mapping exists on the local and remote sites. (Included in NCC 3.6)NCC checks "remote_site_config_check" does not do a network mapping check in NCC 3.6.3 and later versions.
	

Note: If any of the above checks fail, NCC returns a FAIL status for the entire check.

Running the NCC check

You can run this check as part of the complete NCC health check as follows:

nutanix@cvm$ ncc health_checks run_all

You can also run this check individually by using the following command.

nutanix@cvm$ ncc health_checks run_all

You can also run the checks from the Prism web console Health page: select Actions > Run Checks. Select All checks and click Run.

This check is scheduled to run every 3 hours, by default.

This check does not generate an alert.

Output messaging

Check ID110006DescriptionCheck remote site configuration on local and remote sitesCauses of failureRemote site is not properly configured.ResolutionsReview KB 3335.ImpactNutanix snapshot replication might fail to the remote site.. NCC check remote_site_config_check returns INFO for protection domains without remote container mappings.

If the NCC check completes and returns an INFO for protection domains configured for local backups (no replication), this check result can be ignored. These protection domains usually do not have a remote site listed.If replication is desired and there is a remote site configured, check the container or vStore mapping on both sites to ensure there is a 1:1 relationship. You can do the following:
	Create a valid vStore mapping on the remote site configuration of the source cluster and on the remote cluster. A vStore mapping maps a container on the source cluster with a container on the destination cluster. See the Prism Web Console Guide for more information.
	

If the NCC check remote_site_config_check returns a FAIL, run the following commands to review the configuration on the remote site.

nutanix@cvm$ ncli pd ls name=ProtectionDomainName

Replace ProtectionDomainName with the name of the protection domain.

nutanix@cvm$ ncli pd ls name=ProtectionDomainName

Replace RemoteSiteName with the name of the remote site.

Run this command on the remote site and compare the output - mainly the Capabilities and the VStore Map

Note:

The data obtained from the output of these commands are useful in identifying configuration issues and troubleshooting the failure.If the protection domain name or the remote site name is not specified in the above commands, data for all the protection domains or the remote sites configured is displayed.Modifying this vStore mapping information will cause a full replication to take place.The Test Connection option seen on the Data Protection page checks network connectivity and required ports for communication. It does not check for VStore or container mappings.

To list all the remote sites and vStore mappings, run the following command.

nutanix@cvm$ ncli pd ls name=ProtectionDomainName

Sample output:


	If the number of vStore mappings does not match on both sites, you will see a message similar to the following:

	nutanix@cvm$ ncli pd ls name=ProtectionDomainName

	Review the vStore mappings on both sites, and ensure that the number of vStores match.
	
	If the vStore mapping is incorrect on either site, a message similar to the following is displayed:

	nutanix@cvm$ ncli pd ls name=ProtectionDomainName

	Review the mapping. It should be mapped in the right order.

	Example: Site A if you have Container Mapping set to Container_A: Container_B on Site B the mapping should be Container_B: Container_A
	
	On the remote site, for the corresponding site pair, if the network mapping is missing under remote configuration, a message similar to the following will be displayed:

	nutanix@cvm$ ncli pd ls name=ProtectionDomainName

	Review the configuration on the remote site listed in the failure and update the networking configuration.
	
	If Site B is configured as the remote site on Site A, but on Site B, the remote site configuration is missing, a message similar to the below is seen:

	nutanix@cvm$ ncli pd ls name=ProtectionDomainName

	This check only checks the remote site configuration. This check does not check for connectivity. To check connectivity between the sites, review KB 1596: NCC Health Check: remote_site_connectivity_check

	Review the remote site configuration on both sites to ensure that the remote sites have been configured.

	Example: Site A should have Site B as its remote site. Similarly, Site B should have Site A as its remote site.
	
	Prior to NCC 3.8: Number of vStores mapped for the local site on the remote site is not the same.

	In NCC versions prior to 3.8, this check may fail with a similar result as the output below.

	nutanix@cvm$ ncli pd ls name=ProtectionDomainName

	An issue was identified that triggered this alert if both names of the two clusters are changed. In this case, the "Entity Centric" entries are modified but a Legacy entry still remains. The legacy entry is there in case the cluster name changes. Since both EC and non-EC entries share the same IP and uuid, the workflow of the check compares a non-EC remote site object with EC remote site object configured on target. Since no check for remote site type is present here, the check fails. You can confirm by checking that the name of the remote site is shown as: remote_<ip>_<uuid>. If you see this entry, upgrade NCC to version 3.8 or later and this check should pass.
	
	If the DR network segmentation is enabled on Site A but not added in the remote site B 

	nutanix@cvm$ ncli pd ls name=ProtectionDomainName
	This check might fail on the source site if the remote site has multiple remote sites added to it, you can confirm this by listing the remote sites on the remote cluster using "ncli remote-site ls" or via Prism and going to Data Protection > Remote Site and reviewing the sites added. this failure in the check should be addressed in a future NCC release

You can update the configuration or the mappings by modifying the remote site configuration through the Prism web console.

To correct the mapping/configuration, do the following:

Log on to the Prism web console and go to the Data Protection page.Select the Table view.On the Remote Site tab, select the remote site, and then click Update.Correct the mapping.

In case the above mentioned steps do not resolve the issue, consider engaging Nutanix Support at https://portal.nutanix.com/

Gather the output of the below command and attach it to the support case:

nutanix@cvm$ ncli pd ls name=ProtectionDomainName. ### 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.