Merge pull request #301087 from siddomala/ECMPcircuit

Updated ECMP docs

Author: prmerger-automator[bot]

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

@@ -349,7 +349,7 @@ For any reason, if the VPN connection becomes the primary medium for the virtual
 
 ### Does ExpressRoute support Equal-Cost Multi-Path (ECMP) routing in Virtual WAN?
 
-When 1 or more 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 and links advertising the same on-premises routes. ECMP is currently not enabled by default for Virtual WAN hubs. 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. 
+When 1 or more 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 2 ExpressRoute circuits (corresponding to up to 4 ExpressRoute links) advertising the same on-premises routes. ECMP is currently not enabled by default for Virtual WAN hubs. 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. 
 
 ### <a name="expressroute-bow-tie"></a>When two hubs (hub 1 and 2) are connected and there's an ExpressRoute circuit connected as a bow-tie to both the hubs, what is the path for a VNet connected to hub 1 to reach a VNet connected in hub 2?
 

articles/virtual-wan/whats-new.md

@@ -99,7 +99,7 @@ The following features are currently in gated public preview. After working with
 |1.2|Traffic from a Virtual Network connected to Virtual WAN destined to Azure Storage accounts deployed in the same region as your Virtual WAN hub bypasses Virtual WAN routing configuration.|Traffic from a Virtual Network connected to Virtual WAN destined for same region storage account public IP addresses bypasses Virtual WAN routing configurations to send traffic to a security appliance deployed in another Virutal WAN spoke Virtual Network.| September 2023| This issue applies to storage account access over public IP. Utilize [Private Link](../private-link/private-link-overview.md) to deploy private endpoints in spoke Virtual Networks connected to Virtual WAN hub to access storage accounts over private IP. If Private Link is not a technically feasible solution, deploy and configure routing to a security appliance in the hub as instead of another Virtual WAN spoke. This mitigation only applies to traffic from Virtual Networks and does **not** apply to traffic from on-premises. Reference Known Issue #1.1 for guidance related to on-premises connections.|
 |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 1 or more 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 and links 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.  |
+|4| ExpressRoute ECMP Support | Today, ExpressRoute ECMP isn't enabled by default for virtual hub deployments. When 1 or more 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 2 ExpressRoute circuits (corresponding to up to 4 ExpressRoute links) 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.  |
 | 5| Virtual WAN hub address prefixes aren't advertised to other Virtual WAN hubs in the same Virtual WAN.| You can't leverage Virtual WAN hub-to-hub full mesh routing capabilities to provide connectivity between  NVA orchestration software deployed in a virtual network or on-premises connected to a Virtual WAN hub to an Integrated NVA or SaaS solution deployed in a different Virtual WAN hub.  | | If your NVA or SaaS orchestrator is deployed on-premises, connect that on-premises site to all Virtual WAN hubs with NVAs or SaaS solutions deployed in them. If your orchestrator is in an Azure virtual network, manage NVAs or SaaS solutions using public IP. Support for Azure virtual network orchestrators is on the roadmap.|
 |6| Configuring routing intent to route between connectivity and firewall NVAs in the same Virtual WAN hub| Virtual WAN routing intent private routing policy doesn't support routing between an SD-WAN NVA and a Firewall NVA (or SaaS solution) deployed in the same Virtual hub.| | Deploy the connectivity and firewall integrated NVAs in two different hubs in the same Azure region. Alternatively, deploy the connectivity NVA to a spoke Virtual Network connected to your Virtual WAN hub and leverage the [BGP peering](scenario-bgp-peering-hub.md).|
 | 7| BGP between the Virtual WAN hub router and NVAs deployed in the Virtual WAN hub doesn't come up if the ASN used for BGP peering is updated post-deployment.|Virtual hub router expects NVA in the hub to use the ASN that was configured on the router when the NVA was first deployed. Updating the ASN associated with the NVA on the NVA resource doesn't properly register the new ASN with the Virtual hub router so the router rejects BGP sessions from the NVA if the NVA OS is configured to use the new ASN. | |Delete and recreate the NVA in the Virtual WAN hub with the correct ASN.|