Merge pull request #239157 from cherylmc/vwan-static

propagate static route

Author: prmerger-automator[bot]

articles/virtual-wan/howto-connect-vnet-hub-powershell.md

@@ -6,17 +6,18 @@ author: reasuquo
 ms.service: virtual-wan
 ms.custom: devx-track-azurepowershell
 ms.topic: how-to
-ms.date: 05/13/2022
+ms.date: 05/24/2023
 ms.author: reasuquo
 ---
 # Connect a virtual network to a Virtual WAN hub - PowerShell
 
-This article helps you connect your virtual network to your virtual hub using PowerShell. You can also use the [Azure portal](howto-connect-vnet-hub.md) to complete this task. Repeat these steps for each VNet that you want to connect.
+This article helps you connect your virtual network to your virtual hub using PowerShell. Repeat these steps for each VNet that you want to connect.
 
 > [!NOTE]
 >
 > * A virtual network can only be connected to one virtual hub at a time.
 > * In order to connect it to a virtual hub, the remote virtual network can't have a gateway.
+> * Some configuration settings, such as **Propagate static route**, can only be configured in the Azure portal at this time. See the [Azure portal](howto-connect-vnet-hub.md) version of this article for steps.
 
 > [!IMPORTANT]
 > If VPN gateways are present in the virtual hub, this operation as well as any other write operation on the connected VNet can cause disconnection to point-to-site clients as well as reconnection of site-to-site tunnels and BGP sessions.

articles/virtual-wan/howto-connect-vnet-hub.md

@@ -5,7 +5,7 @@ description: Learn how to connect a VNet to a Virtual WAN hub using the portal.
 author: cherylmc
 ms.service: virtual-wan
 ms.topic: how-to
-ms.date: 10/18/2022
+ms.date: 05/24/2023
 ms.author: cherylmc
 
 ---

articles/virtual-wan/whats-new.md

@@ -4,7 +4,7 @@ description: Learn what's new with Azure Virtual WAN such as the latest release
 author: cherylmc
 ms.service: virtual-wan
 ms.topic: conceptual
-ms.date: 05/08/2023
+ms.date: 05/24/2023
 ms.author: cherylmc
 ---
 
@@ -80,24 +80,24 @@ The following features are currently in gated public preview. After working with
 
 |Type of preview|Feature |Description|Contact alias|Limitations|
 |---|---|---|---|---|
-| Managed preview | Route-maps | This feature allows you to preform route aggregation, route filtering, and modify BGP attributes for your routes in Virtual WAN. | [email protected] | Known limitations are displayed here: [About Route-maps (preview)](route-maps-about.md#key-considerations).
+| Managed preview | Route-maps | This feature allows you to perform route aggregation, route filtering, and modify BGP attributes for your routes in Virtual WAN. | [email protected] | Known limitations are displayed here: [About Route-maps (preview)](route-maps-about.md#key-considerations).
 |Managed preview|Configure user groups and IP address pools for P2S User VPNs| This feature allows you to configure P2S User VPNs to assign users IP addresses from specific address pools based on their identity or authentication credentials by creating **User Groups**.|| Known limitations are displayed here: [Configure User Groups and IP address pools for P2S User VPNs (preview)](user-groups-create.md).|
 |Managed preview|Aruba EdgeConnect SD-WAN| Deployment of Aruba EdgeConnect SD-WAN NVA into the Virtual WAN hub| [email protected]| |
 |Managed preview|Checkpoint NGFW|Deployment of Checkpoint NGFW NVA into the Virtual WAN hub|[email protected], [email protected]|Same limitations as routing intent. Doesn't support internet inbound scenario.|
 |Managed preview|Fortinet NGFW/SD-WAN|Deployment of Fortinet dual-role SD-WAN/NGFW NVA into the Virtual WAN hub|[email protected], [email protected]|Same limitations as routing intent. Doesn't support internet inbound scenario.|
-|Public preview/Self serve|Virtual hub routing preference|This feature allows you to influence routing decisions for the virtual hub router. For more information, see [Virtual hub routing preference](about-virtual-hub-routing-preference.md).|For questions or feedback, contact [email protected]|If a route-prefix is reachable via ER or VPN connections, and via virtual hub SD-WAN NVA, then the latter route is ignored by the route-selection algorithm. Therefore, the flows to prefixes reachable only via virtual hub. SD-WAN NVA will take the route through the NVA. This is a limitation during the preview phase of the hub routing preference feature.|
+|Public preview/Self serve|Virtual hub routing preference|This feature allows you to influence routing decisions for the virtual hub router. For more information, see [Virtual hub routing preference](about-virtual-hub-routing-preference.md).|For questions or feedback, contact [email protected]|If a route-prefix is reachable via ER or VPN connections, and via virtual hub SD-WAN NVA, then the latter route is ignored by the route-selection algorithm. Therefore, the flows to prefixes reachable only via virtual hub. SD-WAN NVA takes the route through the NVA. This is a limitation during the preview phase of the hub routing preference feature.|
 |Public preview/Self serve|Hub-to-hub traffic flows instead of an ER circuit connected to different hubs (Hub-to-hub over ER)|This feature allows traffic between 2 hubs traverse through the Azure Virtual WAN router in each hub and uses a hub-to-hub path, instead of the ExpressRoute path (which traverses through Microsoft's edge routers/MSEE). For more information, see the [Hub-to-hub over ER](virtual-wan-faq.md#expressroute-bow-tie) preview link.|For questions or feedback, contact [email protected]|
 
 ## Known issues
 
 |#|Issue|Description |Date first reported|Mitigation|
 |---|---|---|---|---|
-|1|Virtual hub upgrade to VMSS-based infrastructure: Compatibility with NVA in a hub.|For deployments with an NVA provisioned in the hub, the virtual hub router can't be upgraded to Virtual Machine Scale Sets.| July 2022|The Virtual WAN team is working on a fix that will allow Virtual hub routers to be upgraded to Virtual Machine Scale Sets, even if an NVA is provisioned in the hub. After you upgrade the hub router, you will have to re-peer the NVA with the hub router’s new IP addresses (instead of having to delete the NVA).|
-|2|Virtual hub upgrade to VMSS-based infrastructure: Compatibility with NVA in a spoke VNet.|For deployments with an NVA provisioned in a spoke VNet, the customer will have to delete and recreate the BGP peering with the spoke NVA.|March 2022|The Virtual WAN team is working on a fix to remove the need for users to delete and recreate the BGP peering with a spoke NVA after upgrading.|
-|3|Virtual hub upgrade to VMSS-based infrastructure: Compatibility with spoke VNets in different regions |If your Virtual WAN hub is connected to a combination of spoke virtual networks in the same region as the hub and a separate region than the hub, then you may experience a lack of connectivity to these respective spoke virtual networks after upgrading your hub router to VMSS-based infrastructure.|March 2023|To resolve this and restore connectivity to these virtual networks, you can modify any of the virtual network connection properties (For example, you can modify the connection to propagate to a dummy label). We are actively working on removing this requirement. |
+|1|Virtual hub upgrade to VMSS-based infrastructure: Compatibility with NVA in a hub.|For deployments with an NVA provisioned in the hub, the virtual hub router can't be upgraded to Virtual Machine Scale Sets.| July 2022|The Virtual WAN team is working on a fix that will allow Virtual hub routers to be upgraded to Virtual Machine Scale Sets, even if an NVA is provisioned in the hub. After you upgrade the hub router, you'll have to re-peer the NVA with the hub router’s new IP addresses (instead of having to delete the NVA).|
+|2|Virtual hub upgrade to VMSS-based infrastructure: Compatibility with NVA in a spoke VNet.|For deployments with an NVA provisioned in a spoke VNet, you will have to delete and recreate the BGP peering with the spoke NVA.|March 2022|The Virtual WAN team is working on a fix to remove the need for users to delete and recreate the BGP peering with a spoke NVA after upgrading.|
+|3|Virtual hub upgrade to VMSS-based infrastructure: Compatibility with spoke VNets in different regions |If your Virtual WAN hub is connected to a combination of spoke virtual networks in the same region as the hub and a separate region than the hub, then you may experience a lack of connectivity to these respective spoke virtual networks after upgrading your hub router to VMSS-based infrastructure.|March 2023|To resolve this and restore connectivity to these virtual networks, you can modify any of the virtual network connection properties (For example, you can modify the connection to propagate to a dummy label). We're actively working on removing this requirement. |
 |4|Virtual hub upgrade to VMSS-based infrastructure: Compatibility with more than 100 spoke VNets |If your Virtual WAN hub is connected to more than 100 spoke VNets, then the upgrade may time out, causing your virtual hub to remain on Cloud Services-based infrastructure.|March 2023|The Virtual WAN team is working on a fix to support upgrades when there are more than 100 spoke VNets connected.|
 |5|ExpressRoute connectivity with Azure Storage and the 0.0.0.0/0 route|If you have configured a 0.0.0.0/0 route statically in a virtual hub route table or dynamically via a network virtual appliance for traffic inspection, that traffic will bypass inspection when destined for Azure Storage and is in the same region as the ExpressRoute gateway in the virtual hub. As a workaround, you can either use [Private Link](../private-link/private-link-overview.md) to access Azure Storage or put the Azure Storage service in a different region than the virtual hub.|
-
+|6| Default routes (0/0) won't propagate inter-hub |0/0 routes won't propagate between two virtual WAN hubs. | June 2020 |  None. Note: While the Virtual WAN team has fixed the issue, wherein static routes defined in the static route section of the VNet peering page propagate to route tables listed in "propagate to route tables" or the labels listed in "propagate to route tables" on the VNet connection page, default routes (0/0) won't propagate inter-hub. |
 ## Next steps
 
 For more information about Azure Virtual WAN, see [What is Azure Virtual WAN](virtual-wan-about.md) and [frequently asked questions- FAQ](virtual-wan-faq.md).

includes/virtual-wan-connect-vnet-hub-include.md

@@ -1,7 +1,7 @@
 ---
 author: cherylmc
 ms.author: cherylmc
-ms.date: 10/17/2022
+ms.date: 05/24/2023
 ms.service: virtual-wan
 ms.topic: include
 
@@ -23,4 +23,5 @@ ms.topic: include
    * **Propagate to labels**: Labels are a logical group of route tables. For this setting, select from the dropdown.
    * **Static routes**: Configure static routes, if necessary. Configure static routes for Network Virtual Appliances (if applicable). Virtual WAN supports a single next hop IP for static route in a virtual network connection. For example, if you have a separate virtual appliance for ingress and egress traffic flows, it would be best to have the virtual appliances in separate VNets and attach the VNets to the virtual hub.
    * **Bypass Next Hop IP for workloads within this VNet**: This setting lets you deploy NVAs and other workloads into the same VNet without forcing all the traffic through the NVA. This setting can only be configured when you're configuring a new connection. If you want to use this setting for a connection you've already created, delete the connection, then add a new connection.
+   * **Propagate static route**: This setting is currently being rolled out. This setting lets you propagate static routes defined in the **Static routes** section to route tables specified in **Propagate to Route Tables**. Additionally, routes will be propagated to route tables that have labels specified as **Propagate to labels**. These routes can be propagated inter-hub, except for the default route 0/0.
 1. Once you've completed the settings you want to configure, click **Create** to create the connection.