You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/virtual-wan/whats-new.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,8 +25,8 @@ You can also find the latest Azure Virtual WAN updates and subscribe to the RSS
25
25
26
26
| Type |Area |Name |Description | Date added | Limitations |
27
27
| --- |---|---|---|---|---|
28
-
| Metric| Routing | [New Virtual Hub Metrics](monitor-virtual-wan-reference.md#hub-router-metrics)| There are now two additional Virtual WAN hub metrics that display the virtual hub's capacity and spoke VM utilization: **Routing Infrastructure Units** and **Spoke VM Utilization**.| August 2024 | The **Spoke VM Utilization** metric represents an approximate number of deployed spoke VMs as a percentage of the total number of spoke VMs that the hub's routing infrastructure units can support.
29
-
| Feature| Routing |[Routing intent](how-to-routing-policies.md)| Routing intent is the mechanism through which you can configure Virtual WAN to send private or internet traffic via a security solution deployed in the hub.|May 2023|Routing Intent is Generally Available in Azure public cloud. See documentation for [additional limitations](how-to-routing-policies.md#knownlimitations).|
28
+
| Metric| Routing | [New Virtual Hub Metrics](monitor-virtual-wan-reference.md#hub-router-metrics)| There are now two new Virtual WAN hub metrics that display the virtual hub's capacity and spoke VM utilization: **Routing Infrastructure Units** and **Spoke VM Utilization**.| August 2024 | The **Spoke VM Utilization** metric represents an approximate number of deployed spoke VMs as a percentage of the total number of spoke VMs that the hub's routing infrastructure units can support.
29
+
| Feature| Routing |[Routing intent](how-to-routing-policies.md)| Routing intent is the mechanism through which you can configure Virtual WAN to send private or internet traffic via a security solution deployed in the hub.|May 2023|Routing Intent is Generally Available in Azure public cloud. See documentation for [other limitations](how-to-routing-policies.md#knownlimitations).|
30
30
|Feature| Routing |[Virtual hub routing preference](about-virtual-hub-routing-preference.md)|Hub routing preference gives you more control over your infrastructure by allowing you to select how your traffic is routed when a virtual hub router learns multiple routes across S2S VPN, ER, and SD-WAN NVA connections. |October 2022||
31
31
|Feature| Routing|[Bypass next hop IP for workloads within a spoke VNet connected to the virtual WAN hub generally available](how-to-virtual-hub-routing.md)|Bypassing next hop IP for workloads within a spoke VNet connected to the virtual WAN hub lets you deploy and access other resources in the VNet with your NVA without any additional configuration.|October 2022||
32
32
|SKU/Feature/Validation | Routing |[BGP end point (General availability)](scenario-bgp-peering-hub.md)| The virtual hub router now exposes the ability to peer with it, thereby exchanging routing information directly through Border Gateway Protocol (BGP) routing protocol. | June 2022 ||
@@ -94,10 +94,10 @@ The following features are currently in gated public preview. After working with
94
94
|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. |
95
95
|4| ExpressRoute ECMP Support | Today, ExpressRoute ECMP is not 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 Virtual WAN hub, please reach out to [email protected]. |
96
96
| 5| Virtual WAN hub address prefixes are not 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 VNET 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 VNET, manage NVAs or SaaS solutions using public IP. Support for Azure VNET orchestrators is on the roadmap.|
97
-
|6| Configuring routing intent to route between connectivity and firewall NVAs in the same Virtual WAN Hub| Virtual WAN routing intent private routing policy does not support routing between a 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).|
97
+
|6| Configuring routing intent to route between connectivity and firewall NVAs in the same Virtual WAN Hub| Virtual WAN routing intent private routing policy does not 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).|
98
98
| 7| BGP between the Virtual WAN hub router and NVAs deployed in the Virtual WAN hub does not 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 does not 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.|
99
99
|8| Advertising default route (0.0.0.0/0) from on-premises (VPN, ExpressRoute, BGP endpoint) or statically configured on a Virtual Network connection is not supported for forced tunneling use cases.| The 0.0.0.0/0 route advertised from on-premises (or statically configured on a Virtual Network connection) is not applied to the Azure Firewall or other security solutions deployed in the Virtual WAN hub. Packets inspected by the security solution in the hub are routed directly to the internet, bypassing the route learnt from on-premises||Publish the default route from on-premises only in non-secure hub scenarios.|
100
-
|9| Routing intent update operations fail in deployments where private routing policy next hop resource is a NVA or SaaS solution.| In deployments where private routing policy is configured with next hop NVA or SaaS solutions alongside additional private prefixes, modifying routing intent fails. Examples of operations that fail are adding or removing internet or private routing policies. This known issue doesn't impact deployments with no additional private prefixes configured. ||Remove any additional private prefixes, update routing intent and then re-configure additional private prefixes.|
100
+
|9| Routing intent update operations fail in deployments where private routing policy next hop resource is an NVA or SaaS solution.| In deployments where private routing policy is configured with next hop NVA or SaaS solutions alongside additional private prefixes, modifying routing intent fails. Examples of operations that fail are adding or removing internet or private routing policies. This known issue doesn't impact deployments with no additional private prefixes configured. ||Remove any additional private prefixes, update routing intent and then re-configure additional private prefixes.|
0 commit comments