## 3.17.2  Setup and Initial Configuration Problems
This section outlines the analysis steps you need to take in case you face configuration problems during the initial HANA System Replication Setup.
The initial SAP HANA System Replication Setup steps are as follows:
- enabling the SAP HANA System Replication on the primary site with sr_enable
- registering the secondary system with sr_register
While there are no errors to be expected when you enable the primary site, the registration operation on the secondary site can fail due to various errors.
##  Note
If you are in the process of setting up HANA System Replication for the first time, please make sure you have met all the prerequisites and performed the necessary preparation steps, outlined in the SAP HANA Administration Guide .
Pay special attention to the following points:
- Are the primary and secondary sites architecturally identical?
- Are the network interface configurations identical on both sites? (refer to the SCN document SAP HANA Network Requirements for details).
- Are the ports needed for system replication open and reachable from the primary and the secondary site?
## Wrong Topology Information
Upon registering the secondary site, the following error is raised:
The root cause for those issues is usually a wrong topology information. In this case, the secondary site contained the following landscape definition in the nameserver.ini :
The worker property contained the hostname of the primary site, which was wrong. Therefore, the registration failed. The problem should disappear once the correct hosts are maintained in the master and worker (if any) properties. You need to check on both sites if the information maintained in the nameserver topology is consistent.
## Resyncing the Secondary: Persistence Compatibility Checks
If the primary and secondary systems are disconnected for any reason, they must be resynced. If the persistencies (that is, the data and log volume snapshots) of the primary and secondary are compatible, it is possible to achieve a resync with only a delta data shipment or a log shipment; in this case full data shipping is not necessary. Even if the data snapshots are not compatible, the system will automatically attempt a full data shipment ( Resync Optimization ). If necessary, a full data shipment can be triggered manually using the following command:
```
hdbnsutil -sr_register --force_full_replica
```
Trace messages related to persistence which indicate that this is necessary include the following:
- Secondary persistence is not compatible with primary persistence.
- The persistence of at least one service is not initialized correctly.
## Communication Problems with the Primary Site
The sr_register command on the secondary site is failing with:
```
 Output Code > hdbnsutil -sr_register --name=<logical_site_name> --remoteHost=<primary_host --remoteInstance=<primary_instance_no> --mode=<replication_mode> --force_full_replica --sapcontrol=1 unable to contact primary site host <primary_host>:3xx02. connection refused,location=<primary_host>:3xx02
```
## Possible Root Cause 1: Ports Not Open / Blocked by Firewall
This error usually indicates a general communication problem between the primary and secondary site. Mostly, this is caused by the primary host not listening on the required ports for various reasons. You can check whether the required ports 3&lt;instance_number>=01 and 3&lt;instance_number>=02 (non-MDC scenarios) or 4&lt;instance_number>=02 (MDC scenarios) are listening on the required interfaces with the following command on OS level as privileged user (for example, root):
```
>netstat -apn | grep 3<instance_no>02 >netstat -apn | grep 4<instance_no>02
```
If you see that these ports are open and listening on the localhost interface only, you will not be able to reach them from the secondary site. You need to adjust the settings for listeninterface in the global.ini file from .local to .global :
```
 Sample Code [communication] listeninterface=.global
```
With this setting, the following interface:port pairs should be visible in netstat:
##  Note
If the ports are open, check whether they are not filtered by your firewall. Often it is not sufficient to check the connectivity to remote hosts via ping, because ping uses the ICMP protocol for communication. You can easily verify the accessibility of remote hosts by issuing a telnet call. For example:
```
>telnet <primary_host> 30001 >telnet <primary_host> 30102
```
## Possible Root Cause 2: SSL-Related Problems
Another cause for this error could be a wrongly implemented SSL configuration.
##  Note
If you do not secure the HANA network with SSL, do not implement any parameter changes related to SSL.
This can be revealed by activated corresponding traces on the primary site via SAP HANA cockpit:
- Database Explorer Trace Configuration Database Trace Search for 'sr_nameserver' Change from INFO to DEBUG OK
- Database Explorer Trace Configuration Database Trace Search for 'trexnet' Change from ERROR to INFO OK
Alternatively, the traces can be activated in the SQL console by issuing the following statements as a SYSTEM user:
```
 Source Code alter system alter configuration ('indexserver.ini','SYSTEM') SET ('trace','sr_nameserver')='debug' with reconfigure; alter system alter configuration ('indexserver.ini','SYSTEM') SET ('trace','trexnet')='info' with reconfigure;
```
After the trace activation, the registration problem needs to be reproduced by re-running the sr_register command on the secondary. The nameserver trace on the primary site would reveal the following errors in the CommonCrypto Engine:
```
0xa060023c | SSL | ssl3_accept Version in SSLPlaintext.version field of currently received record differs from the one negotiated in the current or currently accomplished handshake. 0xa060023c | SSL | ssl3_get_record Version in SSLPlaintext.version field of currently received record differs from the one negotiated in the current or currently accomplished handshake. (ErrCode: 536871970)
```
Make sure the following parameters are consistent on both sites in the configuration file global.ini :
```
 Sample Code [communication] ssl = systempki .. ... [system_replication_communication] enable_ssl = on
```
You need to ensure that the SSFS key and data files are stored on both sites. The following files must exist on both sites:
```
$DIR_INSTANCE/../global/security/rsecssfs/data/SSFS_<SID>.DAT $DIR_INSTANCE/../global/security/rsecssfs/data/SSFS_<SID>.KEY
```
## Possible Root Cause 3: Wrong Configuration of the Internal Hostname Resolution Parameters
Please check whether the internal hostname resolution information is consistent on both sites. The following how-to guides are a good source of information:
- SAP HANA Network Requirements
- How to Perform System Replication for SAP HANA .
## Possible Root-Cause 4: Wrong MTU Size Configured
A closer look at the nameserver trace file on the secondary site would reveal:
```
 Output Code error: unable to contact primary site; to <primary_host_ip> (<primary_host>):3xx01; original error: timeout occured,location=<primary_host_ip> :3xx02. Was MTU size set to 1500?
```
This problem is discussed in full detail in SAP Note 2166157 - Error: 'failed to open channel ! reason: connection refused' when setting up Disaster Recovery . See also SAP Note 2142892 - SAP HANA System Replication sr_register hangs at "collecting information"
## Possible Root Cause 5: HANA Service Unavailability
Check the availability of the indexserver / nameserver process on the primary site. Often the services faced an intermittent restart, crash or reconfiguration which did not go unrecognized by the secondary site.
## Related Information
```
SAP HANA Administration Guide Configure Tracing in the SAP HANA Database Explorer How to Perform System Replication for SAP HANA SAP HANA Network Requirements SAP Note 2166157 SAP Note 2142892
```