General problems like high latency, low-bandwidth, high collisions counts, and a high percentage of dropped packets also affects Volume Replicator.
Specific issues with networks are as follows:
Check the status of communication between the Primary and Secondary nodes by using the replication path. To do this ping from Primary to Secondary and Secondary to Primary using remote_host fields in the RLINKs. There should be very minimal packet loss, if any.
Run: ping <remote_host>Run: ping <remote_host_ip_address>
Confirm whether the network can handle large packets using the ping command. The packet loss should be similar to that mentioned in the preceding point. In the ping command, specify packet_size value that the vxprint -l <rlink-name> command displays.
Run: ping -l <packet_size> <remote_host> Run: ping -l <packet_size> <remote_ip_address>
Check whether the connection server is started or not. You can confirm this, by checking the system event log. You should see an entry similar to the one given below:
Connection Server started successfully (using port 6ae).
If you do not see this entry, make sure that vxsvc service for the Veritas Enterprise Administration (VEA) is started. If it is not started then start the service, and check the log again.
In the system event log, you may see entries similar to Connection Server already started. These messages do not indicate any problems.
Run the following command on each node to make sure that the Volume Replicator connection server uses the port that is mentioned in the vrport heartbeat command.
netstat -an | findstr <port-number mentioned in vrportheartbeat' output>
The default port number is 4145. Check the output of the vrport command.
More Information