acrolinx

Author: halkazwini

articles/route-server/multiregion.md

@@ -12,26 +12,26 @@ ms.custom: template-concept, engagement-fy23
 
 # Multi-region networking with Azure Route Server
 
-Applications with demanding high availability or disaster recovery requirements often require to be deployed in more than one Azure regions. In such cases, spoke virtual networks (VNets) in different regions need to communicate with each other. One way to enable this communication is by peering all the required spoke VNets to each other. However, this approach would bypass any central network virtual appliances (NVAs) such as firewalls in the hubs. An alternative is to use user-defined routes (UDRs) in the subnets where hub NVAs are deployed, but this can be challenging to maintain. Azure Route Server offers a dynamic alternative that adapts to topology changes automatically, without requiring manual intervention.
+Applications with demanding high availability or disaster recovery requirements often require to be deployed in more than one Azure regions. In such cases, spoke virtual networks (VNets) in different regions need to communicate with each other. One way to enable this communication is by peering all the required spoke VNets to each other. However, this approach would bypass any central network virtual appliances (NVAs) such as firewalls in the hubs. An alternative is to use user-defined routes (UDRs) in the subnets where hub NVAs are deployed, but maintaining UDRs can be challenging. Azure Route Server offers a dynamic alternative that adapts to topology changes automatically, without requiring manual intervention.
 
 ## Topology
 
 The following diagram shows a dual-region architecture, where a hub and spoke topology exists in each region, and the hub VNets are peered to each other via VNet global peering:
 
 :::image type="content" source="./media/multiregion/multiregion.png" alt-text="Diagram showing multi-region design with Azure Route Server.":::
 
-The NVA in each region learns the prefixes of the local hub and spoke VNets through the Azure Route Server and shares them with the NVA in the other region using BGP. To avoid routing loops, it is crucial to establish this communication between the NVAs using an encapsulation technology such as IPsec or Virtual eXtensible LAN (VXLAN).
+The NVA in each region learns the prefixes of the local hub and spoke VNets through the Azure Route Server and shares them with the NVA in the other region using BGP. To avoid routing loops, it's crucial to establish this communication between the NVAs using an encapsulation technology such as IPsec or Virtual eXtensible LAN (VXLAN).
 
 To enable Azure Route Server to advertise the prefixes of the spoke VNets to the local NVAs and inject the learned routes back into the spoke VNets, it's essential to use *Use remote virtual network's gateway or Route Server* setting for peering between the spoke VNets and the hub VNet.
 
-The NVAs advertises the routes they learn from the remote region to their local Route Server, which will then configure these routes in the local spoke VNets, attracting traffic accordingly. In cases where multiple NVAs exist in the same region (Route Server supports up to 8 BGP peers), AS path prepending can be utilized to make one of the NVAs preferred over the others, effectively establishing an active/standby NVA topology.
+The NVAs advertises the routes they learn from the remote region to their local Route Server, which will then configure these routes in the local spoke VNets, attracting traffic accordingly. In cases where multiple NVAs exist in the same region (Route Server supports up to eight BGP peers), AS path prepending can be utilized to make one of the NVAs preferred over the others, effectively establishing an active/standby NVA topology.
 
 > [!IMPORTANT]
 > To ensure that the local Route Server can learn the routes advertised by the NVA from the remote region, the NVA must remove the autonomous system number (ASN) 65515 from the AS path of the routes. This technique is sometimes referred to as "AS override" or "AS-path rewrite" in certain BGP platforms. Otherwise, the BGP loop prevention mechanism will prevent the local Route Server from learning those routes since it prohibits the learning of routes that already contain the local ASN.
 
 ## ExpressRoute
 
-The multi-region design can be combined with ExpressRoute or VPN gateways. The following diagram shows a topology including an ExpressRoute gateway connected to an on-premises network in one of the Azure regions. In this case, an overlay network over the ExpressRoute circuit will help to simplify the network, so that on-premises prefixes will only appear in Azure as advertised by the NVA (and not from the ExpressRoute gateway).
+The multi-region design can be combined with ExpressRoute or VPN gateways. The following diagram shows a topology including an ExpressRoute gateway connected to an on-premises network in one of the Azure regions. In this case, an overlay network over the ExpressRoute circuit helps to simplify the network, so that on-premises prefixes only appear in Azure as advertised by the NVA (and not from the ExpressRoute gateway).
 
 :::image type="content" source="./media/multiregion/multiregion-with-expressroute.png" alt-text="Diagram showing multi-region design with Route Server and ExpressRoute.":::