Merge pull request #268445 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: Taojunshen

articles/networking/nva-accelerated-connections.md

@@ -49,8 +49,7 @@ Network Virtual Appliances (NVAs) with the largest scale workloads requiring vir
 * Feature support may vary as per the NVAs available on Marketplace.
 * Detaching and attaching a network interface on a VM requires stop-deallocate first. 
 * Marketplace portal isn't supported for the limited GA. Other tools such as templates, CLI, Terraform and other multi-cloud tools are supported. 
-* This feature is free during the limited GA, but chargeable after limited GA. 
-
+  
 ## Prerequisites
 
 The following section lists the required prerequisites:
@@ -71,10 +70,11 @@ This list will be updated as more regions become available. The following region
 * Central US
 * South UK
 * West Europe
+* Central India
 
 ## Supported SKUs
 
-This feature is supported on all SKUs supported by Accelerated Networking except the Dv5 VM family, which isn't yet supported during limited GA.
+This feature is supported on all SKUs supported by [Accelerated Networking](../virtual-network/accelerated-networking-overview.md) except the Dv5 VM family, which isn't yet supported during limited GA.
 
 ## Supported enablement methods
 

articles/virtual-wan/scenario-bgp-peering-hub.md

@@ -48,6 +48,8 @@ The virtual hub router now also exposes the ability to peer with it, thereby exc
    | Resource | Limit |
    |---|---|
    |  Number of routes each BGP peer can advertise to the virtual hub.| The hub can only accept a maximum number of 10,000 routes (total) from its connected resources. For example, if a virtual hub has a total of 6000 routes from the connected virtual networks, branches, virtual hubs etc., then when a new BGP peering is configured with an NVA, the NVA can only advertise up to 4000 routes. |
+   | Number of BGP peers | A maximum of 8 BGP peers can be connected to a single Virtual WAN Hub |
+
 * Routes from NVA in a virtual network that are more specific than the virtual network address space, when advertised to the virtual hub through BGP aren't propagated further to on-premises.
 * Currently we only support 4,000 routes from the NVA to the virtual hub.
 * Traffic destined for addresses in the virtual network directly connected to the virtual hub can't be configured to route through the NVA using BGP peering between the hub and NVA. This is because the virtual hub automatically learns about system routes associated with addresses in the spoke virtual network when the spoke virtual network connection is created. These automatically learned system routes are preferred over routes learned by the hub through BGP.