Merge pull request #265624 from halkazwini/rs-anycast

Route Server: Freshness: Anycast routing with Azure Route Server

Author: v-shils

articles/route-server/anycast.md

@@ -2,18 +2,17 @@
 title: Propagating anycast routes to on-premises
 titleSuffix: Azure Route Server
 description: Learn about advertising the same route from different regions with Azure Route Server.
-services: route-server
 author: halkazwini
-ms.service: route-server
-ms.topic: conceptual
-ms.date: 02/23/2023
 ms.author: halkazwini
-ms.custom: template-concept, engagement-fy23
+ms.service: route-server
+ms.topic: concept-article
+ms.date: 02/07/2024
+#CustomerIntent: As a <type of user>, I want <what?> so that <why?>.
 ---
 
 # Anycast routing with Azure Route Server
 
-You can deploy your application across [Availability Zones](../reliability/availability-zones-overview.md) in a single Azure region to achieve higher availability, but sometimes, you may need to deploy your applications in multiple regions, either to achieve a higher resiliency, a better performance for users across the globe, or better business continuity. There are different approaches that can be taken to direct users to one of the locations where a multi-region application is deployed to: DNS-based approaches such as [Azure Traffic Manager](../traffic-manager/traffic-manager-overview.md), routing-based services like [Azure Front Door](../frontdoor/front-door-overview.md), or the [Azure cross-region Load Balancer](../load-balancer/cross-region-overview.md).
+You can deploy your application across [Availability Zones](../reliability/availability-zones-overview.md?toc=/azure/route-server/toc.json) in a single Azure region to achieve higher availability, but sometimes, you might need to deploy your applications in multiple regions, either to achieve a higher resiliency, a better performance for users across the globe, or better business continuity. There are different approaches that can be taken to direct users to one of the locations where a multi-region application is deployed to: DNS-based approaches such as [Azure Traffic Manager](../traffic-manager/traffic-manager-overview.md?toc=/azure/route-server/toc.json), routing-based services like [Azure Front Door](../frontdoor/front-door-overview.md?toc=/azure/route-server/toc.json), or the [Azure cross-region Load Balancer](../load-balancer/cross-region-overview.md?toc=/azure/route-server/toc.json).
 
 The previous Azure services are recommended for getting users to the best application location over the public internet using public IP addressing, but they don't support private networks and IP addresses. This article explores the usage of a route-based approach (IP anycast) to provide multi-regional, private-networked application deployments.
 
@@ -23,7 +22,7 @@ IP anycast essentially consists of advertising exactly the same IP address from
 
 In the design of this scenario, the same IP address is advertised from virtual networks in different Azure regions, where network virtual appliances (NVAs) advertise the application's IP address through Azure Route Server. The following diagram depicts two simple hub and spoke topologies, each in a different Azure region. An NVA in each region advertises the same route (`a.b.c.d/32` in this example) to its local Azure Route Server (the route prefix must not overlap with Azure and on-premises networks). The routes are further propagated to the on-premises network through ExpressRoute. When application users want to access the application from on-premises, the DNS infrastructure (not covered by this document) resolves the DNS name of the application to the anycast IP address (`a.b.c.d`), which the on-premises network devices route to one of the two regions.
 
-:::image type="content" source="./media/anycast/anycast.png" alt-text="Diagram of anycast with Azure Route Server.":::
+:::image type="content" source="./media/anycast/anycast.png" alt-text="Diagram shows an example of using IP anycast with Azure Route Server.":::
 
 The decision of which of the available regions is selected is entirely based on routing attributes. If the routes from both regions are identical, the on-premises network typically uses equal-cost multi-path (ECMP) routing to send each application flow to each region. It's possible as well to modify the advertisements generated by each NVA in Azure to make one of the regions preferred. For example, using BGP AS Path prepending to establish a deterministic path from on-premises to the Azure workload.
 
@@ -32,11 +31,11 @@ The decision of which of the available regions is selected is entirely based on
 
 ## Return traffic
 
-When the application traffic from the on-premises client arrives to one of the NVAs in Azure, the NVA will either reverse-proxy the connection or perform Destination Network Address Translation (DNAT). Then, it sends the packets to the actual application, which typically resides in a spoke virtual network peered to the hub virtual network where the NVA is deployed. Traffic back from the application goes back through the NVA, which would happen naturally if the NVA is reverse-proxying the connection (or performs Source NAT additionally to Destination NAT).
+When the application traffic from the on-premises client arrives to one of the NVAs in Azure, the NVA either performs connection reverse-proxy or Destination Network Address Translation (DNAT). Then, it sends the packets to the actual application, which typically resides in a spoke virtual network peered to the hub virtual network where the NVA is deployed. Traffic back from the application goes back through the NVA, which would happen naturally if the NVA is reverse-proxying the connection (or performs Source NAT additionally to Destination NAT).
 
-Otherwise, traffic arriving to the application will still be sourced from the original on-premises client's IP address. In this case, packets can be routed back to the NVA with user-defined routes (UDRs). Special care must be taken if there are more than one NVA instance in each region, since traffic could be asymmetric (the inbound and outbound traffic going through different NVA instances). Asymmetric traffic is typically not an issue if NVAs are stateless, but it results in errors if NVAs keep track of connection states, such as firewalls. 
+Otherwise, traffic arriving to the application is still sourced from the original on-premises client's IP address. In this case, packets can be routed back to the NVA with user-defined routes (UDRs). Special care must be taken if there are more than one NVA instance in each region, since traffic could be asymmetric (the inbound and outbound traffic going through different NVA instances). Asymmetric traffic is typically not an issue if NVAs are stateless, but it results in errors if NVAs keep track of connection states, such as firewalls. 
 
-## Next steps
+## Related content
 
-* [Learn how Azure Route Server works with ExpressRoute](expressroute-vpn-support.md)
-* [Learn how to peer Azure Route Server with a network virtual appliance (NVA)](tutorial-configure-route-server-with-quagga.md)
+* [Learn how Azure Route Server works with ExpressRoute](expressroute-vpn-support.md).
+* [Learn how to peer Azure Route Server with a network virtual appliance (NVA)](tutorial-configure-route-server-with-quagga.md).