Issues migrating to Dedicated Backup Network

[Norsak]

I wish to offload my Hyper-V backups to a dedicated network/switch.

Here is a simplified diagram of my network:



- Backups where originally talking to HV1 using the LAN IP 192.168.10.9
- Then I added the dedicated backup network
- I added (in veeam) a new Hyper-V Server with IP 10.66.66.10
- I created A replacement backup job targeting VMs on IP 10.66.66.10

Every thing seemed fine, except that I still saw heavy load on the 192.168.10.x network when backups where targeting the Hyper-V host on 10.66.66.10

For trouble-shooting purposes I disconnected the 192.168.10.35 interface on the Veeam server.
This creates the following error when re-scanning the 10.66.66.10 host:

So veeam isn't willing to talk to HV1 using only the 10.66.66.10 interface.
Maybe this is because whatever veeam service/agent got installed on HV1, was installed using 192.168.10.9

How do I fix this? How do I migrate all backup traffic to the 10.66.66.10 interface?

[foggy]

You seem to do everything correct. Might be a routing issue, I recommend contacting support for verification.

[nefes]

Could you please check in name resolution of HV1 on backup server? It should be resolved into 10.66.66.10, not 192.168.10.9.

[Norsak]

Could you please check in name resolution of HV1 on backup server? It should be resolved into 10.66.66.10, not 192.168.10.9

That's actually good advice.
I updated the hosts files on both BACKUP and HV1 so that they resolve each other's hostname and FQDN on a 10.66.66.x IP address.

After restarting the BACKUP server this allowed for jobs to succeed.
----------------------------------------------------------------------------------

But there are still issues.
If I disable the 192.168.10.35 interface on the BACKUP server, then I can successfully run most jobs. Since the ONLY way it can talk to HV! is over the 10.66.66.x network, I do not get any traffic issues on the 192.168.10.x network.
But if I leave the 192.168.10.35 interface enabled on the BACKUP server, then I can see traffic issues on the 192.168.10.x network when i run backup jobs.

Because of these issues, my current strategy is to remove the 192.168.10.35 interface, to enforce complete physical isolation. Then give the 10.66.66.x network internet access.
It's not perfect (BACKUP would not have access to a domain controller), but it's where I think this is headed.

[nefes]

But if I leave the 192.168.10.35 interface enabled on the BACKUP server, then I can see traffic issues on the 192.168.10.x network when i run backup jobs.

Because of these issues, my current strategy is to remove the 192.168.10.35 interface, to enforce complete physical isolation. Then give the 10.66.66.x network internet access.
It's not perfect (BACKUP would not have access to a domain controller), but it's where I think this is headed.

The question is, what traffic is it.
Could you please describe your configuration a little bit deeper:
1. What repository and where do you use? Traffic between host and repository can go through both networks, so you may want to utilize Preferred Networks feature to make it go through backup network (if all components have access to it).
2. Do you use guest processing? If so, and guests are connected to production network only, guest interaction traffic will go through production network anyway. However this traffic should not be intensive, so it is better to stay with it because of benefits from VSS and other guest processing bonuses.
You may also want to utilize Guest Interaction proxy and put it on some internal network of HV1. It will require additional configuration, but that way interaction will go through non-production networks.