done

Author: wtnlee

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

@@ -57,8 +57,13 @@ 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
 
+### Known Issues
+|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 +83,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,19 @@ 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 **sum** of count of routes advertised to your ExpressRoute, VPN or NVA is stable or in-line with any network changes. |
+
 
 ### <a name="s2s-metrics"></a>Supported metrics for microsoft.network/vpngateways