Requirement: While VM is in source zone or when in failed over zone, we want to use same 'Test fail over network' (vNet1/subnet 3). This test fail over network is one of the subnet (8 IPs only) of an existing established Virtual network which has connectivity to on-prem network. We are able to perform test fail over without affecting the production server availability when VM is in source zone or target zone. During fail over, failed over VM in target zone to get new IP in same subnet or keep existing IP (static) - ie: Target network same as source network (vNet3/subnet 1) and after fail back keep the same IP address. Configuration Test network for fail over configured - vNet1/subnet 3. Subnet 3 in vNet1 - Security Group configured to allow RDP traffic(inbound) only and all outbound traffic denied. Note: With this configuration we are able to perform test fail over without impacting the production server availability as RDP traffic only can reach test failed over VM. Observation Able to edit and save Network parameters for replicated items ( RSV --> Replicated Items --> VM --> Network) before fail over execution to configure test fail over settings for Virtual Network ( vNet1/subnet 3) Executed Test Fail over: working as expected. Test VM's-nic obtained IP address in vNet1/subnet 3 Executed Fail over (with Dynamic IP): worked as expected. Failed over VM's-nic obtained IP address in vNet3/subnet 1. Commit /Reprotect - done Tried 'test fail over' - Available option to select 'Virtual Network' only - no option to select 'subnet', ended up test failed over VM received IP from vNet1/Subnet 1 which is a production network (un-restricted traffic). Impact on application availability ( 2 hosts has same name and SID ). Tried configuring Network parameters (same as step 1) on failed over VM to pre-configure Virtual Network and Subnet - Unable to save the configuration as restriction applied (as changes on Failed Over VM not allowed) Issue: Azure VM, zone to zone Test Fail over configuration - Test fail over network limitation when VM is in failed over state. Unable to use preferred subnet (with restricted inbound and outbound traffic) when target vNet has multi subnets and shutting down application server for test fail over is not an option due to business requirement. Work around: When Test Fail over subnet is the only one subnet associated to Virtual Network then this is not an issue as we can pickup test fail over virtual network while executing the test fail over, subnet will be defaulted to single subnet. In our environment we have to use x.y.z.0/24 IP address space for virtual network, otherwise connectivity to on-prem network is not working, Is this a limitation of the product or I am missing something? Why a capability available to run failover test with a preferred subnet while VM in normal mode ( in source zone without impacting application availability) is not available when failed over VM is running in failed over target zone? This is limiting the ability to perform test fail over while utilizing same 'test subnet' (few IPs) which has security group configured to allow RDP access only while VM is in Failed over state ( running in failed over zone)

Hello @ {Kan}-{Ran} Thank you for posting this concern on this community. I just wanted to gather the following detail stated down below: Looking forward to hearing from you Cheers, Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

Azure Site Recovery Zone to Zone - unable to edit Test Fail over network configuration when VM is running in Failed over Zone.

{Ran}-{Kan} 0

Requirement:

While VM is in source zone or when in failed over zone, we want to use same 'Test fail over network' (vNet1/subnet 3). This test fail over network is one of the subnet (8 IPs only) of an existing established Virtual network which has connectivity to on-prem network.
We are able to perform test fail over without affecting the production server availability when VM is in source zone or target zone.
During fail over, failed over VM in target zone to get new IP in same subnet or keep existing IP (static) - ie: Target network same as source network (vNet3/subnet 1) and after fail back keep the same IP address.

Configuration

Test network for fail over configured - vNet1/subnet 3.
Subnet 3 in vNet1 - Security Group configured to allow RDP traffic(inbound) only and all outbound traffic denied.

Note: With this configuration we are able to perform test fail over without impacting the production server availability as RDP traffic only can reach test failed over VM.

Observation

Able to edit and save Network parameters for replicated items ( RSV --> Replicated Items --> VM --> Network) before fail over execution to configure test fail over settings for Virtual Network ( vNet1/subnet 3)
Executed Test Fail over: working as expected. Test VM's-nic obtained IP address in vNet1/subnet 3
Executed Fail over (with Dynamic IP): worked as expected. Failed over VM's-nic obtained IP address in vNet3/subnet 1.
Commit /Reprotect - done
Tried 'test fail over' - Available option to select 'Virtual Network' only - no option to select 'subnet', ended up test failed over VM received IP from vNet1/Subnet 1 which is a production network (un-restricted traffic). Impact on application availability ( 2 hosts has same name and SID ).
Tried configuring Network parameters (same as step 1) on failed over VM to pre-configure Virtual Network and Subnet - Unable to save the configuration as restriction applied (as changes on Failed Over VM not allowed)

Issue:

Azure VM, zone to zone Test Fail over configuration - Test fail over network limitation when VM is in failed over state.

Unable to use preferred subnet (with restricted inbound and outbound traffic) when target vNet has multi subnets and shutting down application server for test fail over is not an option due to business requirement.

Work around:

When Test Fail over subnet is the only one subnet associated to Virtual Network then this is not an issue as we can pickup test fail over virtual network while executing the test fail over, subnet will be defaulted to single subnet. In our environment we have to use x.y.z.0/24 IP address space for virtual network, otherwise connectivity to on-prem network is not working,

Is this a limitation of the product or I am missing something?

Why a capability available to run failover test with a preferred subnet while VM in normal mode ( in source zone without impacting application availability) is not available when failed over VM is running in failed over target zone?

This is limiting the ability to perform test fail over while utilizing same 'test subnet' (few IPs) which has security group configured to allow RDP access only while VM is in Failed over state ( running in failed over zone)

1 answer

risolis 8,701 Reputation points

2023-05-04T02:41:07.7533333+00:00

Hello @{Kan}-{Ran}

Thank you for posting this concern on this community.

I just wanted to gather the following detail stated down below:

Looking forward to hearing from you

Cheers,

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.
Please sign in to rate this answer.
{Ran}-{Kan} 0 Reputation points

2023-05-04T12:13:38.45+00:00

Hi @risolis ,

Thank you for following up,

Incase previous information is not clear. I am not seeing any issues performing actual fail over or fail back.

VM Nic in failed over zone (zone 2) is receiving IP within same subnet (same virtual network) as I am doing the Zone-to-zone (eg Zone 1 - Zone2) Fail over. Also after the Failback to primary location (Zone 2 to Zone 1) VM in primary location (zone1) keeps original IP address. All working as expected.

The issue is, I am unable to follow recommended approach that is using a non-production network for test failover when active VM is running in failed over zone (zone2) and original VM in primary location ( Zone1) has been re-protected as target VM after fail over. (After Failover --> Commit--> Reprotect)

Unable to edit Network setting to assign non-production network and a preferred subnet on a failed over VM for test failover, but this option is available when active VM is running in primary location,

Also, there is no option to select preferred Subnet while performing test fail over, only available option is select a virtual network. When I select non-production network with multiple subnet the test fail over VM's Nic is receiving IP address within first available subnet, not the subnet (which has restricted security group attached) I used for test failover while VM is running in primary location (zone1).

risolis 8,701 Reputation points

2023-05-05T03:05:43.9666667+00:00

Hi @{Kan}-{Ran}

Thank you for your explanation about it.

I would like to make few questions down below:

Is this zonal, zone-redundant, and always-available disaster recovery set up? >> Just for doublechecking my understanding....

Is this on the same resource group?

Are you running any of the following series? >>>> "VMs that support availability zones: AV2-series, B-series, DSv2-series, DSv3-series, Dv2-series, Dv3-series, ESv3-series, Ev3-series, F-series, FS-series, FSv2-series, and M-series."*

Are you using different virtual network for test failover? >> I know that you stated "same virtual network"

Is this VMware or Hyper-V solution?

Did you use the shutdown VM option when doing the test-failover step?

Did you configure any recovery plan?

Looking forward to hearing from you

Cheers!

{Ran}-{Kan} 0 Reputation points

2023-05-10T03:58:21.8166667+00:00

1. Azure Site Recovery Zone to Zone DR config. VMs are in Zone 1 and protected in Zone 2, when VMs failed over to zone 2 re-protected back to Zone 1 (Primary location). Actual fail over - Network config - using same virtual network -- All working as expected.

2. As Azure Site Recovery for VMs source RG and target RG can't be same RG. We are failing back to source RG (yes) - Meaning that we are not removing replication and re-protecting after the fail over, just committing the failover and then re-protecting.

3. We have multiple VMs protected by ASR. OS Windows, checked series they are supported for ASR. some are Standard B2s, Standard D4 v5

4. Production fail over - Production Virtual network, and one subnet out of multiple subnets presents in that virtual network (eg: vNet3/subnet 1). As vNet/subnet spanned across AZ, it is not an issue.

Test Fail over - From Primary zone to Secondary zone

Dedicated subnet (SG to restrict traffic) in an established virtual network ( note: not the same vNet used for Prod fail over as it is not supported - eg: vNet1/subnet 3) . We can perform test fail over to preferred subnet (vNet1/subnet 3) - not an issue.

Test fail over - From Secondary zone to Primary zone

Attempting to perform test fail over using preferred subnet (vNet1/subnet 3) - no options are available via Portal- That is the original issue I raised.

Not clear about why this question raised - This is Azure Site Recovery Zone to Zone Config.

6.I am unaware that shutdown option is available during test fail over (atleast not visible in my region)

7.We have protected items in recovery plan and it self, We are seeing the limitation in both scenario

SadiqhAhmed-MSFT 38,081 Reputation points Microsoft Employee

2023-05-16T06:36:09.86+00:00

@{Kan}-{Ran} Zone to Zone Disaster Recovery reduces complexity as it leverages redundant networking concepts across Availability Zones making configuration much simpler.
You may use the same virtual network as the source network for actual failovers. But you must use a different virtual network to the source virtual network for test failovers. Changes that you make to the test failover VMs are lost when you clean up the test failover virtual machines. These changes are not replicated back to the primary VMs.
https://learn.microsoft.com/en-us/azure/site-recovery/azure-to-azure-how-to-enable-zone-to-zone-disaster-recovery#networking-for-zone-to-zone-disaster-recovery

Hope this helps!

SadiqhAhmed-MSFT 38,081 Reputation points Microsoft Employee

2023-05-17T10:59:18.7833333+00:00

@{Kan}-{Ran} Checking in to see if the above answer helped. If yes, please do "Accept Answer" and Up-Vote it. Let us know if there are still any additional issues we can help with.

{Ran}-{Kan} 0 Reputation points

2023-05-19T23:04:19.2066667+00:00

@SadiqhAhmed-MSFT Thank you for following up.

I am after a solution to perform,

"VM Test fail over to a Test fail over subnet” (a preferred subnet in Test fail over Virtual Network) when VM is being re-protected back in primary location (zone1) after VM failed over to secondary location (zone2),

*Test fail over Virtual Network is different virtual network to the source/target virtual network. It has multiple subnets.

Test fail over subnet is not the first subnet in the “Test fail over Virtual Network”. A small sub range of IP address.eg: 3<sup>rd</sup> subnet in Test fail over Virtual Network.

Scenario:

Before Fail over:

VM - in Primary location Zone1, protected in Zone2.

*Source Network : vnet3 / subnet1

*Target Network : vnet3 / subnet1

Test Fail over network: vnet1 / subnet3

As there is an option to pre-configure preferred test fail over network in "replicated items" available, we can pre-configure "Test fail over target subnet" to a "preferred subnet". Subnet can be any subnet in a Virtual network (Virtual Network can be any network other than the source virtual network).

-> This is working when VM is in primary location (before fail over initiated and re-protected back).

-> After pre-configuring, we can initiate test failover and test VM’s NIC connect to vnet1 / subnet3 as expected.

-> As we can control the inbound and outbound traffic on that subnet(vnet1 / subnet3) we can do test fail over any time without impacting the production system (Note: While VM is in primary location -Zone1). A convenient capability to run test failover any time.

After Failed over and Re-protected

VM - in secondary location Zone2, protected back in Zone1,

*Source Network : vnet3 / subnet1

*Target Network : vnet3 / subnet1

Test Fail over network: I want to use vnet1 / subnet3 as "Test fail over target subnet" as it has necessary FW rules configured (Security Group) to block inbound and outbound traffic.

This is not possible in "replicated items" -"Network" page while VM is protected back in primary location. Previously configured setting for test fail over (subnet) is missing now and not inheriting from pre-failover replicated items config. I understand why we must reconfigure the Test Fail over network, but we can't save any changes in "replicated items" -"Network" page after VM re-protected back in primary zone (zne1) even for test fail over settings.

Also, while executing test fail over, there is no option to select subnet after selecting the virtual network. If I select virtual network vnet1 – Test Fail over successfully completing but test VM’s NIC is connecting to vnet1 /subnet1 not to vnet1/subnet3. No inbound or outbound traffic blocked for vnet1/subnet1. In this situation there is conflict as Test Failed over VM running in Zone1 is reachable from production network.

Is this a limitation of the product or I am missing something or test fail over network can be configured using CloudShell commands?

Why a capability available to run failover test with a preferred subnet while VM in primary location ( in source zone without impacting application availability) is not available when failed over VM is running in secondary location -failed over zone?

SadiqhAhmed-MSFT 38,081 Reputation points Microsoft Employee

2023-05-23T14:20:40.8933333+00:00

@{Kan}-{Ran} You have an interesting requirement and I think we need to have direct interaction to better understand the set up and work on accomplishing it. Please send us an email at AzCommunity @ Microsoft dot com with subject: Attn: Sadiqh Ahmed with your subscription ID and a link to this forum thread for context.

{Ran}-{Kan} 0 Reputation points

2023-05-25T23:26:29.1466667+00:00

@SadiqhAhmed-MSFT I will send the email to AZ community this weekend with the details.

SadiqhAhmed-MSFT 38,081 Reputation points Microsoft Employee

2023-05-29T09:55:13.22+00:00

@{Kan}-{Ran} We haven't received the email from you yet!
Sign in to comment