VBR Discovery failed: Not a valid network mask.

[mkevenaar]

Hi,

Support case #04011553

I am sharing this hoping this can help others as well.

Setup:
VBR v10 server
CentOS 7 VM with VAL v4
VPN connection between VAL server and router using OpenVPN v 2.4.8 (latest available version)
Same ZeroTier network on both VBR and VAL servers. (for more info: https://www.zerotier.com/)
CentOS 7 fully patched.

Primary the CentOS server will backup over the OpenVPN connection, but if that failed it is capable to backup over the ZeroTier network, which is much slower.

The Agent Discovery failed with the following message

Code: Select all

Cannot connect to my.server.fqdn Details: Not a valid network mask.

If you open the log file located in the C:\ProgramData\Veeam\Backup\Rescan\Rescan_of_my.server.fqdn folder you will find the following message:

Code: Select all

[18.02.2020 18:42:44] <01> Info     [my.server.fqdn] Creating temporary directory '/opt/veeam/'
[18.02.2020 18:42:44] <01> Info     [SshEpInvoker] Executing command 'mkdir -p /opt/veeam/'
[18.02.2020 18:42:45] <01> Info     [SshEpInvoker]   Result: [0]
[18.02.2020 18:42:45] <01> Info     Command [arch] result: x86_64
[18.02.2020 18:42:45] <01> Info     , exit code '0'
[18.02.2020 18:42:45] <01> Info     [SshEpInvoker] Executing command '/opt/veeam//veeaminstaller --version'
[18.02.2020 18:42:45] <01> Info     [SshEpInvoker]   Result: [1] stderr [Not a valid network mask.]
[18.02.2020 18:42:45] <01> Info     Installer not found
[18.02.2020 18:42:45] <01> Info     Not a valid network mask. (System.Exception)

When running strace on the server you will notice the following:

Code: Select all

#strace /opt/veeam//veeaminstaller --version
[deleted a lot of lines]
readlink("/sys/class/net/ztname", "../../devices/virtual/net/ztname"..., 256) = 36
write(3, "[18.02.2020 19:02:35.484] <13999"..., 95) = 95
write(3, "[18.02.2020 19:02:35.485] <13999"..., 806) = 806
write(2, "Not a valid network mask.", 25Not a valid network mask.) = 25
write(2, "\n", 1
)                       = 1

Workaround that worked for me, as I have an OpenVPN connection available, was to stop the ZeroTier-one service.

I am now able to rescan the server.

The support case is still open as we are trying to get this working with ZeroTier enabled.

[PTide]

Hi,

While the engineer is configuring ZT environment, would you check whether you're running VAL 4.0.0.1947 or 4.0.0.1961 ? If the former, then kindly upgrade and check whether the issue persists on a newer build.

Thanks!

[mkevenaar]

Hi @PTide,

I am on the 1961 version:

Code: Select all

# rpm -qa | grep veeam
veeamsnap-4.0.0.1961-1.noarch
veeam-4.0.0.1961-1.el7.x86_64
veeam-release-el7-1.0.7-1.x86_64

[mkevenaar]

It seems like there might be an issue when using IPv6 and some prefixlen.

I can confirm that I have this issue with a prefixlen of 40 and 88. These are setup when using ZeroTier RFC4193 setting or ZeroTier 6PLANE IPv6 configurations.

The machine also has IPv6 addresses with a prefixlen of 64 and 48. These seem to work without any issues.

Together with the engineer we have disabled the IPv6 settings in ZeroTier as I am currently not using them. This way the ZeroTier IPv4 network can be used again.

[PTide]

Good to know, thanks for getting back to us with an update.

Cheers!