Discussions specific to the VMware vSphere hypervisor
Post Reply
Posts: 68
Liked: 7 times
Joined: Jun 08, 2013 10:52 am
Full Name: Peter Howarth

Struggling with SureBackup IP addressing

Post by howartp » Jun 25, 2016 7:49 pm


I've been playing with SureBackup on and off, and spent a good while on it tonight. The script tests are working, but the ping tests are failing with "No destination network for IP address" which is the DC I'm trying to test. (The App Group just has both DCs in it, nothing else)

My live VMs are VMware, on production network "VLAN5_LIVE", all in 192.168.5.*

My B&R 9u1 server is

My DR VMware host is with a VLAN5_LIVE network configured on it. This is working with a regular Win7 VM, accessing production network normally.

Because everything is on 192.168.5.* I am using the Basic single-host network option.

Code: Select all

Lab name: VRTX4 Virtual Lab June16
ESX name:
Datastore: VRTX_Store

Name: VRTX4_Virtual_Lab_June16
Pool name: VRTX4 Virtual Lab June16

Production network name:VLAN5_LIVE
Subnet mask:
Default gateway:


Network configuration type: basic single-host
Network options:
Isolated network: VRTX4 Virtual Lab June16 VLAN5_LIVE
Masquerade IP:
Appliance IP:
DHCP: enabled

Network mapping:
VLAN5_LIVE --> VRTX4 Virtual Lab June16 VLAN5_LIVE
I can see in the logs that SureBackup is creating the route (and it then does route print showing it pointing to

Code: Select all

route.exe add mask
Can anyone suggest what's up?


Posts: 635
Liked: 172 times
Joined: Jun 18, 2012 8:58 pm
Full Name: Alan Bolte

Re: Struggling with SureBackup IP addressing

Post by alanbolte » Jun 26, 2016 12:46 am

Looks like Basic Single Host is picking up the wrong default gateway ( instead of Switch to Advanced Single Host to change the setting.

Posts: 68
Liked: 7 times
Joined: Jun 08, 2013 10:52 am
Full Name: Peter Howarth

Re: Struggling with SureBackup IP addressing

Post by howartp » Jun 26, 2016 4:09 pm

Thanks for your reply.

Isn't it typical that after I posted last night, I managed to get it working - at least to a point.

I have discovered one bug in the SureBackup process, and it's possible my problem is linked to it.

After I posted, I completely deleted my Lab and SureBackup job and started again with exactly the same settings and it worked ok this time.

I noticed earlier on that I had initially created my production networks on the DR host with different names to the production networks on the VMs, so part way through my testing, I renamed the production network, edited the VLab and selected the new network on the Proxy tab. However this doesn't update the network map settings on the final screen of the VLab. In basic mode, despite me telling the VLab to use a new Production Network, it was still mapping the old production network to the isolated network.

The way around this was to set it to Advanced mode, make some changes, go Next then Previous and change it back to Basic Mode - this asked me if I'd like to reset the network settings, after which it did another "detecting networks..." process and subsequently showed me the correct mapping.

If a user makes changes to the production network settings in a VLab, is it possible for the VLab wizard to redetect its networks when in Basic mode?

However, I suspect it still hadn't updated everything completely because when I deleted this VLab and recreated it with the same settings, in Advanced mode, as I'd tried at various points through the day, it worked ok first time.

Now... I told you in my first post that everything was all on 192.168.5.* which was correct for the VMs I was testing with. However some of my VMs are on 192.168.4.* which I need in the same AppGroup as the DCs. I've added a 192.168.4.* entry to the isolated networks in my advanced lab (a copy thereof) to see what happens, but the job is now failing with "failed to power on in time" or something like that.

I'm just running it now and watching it, because I'm not sure if it's a mapping issue (ie it isn't getting an IP response in time because I've got some mapping wrong) or whether it is literally the timeout that needs extending - it's currently at 10 minutes which should be sufficient for most of my VMs!

I'll report back.

Post Reply

Who is online

Users browsing this forum: No registered users and 27 guests