fixed typo;

:q

:wq

f

Author: wtnlee

articles/virtual-wan/whats-new.md

@@ -91,7 +91,7 @@ The following features are currently in gated public preview. After working with
 
 |#|Issue|Description |Date first reported|Mitigation|
 |---|---|---|---|---|
-|1|Connectivity to Azure Storage accounts deployed in the same region as your Virtual WAN hub bypasses Virtual WAN routing configuration.|f you configure Virtual WAN to route internet-bound traffic to a security-inspection appliance deployed in the Virtual WAN hub or in a spoke Virtual Network connected to a Virtual WAN hub, storage account traffic destined for a storage account in the same Azure region bypasses the security-inspection appliance. In Secure Hub deployments, ExpressRoute on-premises connected to hubs with this configuration may not be able to access to Azure Storage accounts at all. | May 2021| 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.|
+|1|Connectivity to Azure Storage accounts deployed in the same region as your Virtual WAN hub bypasses Virtual WAN routing configuration.|If you configure Virtual WAN to route internet-bound traffic to a security-inspection appliance deployed in the Virtual WAN hub or in a spoke Virtual Network connected to a Virtual WAN hub, storage account traffic destined for a storage account in the same Azure region as the Virtual WAN hub bypasses the security-inspection appliance. In Secure Hub deployments, ExpressRoute on-premises connected to hubs with this configuration may not be able to access to Azure Storage accounts at all. | September 2023| 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.|
 |2| 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. |
 |3| Two ExpressRoute circuits in the same peering location connected to multiple hubs |If you have two ExpressRoute circuits in the same peering location, and both of these circuits are connected to multiple virtual hubs in the same Virtual WAN, then connectivity to your Azure resources might be impacted. | July 2023 | Make sure each virtual hub has at least 1 virtual network connected to it. This ensures connectivity to your Azure resources. The Virtual WAN team is also working on a fix for this issue. |
 |4| ExpressRoute ECMP Support | Today, ExpressRoute ECMP isn't enabled by default for virtual hub deployments. When multiple ExpressRoute circuits are connected to a Virtual WAN hub, ECMP enables traffic from spoke virtual networks to on-premises over ExpressRoute to be distributed across all ExpressRoute circuits advertising the same on-premises routes. | | To enable ECMP for your environment, you can create a [route-map](route-maps-how-to.md) for your virtual hub. When you create a route-map, your virtual hub will automatically be upgraded to the latest software version that supports ECMP, regardless of whether this route-map is applied on any connections. As a result, you only need to follow steps 1-7 [here](route-maps-how-to.md#configuration-workflow). If you do not plan to use the route-map, you can delete the route-map after step 7 is complete, as hubs with a route-map will incur additional cost. It is also recommended to first try creating a route-map in your test environment and validating routing and connectivity before creating a route-map in your production environment.  |