why surebackup not work correctly with diff VLANs

[baber]

Dear all
hi

i appear a problem in surereplica
my vm that i get backup from that os is linux with ip = 172.20.68.74 255.255.255.224 172.20.68.65 vlan 682
my veeam backup server is in vlan 686 ip = 172.20.68.221 255.255.255.224 172.20.68.193

now i did scenario wuth 2 way :
1- create virtual lab with these :
vlan 682
172.20.68.68
255.255.255.224
172.20.68.65

my proxy config in virtual lab :

https://pasteboard.co/H5OjLy4.jpg

and with below network setting in virtual lab

https://pasteboard.co/H5OmNOr.jpg

now when run surebackup job it will be faile in pinging


this is log :

Code: Select all

2/2/2018 21:57:09          Publishing
2/2/2018 21:57:01          Backup: created at 1/18/2018 3:29:40 PM, type full
2/2/2018 21:57:08          Backup repository: BukharestRepository (type Windows server, server bakveeam, mount server bakveeam)
2/2/2018 21:57:08          Virtual resources: host 172.20.64.14, datastore VeeamBackup_bakveeam, VM bakaml_87c8b1705dd34a53a957b27b9379d538
2/2/2018 21:57:08          Virtual lab: vlabaml
2/2/2018 21:57:08          VM: bakaml (application group, 4096 MB vRAM)
2/2/2018 21:57:08          OS: Red Hat Enterprise Linux 6 (64-bit)
2/2/2018 21:57:09          Network adapter 1: MAC unknown, type static, network unknown
2/2/2018 21:57:09          Assigned roles: none
2/2/2018 21:57:09          Maximum boot time: 600 second(s)
2/2/2018 21:57:09          Application initialization: 120 sec
2/2/2018 21:57:09          Heartbeat test: enabled
2/2/2018 21:57:09          Ping test: enabled
2/2/2018 21:57:09          Script tests: disabled, 0 tests
2/2/2018 21:57:09          Backup file validation: disabled
2/2/2018 21:57:15          Reconfiguring
2/2/2018 21:57:15          Network 1: production vLAN 682, isolated vlabaml vLAN 682, mapped
2/2/2018 21:57:15          Results: 1/1 network(s) mapped, 0 unmapped
2/2/2018 21:57:15          Summary: 100% total pass rate
2/2/2018 21:57:20          Registering
2/2/2018 21:59:26          Powering on
2/2/2018 21:57:24          Waiting for OS to boot for up to 600 seconds (stable IP algorithm)...
2/2/2018 21:57:24          Note: Will proceed to the next step at 2/2/2018 10:07:24 PM or earlier
2/2/2018 21:59:25          Results: IP address 172.20.68.74 is detected
2/2/2018 21:59:26          Updating virtual lab parameters
2/2/2018 21:59:26          Results: IP address 172.30.68.74, network '172.30.0.0', mask '255.255.0.0', gateway 172.20.68.68
2/2/2018 21:59:26          Summary: OS booted up successfully
2/2/2018 21:59:28          Heartbeat test
2/2/2018 21:59:28          Heartbeat status: green
2/2/2018 21:59:28          Results: heartbeat is green, passed
2/2/2018 21:59:28          Summary: 100% total pass rate
2/2/2018 22:02:39 Error    Running ping test(s)
2/2/2018 21:59:28          Network adapter 1: name vLAN 682, usable
2/2/2018 22:00:03 Warning    Network adapter 1: IP address 172.20.68.74, failed - request timed out
2/2/2018 22:00:03          Network adapter 1: IP address fe80::250:56ff:febd:58eb, skipped - IPv4 supported only
2/2/2018 22:00:03 Warning    No successful ping(s), waiting for maximum boot time...
2/2/2018 22:00:03          Note: operation will be repeated at 2/2/2018 10:02:04 PM
2/2/2018 22:02:04          Network adapter 1: name vLAN 682, usable
2/2/2018 22:02:39 Warning    Network adapter 1: IP address 172.20.68.74, failed - request timed out
2/2/2018 22:02:39          Network adapter 1: IP address fe80::250:56ff:febd:58eb, skipped - IPv4 supported only
2/2/2018 22:02:39 Error    Results: 0/2 test(s) passed, 1 failed, 1 skipped
2/2/2018 22:02:39 Error    Summary: 0% total pass rate
2/2/2018 22:02:39          Application initialization

in scenario2 :

1- create virtual lab with these :
vlan 686
172.20.68.194
255.255.255.224
172.20.68.193

my proxy config in virtual lab:

https://pasteboard.co/H5OuhiT.jpg

and with below network setting

https://pasteboard.co/H5OuJJH.jpg


now such as previous way will be fail in pinging step this is log :

Code: Select all

2/2/2018 22:17:31          Publishing
2/2/2018 22:17:23          Backup: created at 1/18/2018 3:29:40 PM, type full
2/2/2018 22:17:30          Backup repository: BukharestRepository (type Windows server, server bakveeam, mount server bakveeam)
2/2/2018 22:17:30          Virtual resources: host 172.20.64.14, datastore VeeamBackup_bakveeam, VM bakaml_834f0af4e2dc40fab521ac3b50f38a96
2/2/2018 22:17:30          Virtual lab: vlabveeam
2/2/2018 22:17:30          VM: bakaml (application group, 4096 MB vRAM)
2/2/2018 22:17:30          OS: Red Hat Enterprise Linux 6 (64-bit)
2/2/2018 22:17:30          Network adapter 1: MAC unknown, type static, network unknown
2/2/2018 22:17:30          Assigned roles: none
2/2/2018 22:17:30          Maximum boot time: 600 second(s)
2/2/2018 22:17:30          Application initialization: 120 sec
2/2/2018 22:17:30          Heartbeat test: enabled
2/2/2018 22:17:30          Ping test: enabled
2/2/2018 22:17:30          Script tests: disabled, 0 tests
2/2/2018 22:17:30          Backup file validation: disabled
2/2/2018 22:17:37 Warning    Reconfiguring
2/2/2018 22:17:37 Warning    Network 1: production vLAN 682, isolated unknown, not mapped
2/2/2018 22:17:37 Warning    Results: 0/1 network(s) mapped, 1 unmapped
2/2/2018 22:17:37 Warning    Summary: One or more networks cannot be mapped, check virtual lab settings
2/2/2018 22:17:41          Registering
2/2/2018 22:19:01 Warning    Powering on
2/2/2018 22:17:46 Warning    One or more networks cannot be mapped, check virtual lab settings
2/2/2018 22:17:46          Waiting for OS to boot for up to 600 seconds (stable heartbeat algorithm)...
2/2/2018 22:17:46          Note: Will proceed to the next step at 2/2/2018 10:27:46 PM or earlier
2/2/2018 22:19:01 Warning    Results: cannot detect IP address
2/2/2018 22:19:01 Warning    Summary: OS booted up successfully
2/2/2018 22:19:03          Heartbeat test
2/2/2018 22:19:03          Heartbeat status: green
2/2/2018 22:19:03          Results: heartbeat is green, passed
2/2/2018 22:19:03          Summary: 100% total pass rate
2/2/2018 22:19:03 Warning    Running ping test(s)
2/2/2018 22:19:03 Warning    One or more networks cannot be mapped, check virtual lab settings
2/2/2018 22:19:03 Warning    Summary: operation is skipped
2/2/2018 22:21:04          Application initialization
2/2/2018 22:19:03          Waiting for 120 more seconds...
2/2/2018 22:19:03          Note: operation will be continued at 2/2/2018 10:21:03 PM
2/2/2018 22:21:04          Summary: application is initialized
2/2/2018 22:21:06          Powering off
2/2/2018 22:21:07          Unregistering
2/2/2018 22:21:10          Cleaning up redo logs
2/2/2018 22:21:12          Unpublishing
2/2/2018 22:21:12          Task finished

but when i change my veeam backup server ip and set that ip in vlan 682 (such as backup vm)
veeam ip = 172.20.68.69 255.255.255.224 172.20.68.65
pinging check will be succeed

now what do i have to do ?
for each vlan do i have to change my veeam ip address?

BR
Babak

[baber]

this problem not appear for anyone ?

[rnelson0]

I went through some trials and tribulations setting up SureBackup myself, I wrote a long article at https://rnelson0.com/2017/09/29/getting ... ckup-jobs/ describing my setup and implementation that might help. One thing I learned is that if the virtual lab proxy appliance is in the same network as the backup server, automatic masquerade routes are created so the backup server can talk to the VMs behind the proxy appliance. If they're in different networks, then you need to add manual routes to the backup server AND ensure transit across the network. The blog post covers this in greater detail.

I believe this is your issue, as it was resolved by moving the backup server into the same vlan as the proxy appliance. Your fix is either to permanently co-locate the backup server and proxy appliance (you can probably keep the backup server where it is and move the proxy appliance, though) or to add routes for the isolated networks on the backup server and on the switch(es) connecting it to the proxy appliance. The first is much simpler and cleaner, IMO.

As you add additional VMs in different vlans, you will not need to do anything UNLESS you use application groups. For any VMs in an application group, you must have a corresponding Isolated Network/vNIC to run the application group's Ping/Script tests. Non-application group VMs will always have Heartbeat/Validation tests, and Ping tests if they are in an existing Isolated Network.

[baber]

i am reading your article but in virtual lab part you said :

Before beginning, we need to decide which host and datastore to use, and grab an IP for the Proxy Appliance on the same network as the Backup server (it can be set up in a different network, but that’s a more complex setup I won’t be visiting in this article)

means that you did not said any about put virtual appliance and veeam backup server in difference vlan

is that correct ?

[baber]

really no one could not solve this problem
that is not logical to use surebackup just when backup proxy and vms that we want check for surebackup put in same vlan the other means
that is not logical we can just check backups that are in same vlan with veam backup server

BR

[baber]

please help me for solve the problem

[baber]

realy anyone did not appear this issue ?

[baber]

i just want to know this is a bug in veeam or not ?

[csydas]

Hey Babak,

Per the User Guide, the Appliance and Veeam should be in the same network when possible: https://helpcenter.veeam.com/docs/backu ... tml?ver=95

You're jumping vlans, which is fine, but that means some extra work needs to be done to get them to see one another. I'm no networking guy so I'm not really sure what the answer is here for your network setup, but that's why Veeam isn't able to perform the tests by default with the first two setups.

This isn't a bug; by default, Veeam will try to print the route to the Virtual Lab during a SureBackup (and SureReplica) run, but it assumes that Veeam and Virtual Lab are in the same network (subnet included); if not, you need to print a route on the Veeam Server to hop over.

In your second setup though, what happens if you change the vNIC to map to vlan 682?

[baber]

Thanks dear friend
i know appliance and veeam server and that machine i want check backup had to in same vlan but it's not logical all of vms in datacenter put in same vlan
i want to know if i use surebackup or sure replica all of my vm's vlan had to same in my Datacenter infrastructure?

BR

[baber]

realy this is so strange for me

anyone can not help for solve the problem

[foggy]

i know appliance and veeam server and that machine i want check backup had to in same vlan but it's not logical all of vms in datacenter put in same vlan

No one says they should reside in the same VLAN. You can configure advanced networking at the corresponding step of the virtual lab wizard.

[Zew]

Rob Nelson and Alex have provided both excellent advise in helping resolve the issue.

I hope the info they provided is enough to get you where you need to be.

Robs comment about IP masquerading and routes is pretty much dead on.

[baber]

so thanks from all of you
the problem has been solved we have 2 way and the straightforward is add new Vnic

BR

[baber]

i have just one question
Do i have to create separate Virtual Lab for every VM that reside in different vm because we had to set specific proxy for each vlan
Is that correct ?

BR

[baber]

please see below pic i put 2 vms that are resite in same vlan in one job but verification job can not start for vm1 and can not continue for vm2 and job fail but when i create a separate job for each one all of steps do excellent what is my problem ?

https://pasteboard.co/HBUreUN.jpg

[baber]

I appear a big problem last step in backup health check is dependent to previous steps for example in below pic script step has been failed but next step (verification) not start why what is problem

https://pasteboard.co/HBZxyyB.jpg

[baber]

actually this is a big problem for example if put 3 vms in one job and if first vm's check fail it won't go to next step and job will fail or escape for others

https://pasteboard.co/HC04PJ5.jpg

[baber]

the Problem solved with remove Application group in the sure backup job