Merge pull request #289701 from wtnlee/monitoringfix

done

Author: prmerger-automator[bot]

articles/virtual-wan/how-to-network-virtual-appliance-inbound.md

@@ -57,8 +57,18 @@ The list below corresponds to the diagram above and describes the packet flow fo
 1. The server responds and sends the reply packets to the NVA Firewall instance over the Firewall private IP.
 1. The NAT translation is reversed and the response is sent out the untrusted interface. Azure then directly sends the packet back to the user.
 
-## Known Limitations and Considerations
+## Known Issues, Limitations and Considerations
 
+The following section describes known issues, limitations and considerations associatd with the Internet Inbound feature.
+
+### Known Issues
+
+The following table describes known issues related to the internet inbound/DNAT feature.
+
+|Issue | Description| Mitigation|
+|--|--|--|
+| DNAT traffic is not forwarded to the NVA after associating an additional IP address.| After associating additional IP address(es) to an NVA that already has active inbound security rules, DNAT traffic is not forwarded properly to the NVA due to a code defect. | Use partner orchestration/management software to modify (create or delete existing) configured inbound-security rules to restore connectivity. |
+|Inbound security rule configuration scalability| Inbound security rule configuration may fail when a large number (approximately 100)  rules are configured.| No mitigation, reach out to Azure Support for fix timelines.|
 ### Limitations
 
 * Destination NAT is supported only for the following NVAs: **checkpoint**, **fortinet-sdwan-and-ngfw** and **fortinet-ngfw**.
@@ -78,6 +88,10 @@ The list below corresponds to the diagram above and describes the packet flow fo
 * Timeout for idle flows is automatically set to 4 minutes.
 * You can assign individual IP address resources generated from an IP address prefix to the NVA as internet inbound IPs. Assign each IP address from the prefix individually.
 
+
+
+
+
 ## Managing DNAT/Internet Inbound configurations
 
 The following section describes how to manage NVA configurations related to internet inbound and DNAT.

articles/virtual-wan/how-to-routing-policies.md

@@ -87,7 +87,17 @@ Consider the following configuration where Hub 1 (Normal) and Hub 2 (Secured) ar
 
 ## <a name="knownlimitations"></a>  Known Limitations
 
-* Routing Intent is currently available in Azure public. Microsoft Azure operated by 21Vianet and Azure Government are currently in roadmap.
+* The following table describes the avaiablility of routing intent in different Azure environments.
+    * Routing intent is not available in Mirosoft Azure operated by 21 Vianet.
+    * Palo Alto Cloud NGFW is only available in Azure Public. Reach out to Palo Alto Networks regarding avaialbility of Cloud NGFW in Azure Government and Microsoft Azure operated by Viacom.
+    * Network Virtual Appliances are not available in all Azure Government regions. Contact your NVA partner regarding availability in Azure Government.  
+
+| Cloud Environment| Azure Firewall| Network Virtual Appliance| SaaS solutions|
+|--|--|--| --|
+| Azure Public | Yes | Yes | Yes|
+|Azure Government|Yes| Limited | No|
+|Microsoft Azure operated by 21 Vianet|No|No|No| 
+    
 * Routing Intent simplifies routing by managing route table associations and propagations for all connections (Virtual Network, Site-to-site VPN, Point-to-site VPN, and ExpressRoute). Virtual WANs with custom route tables and customized policies therefore can't be used with the Routing Intent constructs.
 * Encrypted ExpressRoute (Site-to-site VPN tunnels running over ExpressRoute circuits) is supported in hubs where routing intent is configured if Azure Firewall is configured to allow traffic between VPN tunnel endpoints (Site-to-site VPN Gateway private IP and on-premises VPN device private IP). For more information on the required configurations, see [Encrypted ExpressRoute with routing intent](#encryptedER).
 * The following connectivity use cases are **not** supported with Routing Intent:

articles/virtual-wan/monitor-virtual-wan-reference.md

@@ -30,6 +30,8 @@ This table contains more information about some of the metrics in the preceding
 |:-------|:------------|
 | **Routing Infrastructure Units** | The virtual hub's routing infrastructure units (RIU). The virtual hub's RIU determines how much bandwidth the virtual hub router can process for flows traversing the virtual hub router. The hub's RIU also determines how many VMs in spoke VNets the virtual hub router can support. For more information on routing infrastructure units, see [Virtual Hub Capacity](hub-settings.md#capacity).
 | **Spoke VM Utilization** | The 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. For example, if the hub's RIU is set to 2, which supports 2,000 spoke VMs, and 1,000 VMs are deployed across spoke virtual networks, this metric's value is approximately 50%.  |
+| **Count Of Routes Advertised To Peer** | The Virtual WAN hub router exchanges routes with all active instances of ExpressRoute gateways, VPN  gateways and NVAs deployed in the Virtual WAN hub or in a connected Virtual Network spoke. When the Virtual WAN hub router learns a  prefix with the same AS-PATH length from multiple peers, the router internally selects a peer to prefer for that specific route and re-advertises that route to all **other** peers (including the other gateway or NVA instance). This  internal route selection process occurs for every route processed and the selected instance can change due to various factors such as network changes or maintenance events. As a result the number of routes advertised to an individual peer may fluctuate. When this metric is viewed with the maximum aggregation, Azure Monitor displays the data associated with a **single** BGP session between the Virtual WAN hub router and gateway or NVA. To effectively monitor changes or potential issues in your network, apply a split in Azure Monitor on the Count of Routes Advertised to Peer metric on a per peer IP address and ensure that the total number of routes advertised to your ExpressRoute, VPN or NVA is stable or in-line with any network changes. The total count of routes advertised must be calculated manually as the Azure Monitor **sum**  aggregation type sums up data-points over the aggregation window, which  does not accurately reflect routes advertised count.   |
+
 
 ### <a name="s2s-metrics"></a>Supported metrics for microsoft.network/vpngateways
 

articles/virtual-wan/whats-new.md

@@ -98,6 +98,9 @@ The following features are currently in gated public preview. After working with
 | 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.|
 |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.|
 |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.|
+|10|  DNAT traffic is not forwarded to the NVA after associating an additional IP address.|After associating additional IP address(es) to an NVA that already has active inbound security rules, DNAT traffic is not forwarded properly to the NVA due to a code defect. | November 2024 | Use partner orchestration/management software to modify (create or delete existing) configured inbound-security rules to restore connectivity.|
+|11| Inbound security rule configuration scalability | Inbound security rule configuration may fail when a large number (approximately 100)  rules are configured. | November 2024  | None, reach out Azure Support for more information.|
+
 
 
 ## Next steps