Troubleshooting guide for rlink connections

Article:TECH10288  |  Created: 2002-01-08  |  Updated: 2002-01-08  |  Article URL http://www.symantec.com/docs/TECH10288
Article Type
Technical Solution

Environment

Issue



Troubleshooting guide for rlink connections

Solution



There are many reasons why rlinks may not connect.
Below is a checklist that can be used to help troubleshoot rlinks that are not connecting.
Some of the signs that there is a problem are:

- rlinks timeout when trying to attach
- rlinks stay in the ENABLED/ACTIVE state when both rlinks are attached
- the secondary rlink becomes PAUSED after the primary rlink is attached.

1. Validate VERITAS Volume Replicator (VVR) license and license utilities:
This will show up when VxVM does not allow replicator volume groups (RVG) and rlink objects to be created. If this is a problem, the host_infod and vxnetd daemons will not be started automatically. Please see the Network and Process Checks section below for dealing with problems with the daemons.

1.0. Verify the correct licenses and install them by using the vxlicense utility (ie. vxlicense -c).

NOTE: Each node needs at least one VVR and one VxVM license.
   
# vxlicense -p

1.1. Verify the correct version of the vxlicense utility.
     
Older versions of the utility do not support the VVR product name and therefore will not report a valid license for it (VVR used to be named SRVM).  To verify the vxlicense is the correct version,  the following commands should show a valid VVR license.

# vxlicense -t VVR
# vxlicense -t vvr
# vxlicense -t SRVM

# vxlicense -t srvm
# vxdctl license

1.2  Network and Process and OS Checks:

Besides the specific problems addressed below,  general problems with the network will also affect VVR. Be aware of high latency, low bandwidth, high collision counts, and a high percentage of dropped packets.

2.0. Run vxprint -l on the primary and secondary rlinks.

2.1. Check the communication between the primary and secondary nodes via the replication path.

To do this, ping from primary to secondary and secondary to primary using remote_host and IP_addr fields in the rlinks.

NOTE: There should very minimal packet loss,  if any at all.

On Solaris: ping -s
On HP-UX: ping


2.2. Confirm that the network can handle large packets using the ping command (The packet loss should be similar to that of #1).

On Solaris: ping -I 2 8192
On HP-UX: ping 8192

2.3. Check whether host_infod is running,  using the ps command.

If it is not running, start it using the following script: /etc/init.d/vxnm-host_infod.

2.4. Ensure that netd process is running by typing the following: /usr/sbin/vxnetd.

2.5. Check whether the I/O daemons are started,  using vxiod. (This displays the number of daemons currently running. If the number is 0, then run vxiod set 10.)

2.6. Use pkginfo -l VRTSvxvm\*  to make sure the VRTSvxvm package versions are the same on the primary and secondary nodes.

2.7  VVR 3.2 supports interoperability between different versions of Solaris, and 32 and 64-bit modes. If running earlier versions of VVR, use the uname -a command to make sure both primary and secondary nodes are running the same versions of Solaris and use the isainfo -kv command to make sure they are running in the same mode.

2.8. Check that there is a user datagram protocol (UDP) port open on primary and secondary nodes for the well known ports found above.

To do this, run the following command on each node and look for the specified output:

# netstat -an
UDP
Local Address Remote Address State  
-------------------- ----------------------  -------
*.<port-number>                       Idle


3. Configuration checks for rlinks:

Some of the following conditions are checked by VVR while running the vxrlink att command, so make sure errors are not coming up while attaching rlinks. The attributes listed below will come up when using the vxprint command. If the VRAS (vradmin) commands are being used to create the configuration, it is most likely that you will not run into any of the following. It is a good idea to check it anyway.

# vxprint -l


3.0. Check Primary remote_rlink == Secondary rlink Name
3.1. Check Secondary remote_rlink == Primary rlink Name
3.2. Check Primary remote_dg == Secondary dg
3.3. Check Secondary remote_dg = Primary dg
3.4. Check Primary local_host == Secondary remote_host (same IP)
3.5. Check Secondary local_host == Primary remote_host (same IP)
3.6. Check Primary remote_host IP is indeed IP of Secondary host.
3.7. Check Secondary remote_host IP is indeed IP of Primary host.
      (Do the last 2 checks especially in cluster environment. Cluster manager may have changed Primary or Secondary nodenames).
3.8. If Primary rlink is in ENABLED state, Primary remote_dg_dgid == Secondary dgid (vxprint -l Secondary dg)
      (On Secondary remote_dg_dgid will not have any value which is OK)
3.9. If Primary rlink is in ENABLED State, Check Primary remote_rlink_rid == Secondary (rlink) rid (On Secondary remote_rlink_rid is 0.0 which is OK)
3.10. Verify that the Well Known Port on Primary is correct, check port displayed for local_host is the same as listed in /etc/vx/sr_port on Primary.
3.11. Verify that the Well Known Port on Secondary is correct, confirm port number displayed for local_host is same as port number for Primary remote_host.
        Confirm this port matches the value in /etc/vx/sr_port on Secondary.


4. Configuration checks for volume mappings:

NOTE: Volume mapping errors are obvious since these errors are displayed while attaching primary rlinks.

4.0. If the same volume names are being used on the primary and secondary (which is always recommended), make sure there is a corresponding secondary volume associated with secondary RVG for each volume associated with the primary RVG.
4.1. Make sure the size of each secondary volume is the same as the size of the corresponding primary volume. (A secondary volume can be of larger size than the     primary volume, but it is recommended that the primary and secondary volumes have the same size). If a secondary data volume is smaller than its corresponding primary data volume then the secondary rlink will be paused.
4.2. In case different volume names are being used on the primary and secondary host, check that the primary_datavol attribute of each secondary data volume is set to the corresponding primary data volume name. Also check the size of  the primary and secondary data volumes as explained above. If your configuration is such that the names of your data volumes on the primary and secondary are different you should also set the primary_datavol attribute for the primary data volumes. This will allow primary migration without the surprise that the rlinks will not connect once the roles have been switched.

5.0 Setting "local-mac-address?=true" in eeprom sometimes seems to get rlinks to connect properly.

6.Contact VERITAS Customer Support by phone at 1800-642-0652 or by email at support@veritas.com

NOTE: The technical support engineer may request vxexplorer outputs from the primary and secondary hosts.



Legacy ID



235388


Article URL http://www.symantec.com/docs/TECH10288


Terms of use for this information are found in Legal Notices