Symptoms:

A user may want to access VRAs to perform network testing or troubleshooting.  For this reason, in 7.0 a SSH key is being provided for users who wish to be able to access the VRA.

Cause:

A user may require VRA access to perform network troubleshooting between the source and target VRAs or from the VRA to the ZVM VM.

Solution:

Starting in version 7.0, Zerto has enabled VRA user access using "Plink" to run commands on the VRA virtual machine for troubleshooting purposes.  Plink is a command-line connection tool that comes with the PuTTY suite and exists in the Zerto Virtual Replication installation folder.  For Plink to be run on a VRA, an SSH key file must first be loaded.

Within the Zerto Virtual Replication installation folder, an SSH key file named " ssh.ppk" can be found inside a folder named "Secrets". Please note that only a user account with Administrative access on the ZVM server can access the "Secrets" folder. 

To use Plink, please open a Windows CMD prompt in the Zerto Virtual Replication installation folder and then run your desired command using the following syntax: 

  • plink -i <path to key file> <user>@<VRA IP address> “<command>”

Here are some common connectivity troubleshooting plink commands: 

Ping'ing a Peer VRA/ZCC: 

  • plink -i Secrets/ssh.ppk root@<VRA IP address> “ping -c 20 <Peer VRA/ZCC Address>”

If packet loss is present, then seeing a 'site disconnection' error is expected in the Zerto Virtual Manager GUI. 

Telnet to a Peer VRA/ZCC: 

  • plink -i Secrets/ssh.ppk root@<VRA IP address> “timeout 3 telnet <Peer VRA/ZCC Address> <port>”
  • NOTE: VRAs communicate over ports 4007 and 4008 so telnets on both ports should be checked. 
  • NOTE: VRAs are sending outgoing communication to the ZCC over ports 9082 and higher (2 ports for each VRA) - to view the ZCC's port forwarding rules, connect to the ZCC (following the KB article "Connecting to a ZCC via SSH and performing connectivity troubleshooting steps") and use the following command:

    a. Type: iptables-save > iptables.txt

    b. Type: less iptables.txt
     

Now that you have the mapping table of ports through which the ZCC is communicating with each VRA, you can start testing Telnet from VRAs on the cloud's/tenant's site to the ZCC on the relevant ports.
If one of the above ports is blocked, then seeing a site disconnection error in the Zerto Virtual Replication GUI is expected.

Pinging VRAs while checking the current MTU value: 

First, run an "ifconfig" command in the VRA interface to find the current outgoing MTU value: 

  • plink -i Secret/ssh.ppk root@<VRA IP address> “ifconfig”

User-added image 

Decrease the MTU value by 28 (ICMP header) and use the new MTU value to ping the peer site VRA. 

In our example the original MTU is set to 1500, so we would want to ping with a value of 1472: 

  • plink -i Secrets/ssh.ppk root@<VRA IP address> “ping -c 10 -M do -s 1472 <Peer VRA/ZCC Address>”

If the ping responds, as usual, the MTU does not have to be modified. 

 If the packet is too large however, (Most common error messages will be either “Packet needs to be fragmented but DF set.” Or “Message too long, mtu=xxxx”) then you will need to modify the current MTU value. 

To modify the MTU on the VRA, continue running the MTU pings with lower packet values until you find a value which does not fragment. Once the correct MTU value is found, you would want to increase the value by 28 (ICMP header). For example, ping with an MTU value of 1464 that has passed without fragmentation would require an increase of 28 bytes i.e. would require configuring the NIC with an MTU value of 1492 (1464 + 28). 

Once we have the new MTU value, please use the following command while replacing the xxxx with your desired MTU value: 

  • plink -i Secrets/ssh.ppk root@<VRA IP address> “sed -i -r 's/mtu [0-9]{4}/mtu xxxx/' /etc/network/interfaces”

After setting the new MTU, please run the following command to restart the networking services of the VRA for the changes to be applied: 

  • plink -i Secrets/ssh.ppk root@<VRA IP address> “/etc/init.d/networking reload”

Please run "ifconfig" again to verify that the new MTU is present. 

If the MTU issue cannot be diagnosed, please open a support ticket with your findings from the steps described above. 

NOTE: The VRA upgrade re-deploys the OS of the VRA, and changes such as MTU values or static routes will thus be removed. 

Affected Versions:

7.0 +

Hypervisor:

VMware, Hyper-V.