SureReplica - One or more networks cannot be mapped

[joebranca]

I am attempting a preliminary test with SureReplica before progress on a bigger DRO project. We only need to validate replicas can be powered up and booted as functional VMs. In theory network mapping isn't needed since not even ping is necessary, but it appears network mapping is required for SureReplica to bring up the replica VMs at all.

- VBR running replication jobs and virtual lab are in DR site.

- Set up a small SureReplica job of 3 VMs, source VMs are from two different production networks, though their replication job maps their vNICs to a single DR subnet. They get re-IPed during failovers.

Virtual Lab setup:

Networking Mode: Advanced Single host

Isolated Networks mapping:
Production network 1 maps to isolated network label 1
Production network 2 maps to isolated network label 2

Network settings:
vNIC 1: isolated network label 1 configured to have IP address same as production network 1 gateway IP, subnet mask same as production network 1 subnet mask - 255.255.255.128.
Masquerade IP 192.168.255.128

vNIC 2: isolated network label 2 configured to have IP address same as production network 2 gateway IP, subnet mask same as production network 2 subnet mask - 255.255.255.192.
Masquerade IP 192.168.100.192

In both vNIC configurations, when I select the isolated network for the vNIC to connect to, a message pops up: "Unable to resolve network settings for <isolated network label> (<production network subnet>)." Even though I was able to search and select the production networks in vcenter in the prior Isolated Network settings page.
Also, I have registry set on VBR to remove '/' and '&' as restricted symbols, per this KB article - https://www.veeam.com/kb2074 Since in our environment, the port group names may use a '/' between network and mask, or it may use '&2f' instead of '/'.

When I run the SureReplica job, the network mapping does not happen. It seems like it doesn't like the DR port group (128.195.***.***/28-v759) assigned to the replica's vNIC (from the replication job) while its residing in DR subnet:

"Warning Network 1: production 128.195.***.***/28-v759, isolated unknown, not mapped"
"Warning Results: Networks: 0/1 mapped, 1 unmapped"
"Warning Summary: One or more networks cannot be mapped, check virtual lab settings"

the later ping step gets skipped:
"Running Ping test"
"One or more networks cannot be mapped, check virtual lab settings"
"Summary: operation is skipped"

Am I missing something simple? My understanding is the virtual lab maps the original source VMs' source networks to isolated networks, and this has nothing to do with the replica's vNIC port group assignment, since SureReplica does not re-IP from prod network to DR network IPs like Failover does.

[Andreas Neufert]

If I understand it correctly, then your network mapping is done with a configuration for the source side. But the tests use the replication target VMs.

So likely in your case the solution is, that you need to create the network mappings for the networks within the replica target side. You can use then the IP Gateway and Subnet from the production for the testing. This should work.

[haslund]

The message "Unable to resolve network settings for <isolated network label> (<production network subnet>)." is quite common. Veeam sends a request to the vCenter and sometimes it unexpectedly sends back a blank response, we then in turn show this message. It's not a big problem, but it means you will need to carefully and manually input all network information.

Could you share some screenshots of your virtual lab configuration?

[joebranca]

If I understand it correctly, then your network mapping is done with a configuration for the source side. But the tests use the replication target VMs.

So likely in your case the solution is, that you need to create the network mappings for the networks within the replica target side. You can use then the IP Gateway and Subnet from the production for the testing. This should work.

Ok I will try this and update the thread. In the mapping step I will map the replica's DR subnet "128.195.***.***/28" to an isolated subnet label, and then in the vNIC config step, assign that mapping to the vNIC and assign production environment gateway IP and subnet to the interface.

[joebranca]

Yes that fixed the network mapping error.

I also see that in our case, sometimes source VMs from more than one production network are mapped to a single DR subnet (2 to 1 mappings), and that will not work for testing in a single virtual lab, since the virtual lab only supports 1 to 1 network mappings correct?

[Andreas Neufert]

I think the main point here is that you could define only 1 gateway for 2 subnets.

But in general if you have VMs with muliple NICs you can define the virutal lab network for each of the virtual switches and subnets available and enable routing within the virutal lab when needed. This way all VMs can speak with each other in the virtual lab and you can test things there.

If you are concerned about the private API subnet burning, then just use public subnets that you do not use in your oganization as Masquerade Networks. It will warn you about it, but it will work fine.

[joebranca]

Since I posted previously about the SureReplica jobs now running as expected in the DR environment (after the recommendation above about correcting the settings to use DR networks for mappings and production IPs for vNIC configs), I am also on the production site setting up a SureBackup virtual lab to test restore Veeam backups of VMs also from multiple production networks. This is resulting in the same errors as my initial problem, e.g.

"4/10/2025 1:01:11 PM Warning Network 1: production x.x.x.x%2f26-v828, isolated unknown, not mapped"

I made sure to configure the SureBackup's virtual lab so that the 7 vNICs are mapping 7 production networks to isolated networks, with unused VLAN IDs, and then in the Network Settings step each of those vNICs are set with IPs coinciding with the production network gateway IP, prod subnet mask, and some masquerade IP from private network spaces. Back in the mapping step, my selection of production networks are taken directly from browsing the specific ESX host which the lab and proxy are configured to use for bringing up VMs. I have verified that the selected host has the 7 isolated networks available.

When I run the job, I monitor the restored VMs in the lab and see that when they are registered, their NICs do have the correctly assigned isolated network named port group. However once power on of the restored VM commences, the NIC loses that port group assignment and the "isolated unknown, not mapped" errors pop up in the job for each VM being tested.

Anything else I'm missing with the lab config?

[Andreas Neufert]

Do you use NSX? Can you check if you use a supported version?
https://helpcenter.veeam.com/docs/backu ... 20#network

I think it is time that someone looks into the logs. Can you please open a support ticket and explain it there, then post here the support ticket number so that we can monitor it from our side?

[joebranca]

No NSX in our VMWare environment. I will open a ticket today. Last time I looked into this, I don't think I was able to locate any detailed logs for SureBackup jobs on the VBR server. Where should I look for error lines after running SureBackup?

[joebranca]

Disregard that last question, Support log based on SureBackup job was generated through the console. We'll see if it has any other details than what the job window showed. Submitted Case #07670102

[Andreas Neufert]

If I understood the support case internal notes, then there are different VMs in the same network but in different subnets.
Workaround was to create 2 different labs so that the IP configuration of the lab matches the specific subnet and split the VMs to 2 different surebackup jobs that use the labs accordingly.