Merge pull request #270412 from cherylmc/vpngwfix

format

Author: v-shils

articles/virtual-wan/about-virtual-hub-routing-preference.md

@@ -1,11 +1,11 @@
 ---
 title: 'Virtual WAN virtual hub routing preference'
 titleSuffix: Azure Virtual WAN
-description: Learn about Virtual WAN Virtual virtual hub routing preference.
+description: Learn about Virtual WAN virtual hub routing preference.
 author: cherylmc
 ms.service: virtual-wan
 ms.topic: conceptual
-ms.date: 07/28/2023
+ms.date: 03/27/2024
 ms.author: cherylmc
 ---
 # Virtual hub routing preference
@@ -19,47 +19,50 @@ The virtual hub router takes routing decisions using built-in route selection al
 This section explains the route selection algorithm in a virtual hub along with the control provided by HRP. When a virtual hub has multiple routes to a destination prefix for on-premises, the best route or routes are selected in the order of preference as follows:
 
 1. Select routes with Longest Prefix Match (LPM).
+1. Prefer static routes learned from the virtual hub route table over BGP routes.
+1. Select best path based on the virtual hub routing preference configuration.
 
-1. Prefer static routes over BGP routes.
+You can select one of the three possible virtual hub routing preference configurations: ExpressRoute, VPN, or AS Path. Each configuration is slightly different. Route rules are processed sequentially within the selected configuration until a match is made.
 
-1. Select best path based on the HRP configuration. There are three possible configurations for HRP and the route preference changes accordingly.
+* **ExpressRoute** (This is the default setting)
 
-   * **ExpressRoute** (This is the default setting.)
+   1. Prefer routes from local virtual hub connections over routes learned from remote virtual hub.
+   1. If there are Routes from both ExpressRoute and Site-to-site VPN connections:
 
-      1. Prefer routes from connections local to a virtual hub over routes learned from remote hub.
-      1. If there are still routes from both ER and S2S VPN connections, then see below. Else proceed to the next rule.
-         * If all the routes are local to the hub, then choose routes learned from ER connections because HRP is set to ER.
-         * If all the routes are through remote hubs, then choose route from S2S VPN connection over ER connections because any transit between ER to ER is supported only if the circuits have ER Global Reach enabled and an Azure Firewall or NVA is provisioned inside the virtual hub.
-      1. Then, prefer the routes with the shortest BGP AS-Path length.
+      * If all the routes are local to the virtual hub, the routes learned from ExpressRoute connections will be chosen because Virtual hub routing preference is set to ExpressRoute.
+      * If all the routes are through remote hubs, Site-to-site VPN will be preferred over ExpressRoute.
+   1. Prefer routes with the shortest BGP AS-Path length.
 
-   * **VPN**
+* **VPN**
 
-      1. Prefer routes from connections local to a virtual hub over routes learned from remote hub.
-      1. If there are routes from both ER and S2S VPN connections, then choose S2S VPN routes.
-      1. Then, prefer the routes with the shortest BGP AS-Path length.
+   1. Prefer routes from local virtual hub connections over routes learned from remote virtual hub.
+   1. If there are routes from both ExpressRoute and Site-to-site VPN connections, the Site-to-site VPN routes will be chosen.
+   1. Prefer routes with the shortest BGP AS-Path length.
 
-   * **AS Path**
+* **AS Path**
 
-      1. Prefer routes with the shortest BGP AS-Path length irrespective of the source of the route advertisements. For example, whether the routes are learned from on-premises connected via S2S VPN or ER.
-      1. Prefer routes from connections local to the virtual hub over routes learned from remote hub.
-      1. If there are routes from both ER and S2S VPN connections, then see below. Else proceed to the next rule.
-         * If all the routes are local to the virtual hub, then choose routes from ER connections.
-         * If all the routes are through remote virtual hubs, then choose routes from S2S VPN connections.
+   1. Prefer routes with the shortest BGP AS-Path length irrespective of the source of the route advertisements. Note: In vWANs with multiple remote virtual hubs, if there's a tie between remote ExpressRoute routes and remote site-to-site VPN routes, remote site-to-site VPN routes will be preferred.
+
+   1. Prefer routes from local virtual hub connections over routes learned from remote virtual hub.
+   1. If there are routes from both ExpressRoute and Site-to-site VPN connections:
+
+      * If all the routes are local to the virtual hub, the routes from ExpressRoute connections will be chosen.
+      * If all the routes are through remote virtual hubs, the routes from Site-to-site VPN connections will be chosen.
 
 **Things to note:**
 
 * When there are multiple virtual hubs in a Virtual WAN scenario, a virtual hub selects the best routes using the route selection algorithm described above, and then advertises them to the other virtual hubs in the virtual WAN.
-* For a given set of destination route-prefixes, if the ExpressRoute routes are preferred and the ExpressRoute connection subsequently goes down, then routes from S2S VPN or SD-WAN NVA connections will be preferred for traffic destined to the same route-prefixes. When the ExpressRoute connection is restored, traffic destined for these route-prefixes may continue to prefer the S2S VPN or SD-WAN NVA connections. To prevent this from happening, you need to configure your on-premises device to utilize AS-Path prepending for the routes being advertised to your S2S VPN Gateway and SD-WAN NVA, as you need to ensure the AS-Path length is longer for VPN/NVA routes than ExpressRoute routes. 
+* For a given set of destination route-prefixes, if the ExpressRoute routes are preferred and the ExpressRoute connection subsequently goes down, then routes from S2S VPN or SD-WAN NVA connections will be preferred for traffic destined to the same route-prefixes. When the ExpressRoute connection is restored, traffic destined for these route-prefixes might continue to prefer the S2S VPN or SD-WAN NVA connections. To prevent this from happening, you need to configure your on-premises device to utilize AS-Path prepending for the routes being advertised to your S2S VPN Gateway and SD-WAN NVA, as you need to ensure the AS-Path length is longer for VPN/NVA routes than ExpressRoute routes.
 
 ## Routing scenarios
 
 Virtual WAN hub routing preference is beneficial when multiple on-premises are advertising routes to same destination prefixes, which can happen in customer Virtual WAN scenarios that use any of the following setups.
 
-* Virtual WAN hub using ER connections as primary and VPN connections as back-up.
+* Virtual WAN hub using ER connections as primary and VPN connections as backup.
 * Virtual WAN with connections to multiple on-premises and customer is using one on-premises site as active, and another as standby for a service deployed using the same IP address ranges in both the sites.
 * Virtual WAN has both VPN and ER connections simultaneously and the customer is distributing services across connections by controlling route advertisements from on-premises.
 
-The example below is a hypothetical Virtual WAN deployment that encompasses multiple scenarios described above. We'll use it to demonstrate the route selection by a virtual hub.
+The following example is a hypothetical Virtual WAN deployment that encompasses multiple scenarios described earlier. We'll use it to demonstrate the route selection by a virtual hub.
 
 A brief overview of the setup:
 
@@ -68,7 +71,7 @@ A brief overview of the setup:
 
    :::image type="content" source="./media/about-virtual-hub-routing-preference/diagram.png" alt-text="Example diagram for hub-route-preference scenario." lightbox="./media/about-virtual-hub-routing-preference/diagram.png":::
 
-Let’s say there are flows from a virtual network VNET1 connected to Hub_1 to various destination route-prefixes advertised by the on-premises. The path that each of those flows takes for different configurations of Virtual WAN **hub routing preference** on Hub_1 and Hub_2 is described in the tables below. The paths have been labeled in the diagram and referred to in the tables below for ease of understanding.
+Let’s say there are flows from a virtual network VNET1 connected to Hub_1 to various destination route-prefixes advertised by the on-premises. The path that each of those flows takes for different configurations of Virtual WAN **hub routing preference** on Hub_1 and Hub_2 is described in the following tables. The paths have been labeled in the diagram and referred to in the tables for ease of understanding.
 
 **When only local routes are available:**
 

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

@@ -5,7 +5,7 @@ author: cherylmc
 ms.service: virtual-wan
 ms.custom: devx-track-azurepowershell
 ms.topic: faq
-ms.date: 10/30/2023
+ms.date: 03/27/2024
 ms.author: cherylmc
 # Customer intent: As someone with a networking background, I want to read more details about Virtual WAN in a FAQ format.
 ---
@@ -46,7 +46,7 @@ Virtual WAN supports [Azure VPN client](https://go.microsoft.com/fwlink/?linkid=
 
 ### For User VPN (point-to-site)- why is the P2S client pool split into two routes?
 
-Each gateway has two instances, the split happens so that each gateway instance can independently allocate client IPs for connected clients and traffic from the virtual network is routed back to the correct gateway instance to avoid inter-gateway instance hop.
+Each gateway has two instances. The split happens so that each gateway instance can independently allocate client IPs for connected clients and traffic from the virtual network is routed back to the correct gateway instance to avoid inter-gateway instance hop.
 
 ### How do I add DNS servers for P2S clients?
 
@@ -311,32 +311,7 @@ Yes. Customers can now create more than one hub in the same region for the same
 
 ### How does the virtual hub in a virtual WAN select the best path for a route from multiple hubs?
 
-If a virtual hub learns the same route from multiple remote hubs, the order in which it decides is as follows:
-1.	Select routes with Longest Prefix Match (LPM).
-2.	Prefer static routes learned from the virtual hub route table over BGP routes.
-3.	Select best path based on the [Virtual hub routing preference](about-virtual-hub-routing-preference.md) configuration. There are three possible configurations for Virtual hub routing preference and the route preference changes accordingly.
-
-    * **ExpressRoute** (This is the default setting)
-        1.	Prefer routes from local virtual hub connections over routes learned from remote virtual hub.
-        2. If there are Routes from both ExpressRoute and Site-to-site VPN connections:
-              * If all the routes are local to the virtual hub, the routes learned from ExpressRoute connections will be chosen because Virtual hub routing preference is set to ExpressRoute.
-              * If all the routes are through remote hubs, Site-to-site VPN will be preferred over ExpressRoute. 
-        3.	Prefer routes with the shortest BGP AS-Path length.
-
-    * **VPN**
-        1.	Prefer routes from local virtual hub connections over routes learned from remote virtual hub.
-        2.	If there are routes from both ExpressRoute and Site-to-site VPN connections, the Site-to-site VPN routes will be chosen.
-        3.	Prefer routes with the shortest BGP AS-Path length.
-
-    * **AS Path**
-        1.	Prefer routes with the shortest BGP AS-Path length irrespective of the source of the route advertisements. 
-         Note: In vWANs with multiple remote virtual hubs, If there's a tie between remote routes and remote site-to-site VPN routes. Remote site-to-site VPN will be preferred.
-
-        2.	Prefer routes from local virtual hub connections over routes learned from remote virtual hub.
-        3.	If there are routes from both ExpressRoute and Site-to-site VPN connections:
-            *	If all the routes are local to the virtual hub, the routes from ExpressRoute connections will be chosen.
-            * If all the routes are through remote virtual hubs, the routes from Site-to-site VPN connections will be chosen.
-
+For information, see the  [Virtual hub routing preference](about-virtual-hub-routing-preference.md) page. 
 
 ### Does the Virtual WAN hub allow connectivity between ExpressRoute circuits?
 
@@ -374,7 +349,7 @@ The current behavior is to prefer the ExpressRoute circuit path for standalone (
 
 In Azure portal, the **Allow traffic from remote Virtual WAN networks** and **Allow traffic from non Virtual WAN networks** toggles allow connectivity between the standalone virtual network (VNet 4) and the spoke virtual networks directly connected to the Virtual WAN hub (VNet 2 and VNet 3). To allow this connectivity, both toggles need to be enabled: the **Allow traffic from remote Virtual WAN networks** toggle for the ExpressRoute gateway in the standalone virtual network and the **Allow traffic from non Virtual WAN networks** for the ExpressRoute gateway in the Virtual WAN hub. In the diagram below, if both of these toggles are enabled, then connectivity would be allowed between the standalone VNet 4 and the VNets directly connected to hub 2 (VNet 2 and VNet 3). If an Azure Route Server is deployed in standalone VNet 4, and the Route Server has [branch-to-branch](../route-server/quickstart-configure-route-server-portal.md#configure-route-exchange) enabled, then connectivity will be blocked between VNet 1 and standalone VNet 4. 
 
-Enabling or disabling the toggle will only affect the following traffic flow: traffic flowing between the Virtual WAN hub and standalone VNet(s) via the ExpressRoute circuit. Enabling or disabling the toggle will **not** incur downtime for all other traffic flows (Ex: on-premises site to spoke VNet 2 will not be impacted, VNet 2 to VNet 3 will not be impacted, etc). 
+Enabling or disabling the toggle will only affect the following traffic flow: traffic flowing between the Virtual WAN hub and standalone VNet(s) via the ExpressRoute circuit. Enabling or disabling the toggle will **not** incur downtime for all other traffic flows (Ex: on-premises site to spoke VNet 2 won't be impacted, VNet 2 to VNet 3 won't be impacted, etc). 
 
 :::image type="content" source="./media/virtual-wan-expressroute-portal/expressroute-bowtie-virtual-network-virtual-wan.png" alt-text="Diagram of a standalone virtual network connecting to a virtual hub via ExpressRoute circuit." lightbox="./media/virtual-wan-expressroute-portal/expressroute-bowtie-virtual-network-virtual-wan.png":::
 
@@ -433,7 +408,7 @@ Yes, BGP communities generated by on-premises will be preserved in Virtual WAN.
 
 ### Is there a way to change the ASN for a VPN gateway?
 
-No. Virtual WAN does not support ASN changes for VPN gateways.
+No. Virtual WAN doesn't support ASN changes for VPN gateways.
 
 ### In Virtual WAN, what are the estimated performances by ExpressRoute gateway SKU?
 
@@ -469,7 +444,7 @@ Additional things to note:
 
 * If you change your spoke virtual network's subscription status from disabled to enabled and then upgrade the virtual hub, you'll need to update your virtual network connection after the virtual hub upgrade (Ex: you can configure the virtual network connection to propagate to a dummy label).
 
-* If your hub is connected to a large number of spoke virtual networks (60 or more), then you may notice that 1 or more spoke VNet peerings will enter a failed state after the upgrade. To restore these VNet peerings to a successful state after the upgrade, you can configure the virtual network connections to propagate to a dummy label, or you can delete and recreate these respective VNet connections. 
+* If your hub is connected to a large number of spoke virtual networks (60 or more), then you might notice that 1 or more spoke VNet peerings will enter a failed state after the upgrade. To restore these VNet peerings to a successful state after the upgrade, you can configure the virtual network connections to propagate to a dummy label, or you can delete and recreate these respective VNet connections. 
 
 ### Is there a route limit for OpenVPN clients connecting to an Azure P2S VPN gateway?
 
@@ -504,7 +479,7 @@ At this time, advanced notification can't be enabled for the maintenance of Netw
 
 At this time, you need to configure a minimum of a five hour window in your preferred time zone.
 
-### Can I configure a maintenance schedule that does not repeat daily?
+### Can I configure a maintenance schedule that doesn't repeat daily?
 
 At this time, you need to configure a daily maintenance window.