SureBackup/VirtualLab and portgroups with same subnet/gateway

[pirx]

#07929109

SureBackup/VL is my final enemy. For a long time now.

In production we have different clusters with different vDS. On those vDS, portgroups with identical VLANs/subnets/gateways are configured (for historical reasons we decided to not use only one vDS streched over all clusters at a location). SureBackup jobs are based on linked backup jobs, which are on per cluster base. All kinds of networks are used in clusters.

There seems to be no easy way to setup SB and VL for this. A single VL can only have the gateway address of a specific network configured on one vNIC in isolation network (same gw IP can not be configured on multipe vNICs). For our many jobs from many clusters that share identical networks (but different portgroup/network names) it means that we need a lot of VLs. One per cluster as far as I understand.

Example: for below 5 clusters all using VLAN 11 (there are even more using VLAN 11...) configured on different portgroups (cluster01_dvs01_vlan11 ....) I can not create a single VL for SureBackup as the gw is identical.

cluster01_dvs01_vlan11 11 10.11.0.0/16 10.11.8.1
cluster03_dvs01_vlan11 11 10.11.0.0/16 10.11.8.1
cluster20_dvs01_vlan11 11 10.11.0.0/16 10.11.8.1
cluster21_dvs01_vlan11 11 10.11.0.0/16 10.11.8.1
cluster_Lab_dvs01_vlan11 11 10.11.0.0/16 10.11.8.1

If this is the case, is there any way to clone/copy VLs?

[pirx]

NATing on proxy seems to be black magic or I've still a fundamental misunderstanding.

I now created a dedicated VL for all SB jobs of one cluster. VL proxy is in same VLAN/Subnet as VBR server.

I've mapped networks like this

VLAN ID Distributed Switch Subnet GW VL Mask VL Network VL Masq
5 cluster03_dvs01 10.24.2.0/23 10.24.2.1 255.255.0.0 10.24.0.0/16 10.254.C.D
11 cluster03_dvs01 10.11.0.0/16 10.11.8.1 255.255.128.0 10.11.0.0/16 10.255.128.D
98 cluster03_dvs01 10.24.100.0/22 10.24.100.1 255.255.224.0 10.24.96.0/19 10.255.160.D
100 cluster03_dvs01 10.1.0.0/16 10.1.0.1 255.255.240.0 10.1.0.0/20 10.255.240.D
182 icluster03_dvs01 10.24.72.0/23 10.24.72.1 255.255.248.0 10.24.72.0/21 10.255.248.D

All VMs in the SB job fail with something like "Warning Network adapter 1: IP address 10.11.3.9, failed - destination host unreachable"

24.12.2025 12:09:08 Updating virtual lab parameters
24.12.2025 12:09:07 IP address 10.254.2.119, network '10.254.0.0', mask '255.255.0.0', gateway 10.11.5.171
24.12.2025 12:09:08 Summary: OS booted up successfully
24.12.2025 12:09:09 Heartbeat test
24.12.2025 12:09:09 Heartbeat status: green
24.12.2025 12:09:09 Results: heartbeat is green, passed
24.12.2025 12:09:09 Summary: 100% total pass rate
24.12.2025 12:09:09 Running ping test(s)
24.12.2025 12:09:10 Network adapter 1: name cluster03_dvs01_vlan5, usable
24.12.2025 12:09:38 Warning Network adapter 1: IP address 10.24.2.119, failed - destination host unreachable
24.12.2025 12:09:38 Warning No successful ping(s), waiting for maximum boot time...

Example for a Linux VM with production IP 10.24.2.119

- in vCenter I see that the started VM has the correct IP 10.24.2.119
- from VBR server I can reach VL proxy production IP 10.11.5.171. Routes are there.

10.254.0.0 255.255.0.0 10.11.5.171 10.11.38.20 16
10.255.128.0 255.255.128.0 10.11.5.171 10.11.38.20 16
10.255.160.0 255.255.224.0 10.11.5.171 10.11.38.20 16
10.255.240.0 255.255.240.0 10.11.5.171 10.11.38.20 16
10.255.248.0 255.255.248.0 10.11.5.171 10.11.38.20 16

- from VBR server traceroute is not passing proxy to reach NATed destination IP 10.254.2.119 of VM, but it is using the proxy as gw (10.11.5.171)

# tracert 10.254.2.119

Tracing route to 10.254.2.119 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms sdes0671 [10.11.5.171]
2 <1 ms <1 ms <1 ms 10.254.2.119
3 10.254.2.119 reports: Destination host unreachable.

- I loggend in with vSphere console to the VM with IP 10.24.2.119. It has gw 10.24.2.1 set (static config) _and_ it can reach it.

That's where I'm lost. Proxy is reachable from prod and from the VM is isolation network. But somehow NAT is not working. Is there any way to login to appliance proxy with SSH to check? I'm pretty sure I did this years ago, but ssh port is disabled.

[petesteven]

I think ssh is not possible, but you can login directly to the proxy via vCenter/ESXi Console.

[pirx]

I logged in via console and enabled ssh, but I can not make ssh start automatically.

Anyway. I was able to strip down my test to 3 VLANs/network/masq-networks. When I add the third one (VLAN 181), the VMs connected to the second one (VLAN 182) stop working.

vNIC1 10.253.x.x 10.11.8.1
vNIC2 10.254.128.x 10.24.72.1 (VLAN 182)
vNIC3 10.255.240.0 10.24.70.1 (VLAN 181)

Logged in to appliance I see with tcpdump that everything is fine when doing a traceroute on VBR server or appliance to the masq IPs of the VM in VLAN 182. Alliance is able to üping etc. Once I add the masq network for VLAN 182 and test again, it fails.

What I then see in tcpdump on appliance are packages with time exceeded. I can only guess that there is a loop now.

Until now support could not really explain what is happening and for them masq rules seem also kind o black magic.

[pirx]

I received feedback from L2 support about the failing SB job with the prod subnets 10.24.72.0/23 and 10.24.70.0/23.

These two networks have part of IP addresses overlap so during the tests Virtual lab VM cannot correctly complete the routing and fails to reach the tested VM.
The only workaround here is to create another Virtual lab and SureBackup job to process VMs from the overlapped network.

I've no idea how SB should be implemented in 'larger' companies. In my experience its not unusual to have many different VLANs and subnets connected to VMs in one cluster / Veeam backup jobs. Creating a dedicated Virtual Lab is not working as SB jobs only use one VL and SB jobs are based on clusters in our case - and I don't see that we change this to be based on VLANs just to get SB working. Using an Application Groups for each VLAN is also not really working (tried this for and other issue before) as a SB job will completely fail as soon as the first task fails.

As my current issue is a bit different that the initially subject of this thread, I will a new one to get confirmation here.