Issue with virtual lab & servers with dual stack interfaces

[ICarter]

Hi,

First up I'd like to make it very clear, this post is NOT to request full IPv6 support in Veeam Backup and Replication. That's been discussed at length elsewhere, and we understand this is a lot of work. Please don't turn this thread into another discussion about full support, which while important to many people, is NOT what we are asking for here.

What we are looking for is a shorter term fix, to a serious problem affecting Windows Server customers, whether actively using IPv6 or not.

Windows Server has had IPv6 dual-stack enabled by default, for many years. Currently to get a Windows Server to work in sandbox-labs, including SureBackup and SureReplica, we've been advised to apply the "DisabledComponents" registry key (detailed in https://support.microsoft.com/en-us/kb/929852) to turn this off.

This works for some scenarios. However this workaround has three major issues, in our experience:

1. The change is not recommended by Microsoft, as you can see in the article, for any current Windows Server release.
2. Some products refuse to work (such as MS SQL Server Always On Availability Groups).
3. You can't use any IPv6 at all on the server (even for providing a service to users, not backup).

We would like to request that Veeam issue a short term fix, to fill the gap between today and full IPv6 support, so customers can use SureBackup/Replica and sandbox-labs without having to turn off all IPv6 and put their VMs into an untested state.

In our view this means changing Veeam to at least "ignore" IPv6 addresses when building a lab, instead of failing during the deployment process, with the error – Error: IP-address is not IPv4. Which seems to be the behaviour at the moment. It is worth noting this happens prior to the various validation tests, such as ping, heartbeat etc. which we have disabled to rule them out.

After repeated experimentation we surmise that during the boot process Veeam generates an array of IP addresses that the server has and that this array is in an arbitrary order. If the first address processed in the array is an IPv6 address the error generated above occurs and the lab fails. If the first address is an IPv4 address this is processed on the usual way by Veeam, mapped to the lab IP space etc. and the lab succeeds. We suspect it must occur in this way as repeated restarting of a lab that fails with the IPv6 error and making no changes can result in an working lab provided the IPv4 address is encountered first.

Ideally we would like Veeam to just ignore IPv6 addresses when processing the array. If it hit a IPv4 address it should be processed in the usual way. If the end of the array is encountered without finding any valid addresses the lab should then fail.

Has anyone else encountered this and found a way around it, or does it need a fix?

Cheers, Ian

[nefes]

Hello Ian,

It is not so easy as you describe. SureBackup job certainly skips IPv6 addresses since it can't be used for further ping and script tests.
However there are some rare situations, where VMware changes the order in which it returns IP address list, so we mistakenly work with IPv6 and fail.
Have you opened a support case for this issue? After reviewing your logs we may find out, which exact situation happens to you. We even have a private fix for one of such situations.
Please post a case number here, so it will be easier to follow it.

[ICarter]

Hi,

One of my colleagues did log a case (01679614) back in February but got the stock "IPv6 isn't supported" answer. Looking through the transcript I'm not sure if any logs were analysed. I am happy to open a new case and provide some logs if it can be investigated?

Cheers, Ian

[nefes]

Yes, please open a new one and post number here. We are very interested in checking private fix in real environments, since this problem is not reproducible in our lab. Thanks!

[ICarter]

Hi,

I've logged this as case 01782410.

Cheers, Ian