Merge pull request #287897 from siddomala/ARSdns

ASNs for vWAN routing

Author: prmerger-automator[bot]

articles/route-server/troubleshoot-route-server.md

@@ -47,6 +47,10 @@ If you advertise a route from your NVA to Route Server that is an exact prefix m
 
 If you associate a service endpoint policy to the RouteServerSubnet or GatewaySubnet, then communication may break between Azure's underlying management platform and these respective Azure services (Route Server and VPN/ExpressRoute gateway). This can cause these Azure resources to enter an unhealthy state, resulting in connectivity loss between your on-premises and Azure workloads.
 
+### Why do I lose connectivity after using custom DNS instead of the default (Azure-provided DNS) for Route Server's virtual network?
+
+For the virtual network that Route Server is deployed in, if you are not using default (Azure-provided) DNS, then make sure your custom DNS configuration is able to resolve public domain names. This ensures that Azure services (Route Server and VPN/ExpressRoute gateway) are able to communicate with Azure's underlying management plane. Please see the note about wildcard rules in the [Azure DNS Private Resolver documentation](../dns/private-resolver-endpoints-rulesets.md#rules).
+
 ### Why can't I TCP ping from my NVA to the BGP peer IP of the Route Server after I set up the BGP peering between them?
 
 In some NVAs, you need to add a static route to the Route Server subnet to be able to TCP ping the Route Server from the NVA and to avoid BGP peering flapping. For example, if the Route Server is in 10.0.255.0/27 and your NVA is in 10.0.1.0/24, you need to add the following route to the routing table in the NVA:

articles/virtual-wan/about-virtual-hub-routing-preference.md

@@ -54,6 +54,7 @@ You can select one of the three possible virtual hub routing preference configur
 * When there are multiple virtual hubs in a Virtual WAN scenario, a virtual hub selects the best routes using the route selection algorithm described above, and then advertises them to the other virtual hubs in the virtual WAN.
 * For a given set of destination route-prefixes, if the ExpressRoute routes are preferred and the ExpressRoute connection subsequently goes down, then routes from S2S VPN or SD-WAN NVA connections will be preferred for traffic destined to the same route-prefixes. When the ExpressRoute connection is restored, traffic destined for these route-prefixes might continue to prefer the S2S VPN or SD-WAN NVA connections. To prevent this from happening, you need to configure your on-premises device to utilize AS-Path prepending for the routes being advertised to your S2S VPN Gateway and SD-WAN NVA, as you need to ensure the AS-Path length is longer for VPN/NVA routes than ExpressRoute routes.
 * When processing routes from remote hubs, routes learnt from hubs with routing intent private routing policies are always preferred over routes from hubs without routing intent. This is to ensure customer traffic takes the secure path when a secure path is available. To avoid asymmetric routing, enable Routing Intent on all hubs in Virtual WAN.
+* When a Virtual WAN hub advertises a route to another Virtual WAN hub, this route will have the ASNs 65520-65520 prepended to its AS-Path. For more details on routing in Virtual WAN, please see [Virtual WAN routing deep dive](routing-deep-dive.md) and [View Virtual Hub Effective Routes](effective-routes-virtual-hub.md).
 
 ## Routing scenarios
 

includes/route-server-limits.md

@@ -9,13 +9,11 @@ ms.date: 09/18/2023
 |----------|-------|
 | Number of BGP peers | 8 |
 | Number of routes each BGP peer can advertise to Azure Route Server <sup>1</sup> | 1,000 |
-| Number of VMs in the virtual network (including peered virtual networks) that Azure Route Server can support <sup>2</sup> | 4,000 |
+| Number of VMs in the virtual network (including peered virtual networks) that Azure Route Server can support | 4,000 |
 | Number of virtual networks that Azure Route Server can support | 500 |
 | Number of total on-premises and Azure Virtual Network prefixes that Azure Route Server can support | 10,000 |
 
 <sup>1</sup> If your NVA advertises more routes than the limit, the BGP session gets dropped.
 
-<sup>2</sup> The number of VMs that Azure Route Server can support isn’t a hard limit and it depends on the availability and performance of the underlying infrastructure.
-
 > [!NOTE]
 > The total number of routes advertised from VNet address space and Route Server towards ExpressRoute circuit, when [Branch-to-branch](/azure/route-server/quickstart-configure-route-server-portal#configure-route-exchange) enabled, must not exceed 1,000. For more information, see [Route advertisement limits](/azure/azure-resource-manager/management/azure-subscription-service-limits#expressroute-limits) of ExpressRoute.