Merge pull request #271149 from siddomala/HRPga

prmerger-automator[bot] · web-flow · commit 0907f27c646b · 2024-04-03T22:24:47.000Z
vWAN doc updates
diff --git a/articles/virtual-wan/hub-settings.md b/articles/virtual-wan/hub-settings.md
@@ -27,6 +27,10 @@ When you deploy a new virtual hub, you can specify additional routing infrastruc
 
 When increasing the virtual hub capacity, the virtual hub router will continue to support traffic at its current capacity until the scale out is complete. It may take up to 25 minutes for the virtual hub router to scale out to additional routing infrastructure units. It's also important to note the following: currently, regardless of the number of routing infrastructure units deployed, traffic may experience performance degradation if more than 1.5 Gbps is sent in a single TCP flow. 
 
+> [!NOTE]
+> Regardless of the virtual hub's capacity, the hub can only accept a maximum of 10,000 routes from its connected resources (virtual networks, branches, other virtual hubs, etc).
+>
+
 ### Configure virtual hub capacity
 
 Capacity is configured on the **Basics** tab **Virtual hub capacity** setting when you create your virtual hub.
diff --git a/articles/virtual-wan/monitor-virtual-wan-reference.md b/articles/virtual-wan/monitor-virtual-wan-reference.md
@@ -54,7 +54,7 @@ $MetricInformation.Data
 
 * **Start Time and End Time** - This time is based on UTC. Ensure that you're entering UTC values when inputting these parameters. If these parameters aren't used, the past one hour's worth of data is shown by default.  
 
-* **Sum Aggregation Type** - This aggregation type shows you the total number of bytes that traversed the virtual hub router during a selected time period. The **Max** and **Min** aggregation types aren't meaningful. 
+* **Sum Aggregation Type** - The **sum** aggregation type shows you the total number of bytes that traversed the virtual hub router during a selected time period. For example, if you set the Time granularity to 5 minutes, each data point will correspond to the number of bytes sent in that 5 minute interval. To convert this to Gbps, you can divide this number by 37500000000. Based on the virtual hub's [capacity](hub-settings.md#capacity), the hub router can support between 3 Gbps and 50 Gbps. The **Max** and **Min** aggregation types aren't meaningful at this time. 
  
 
 ### <a name="s2s-metrics"></a>Site-to-site VPN gateway metrics
diff --git a/articles/virtual-wan/routing-deep-dive.md b/articles/virtual-wan/routing-deep-dive.md
@@ -58,7 +58,7 @@ Even if hub 1 knows the ExpressRoute prefix from circuit 2 (`10.5.2.0/24`) and h
 > [!IMPORTANT]
 > The previous diagram shows two secured virtual hubs, this topology is supported with Routing Intent. For more information see [How to configure Virtual WAN Hub routing intent and routing policies][virtual-wan-intent].
 
-As explained in [Virtual hub routing preference (Preview)][virtual-wan-hrp], Virtual WAN favors routes coming from ExpressRoute per default. Since routes are advertised from hub 1 to the ExpressRoute circuit 1, from the ExpressRoute circuit 1 to the circuit 2, and from the ExpressRoute circuit 2 to hub 2 (and vice versa), virtual hubs prefer this path over the more direct inter hub link now. The effective routes in hub 1 show this:
+As explained in [Virtual hub routing preference][virtual-wan-hrp], Virtual WAN favors routes coming from ExpressRoute per default. Since routes are advertised from hub 1 to the ExpressRoute circuit 1, from the ExpressRoute circuit 1 to the circuit 2, and from the ExpressRoute circuit 2 to hub 2 (and vice versa), virtual hubs prefer this path over the more direct inter hub link now. The effective routes in hub 1 show this:
 
 :::image type="content" source="./media/routing-deep-dive/virtual-wan-routing-deep-dive-scenario-2-er-hub-1.png" alt-text="Screenshot of effective routes in Virtual hub 1 with Global Reach and routing preference ExpressRoute." lightbox="./media/routing-deep-dive/virtual-wan-routing-deep-dive-scenario-2-er-hub-1-expanded.png":::
 
@@ -68,7 +68,7 @@ The effective routes in hub 2 will be similar:
 
 :::image type="content" source="./media/routing-deep-dive/virtual-wan-routing-deep-dive-scenario-2-er-hub-2.png" alt-text="Screenshot of effective routes in Virtual hub 2 with Global Reach and routing preference ExpressRoute." lightbox="./media/routing-deep-dive/virtual-wan-routing-deep-dive-scenario-2-er-hub-2-expanded.png":::
 
-The routing preference can be changed to VPN or AS-Path as explained in [Virtual hub routing preference (Preview)][virtual-wan-hrp]. For example, you can set the preference to VPN as shown in this image:
+The routing preference can be changed to VPN or AS-Path as explained in [Virtual hub routing preference][virtual-wan-hrp]. For example, you can set the preference to VPN as shown in this image:
 
 :::image type="content" source="./media/routing-deep-dive/virtual-wan-routing-deep-dive-scenario-2-set-hrp-vpn.png" alt-text="Screenshot of how to set hub routing preference in Virtual WAN to V P N." lightbox="./media/routing-deep-dive/virtual-wan-routing-deep-dive-scenario-2-set-hrp-vpn.png":::
 
diff --git a/articles/virtual-wan/scenario-route-through-nva.md b/articles/virtual-wan/scenario-route-through-nva.md
@@ -68,7 +68,7 @@ With that, the static routes that we need in the Default table to send traffic t
 | VNet 2       | Default     | 10.2.0.0/16 -> eastusconn |
 | VNet 4       | Default     | 10.4.0.0/16 -> weconn     |
 
-Now virtual WAN knows which connection to send the packets to, but the connection needs to know what to do when receiving those packets: This is where the connection route tables are used. Here we'll use the shorter prefixes (/24 instead of the longer /16), to make sure that these routes have preference over routes that are imported from the NVA VNets (VNet 2 and VNet 4):
+Now, these static routes will be advertised to your on-premises branches, and the Virtual WAN hub will know which VNet connection to forward traffic to. However, the VNet connection needs to know what to do when receiving this traffic: This is where the connection route tables are used. Here we'll use the shorter prefixes (/24 instead of the longer /16), to make sure that these routes have preference over routes that are imported from the NVA VNets (VNet 2 and VNet 4):
 
 | Description | Connection | Static route            |
 | ----------- | ---------- | ----------------------- |
diff --git a/articles/virtual-wan/virtual-wan-expressroute-portal.md b/articles/virtual-wan/virtual-wan-expressroute-portal.md
@@ -94,7 +94,7 @@ Once the gateway is created, you can connect an [ExpressRoute circuit](../expres
 
 ### To connect the circuit to the hub gateway
 
-In the portal, go to the **Virtual hub -> Connectivity -> ExpressRoute** page. If you have access in your subscription to an ExpressRoute circuit, you'll see the circuit you want to use in the list of circuits. If you don’t see any circuits, but have been provided with an authorization key and peer circuit URI, you can redeem and connect a circuit. See [To connect by redeeming an authorization key](#authkey).
+First, verify that your circuit's peering status is provisioned in the **ExpressRoute circuit -> Peerings** page in Portal. Then, go to the **Virtual hub -> Connectivity -> ExpressRoute** page. If you have access in your subscription to an ExpressRoute circuit, you'll see the circuit you want to use in the list of circuits. If you don’t see any circuits, but have been provided with an authorization key and peer circuit URI, you can redeem and connect a circuit. See [To connect by redeeming an authorization key](#authkey).
 
 1. Select the circuit.
 2. Select **Connect circuit(s)**.
