Merge pull request #208082 from siddomala/vWANVMSSBGP

Updating vWAN FAQ for VMSS migration and ER Y (vWAN to non-vWAN connectivity)

Author: ttorble

articles/virtual-wan/virtual-wan-faq.md

@@ -332,6 +332,10 @@ The current behavior is to prefer the ExpressRoute circuit path over hub-to-hub
 
 * Contact the product team to take part in the gated public preview. In this preview, traffic between the 2 hubs traverses through the Azure Virtual WAN router in each hub and uses a hub-to-hub path instead of the ExpressRoute path (which traverses through the Microsoft Edge routers/MSEE). To use this feature during preview, email **[email protected]** with the Virtual WAN IDs, Subscription ID, and the Azure region. Expect a response within 48 business hours (Monday-Friday) with confirmation that the feature is enabled.
 
+### When there's an ExpressRoute circuit connected as a bow-tie to a vWAN hub and a non-vWAN (customer-managed) VNet, what is the path for the non-vWAN VNET to reach a VNet directly connected to the vWAN hub? 
+
+The current behavior is to prefer the ExpressRoute circuit path for non-vWAN VNet to vWAN VNet connectivity. However, this isn't encouraged in a Virtual WAN setup. To resolve this, you can [create a Virtual Network connection](howto-connect-vnet-hub.md) to directly connect the non-vWAN VNet to the vWAN hub. Afterwards, VNet to VNet traffic will traverse through the Virtual WAN router instead of the ExpressRoute path (which traverses through the Microsoft Enterprise Edge routers/MSEE).
+
 ### Can hubs be created in different resource group in Virtual WAN?
 
 Yes. This option is currently available via PowerShell only. The Virtual WAN portal requires that the hubs are in the same resource group as the Virtual WAN resource itself.
@@ -397,7 +401,13 @@ Yes, BGP communities generated by on-premises will be preserved in Virtual WAN.
 
 The Virtual WAN team has been working on upgrading virtual routers from their current Cloud Services infrastructure to Virtual Machine Scale Sets based deployments. This will enable the virtual hub router to now be availability zone aware. If you navigate to your Virtual WAN hub resource and see this message and button, then you can upgrade your router to the latest version by clicking on the button. Azure-wide Cloud Services-based infrastructure is deprecating. If you would like to take advantage of new Virtual WAN features, such as [BGP peering with the hub](create-bgp-peering-hub-portal.md), you'll have to update your virtual hub router via Azure Portal. 
 
-You’ll only be able to update your virtual hub router if all the resources (gateways/route tables/VNet connections) in your hub are in a succeeded state. Additionally, as this operation requires deployment of new virtual machine scale sets based virtual hub routers, you’ll face an expected downtime of 30 minutes per hub. Within a single Virtual WAN resource, hubs should be updated one at a time instead of updating multiple at the same time. When the Router Version says “Latest”, then the hub is done updating. There will be no routing behavior changes after this update. If the update fails for any reason, your hub will be auto recovered to the old version to ensure there is still a working setup.
+You’ll only be able to update your virtual hub router if all the resources (gateways/route tables/VNet connections) in your hub are in a succeeded state. Additionally, as this operation requires deployment of new virtual machine scale sets based virtual hub routers, you’ll face an expected downtime of up to 30 minutes per hub. Within a single Virtual WAN resource, hubs should be updated one at a time instead of updating multiple at the same time. When the Router Version says “Latest”, then the hub is done updating. There will be no routing behavior changes after this update unless one of the following is true:
+
+1. The Virtual WAN hub is in a different region than one or more spoke VNets. In this case, you will have to delete and recreate these respective VNet connections to maintain connectivity. 
+1. You have already configured BGP peering between your Virtual WAN hub and an NVA in a spoke VNet. In this case, you will have to [delete and then recreate the BGP peer](create-bgp-peering-hub-portal.md). Since the virtual hub router's IP addresses change after the upgrade, you will also have to reconfigure your NVA to peer with the virtual hub router's new IP addresses. These IP addresses are represented as the "virtualRouterIps" field in the Virtual Hub's Resource JSON.
+
+If the update fails for any reason, your hub will be auto recovered to the old version to ensure there is still a working setup.
+
 
 ### Is there a route limit for OpenVPN clients connecting to an Azure P2S VPN gateway?