Merge pull request #227201 from cherylmc/freshness2

freshness updates

Author: denrea

articles/virtual-wan/about-client-address-pools.md

@@ -2,11 +2,10 @@
 title: 'About client address pools for P2S User VPN'
 titleSuffix: Azure Virtual WAN
 description: Learn about client address pools for User VPN P2S.
-services: virtual-wan
 author: cherylmc
 ms.service: virtual-wan
 ms.topic: conceptual
-ms.date: 07/29/2021
+ms.date: 02/13/2023
 ms.author: cherylmc
 
 ---
@@ -16,7 +15,7 @@ This article describes Virtual WAN guidelines and requirements for allocating cl
 
 ## Background
 
-Point-to-site VPN gateways in the Virtual WAN hub are deployed with one or more highly-available gateway instances. Each instance of a point-to-site VPN gateway can support up to 10,000 concurrent connections.
+Point-to-site VPN gateways in the Virtual WAN hub are deployed with one or more highly available gateway instances. Each instance of a point-to-site VPN gateway can support up to 10,000 concurrent connections.
 
 As a result, for scale units greater than 40 (support for more than 10,000 concurrent connections), Virtual WAN deploys an extra gateway instance to service every 10,000 additional connecting users.
 
@@ -60,7 +59,7 @@ The following table summarizes the available scale unit choices for Point-to-sit
 
 Point-to-site VPN address pool assignments are done automatically by Virtual WAN. See the following basic guidelines for specifying address pools.
 
-* One gateway instance allows for a maximum of 10,000 concurrent connections. As such, each address pool should contain at least 10,000 unique IPv4 addresses. If less than 10,000 addresses are assigned to each instance  incoming connections will be rejected after all allocated IP addresses have been assigned.
+* One gateway instance allows for a maximum of 10,000 concurrent connections. As such, each address pool should contain at least 10,000 unique IPv4 addresses. If less than 10,000 addresses are assigned to each instance, incoming connections will be rejected after all allocated IP addresses have been assigned.
 * Multiple address pool ranges are automatically combined and assigned to a **single** gateway instance. This process is done in a round-robin manner for any gateway instances that have less than 10,000 IP addresses. For example, a pool with 5,000 addresses can be combined automatically by Virtual WAN with another pool that has 8,000 addresses and is assigned to a single gateway instance.
 * A single address pool is only assigned to a single gateway instance by Virtual WAN.
 * Address pools must be distinct. There can be no overlap between address pools.

articles/virtual-wan/how-to-routing-policies.md

@@ -7,7 +7,7 @@ author: cherylmc
 
 ms.service: virtual-wan
 ms.topic: how-to
-ms.date: 05/26/2021
+ms.date: 02/13/2023
 ms.author: cherylmc
 
 ---

articles/virtual-wan/howto-firewall.md

@@ -1,12 +1,10 @@
 ---
 title: 'Architecture: Interconnect with China using Azure Virtual WAN and secure Hub'
 description: Learn how to interconnect with China using Azure Virtual WAN and a secured hub.
-services: virtual-wan
 author: skishen525
-
 ms.service: virtual-wan
 ms.topic: conceptual
-ms.date: 12/01/2020
+ms.date: 02/13/2023
 ms.author: sukishen
 
 ---
@@ -17,7 +15,7 @@ When looking at common automotive, manufacturing, logistics industries, or other
 
 In most of the cases, customers are struggling with high latencies, low bandwidth, unstable connection, and high costs connecting to outside of China (for example, Europe or the United States).
 
-A reason for these struggles is the "Great Firewall of China", which protects the Chinese part of the Internet and filters traffic to China. Nearly all traffic running from People's Republic of China to outside of China, except the special administration zones like Hong Kong and Macau, passes the Great Firewall. The traffic running through Hong Kong and Macau does not hit the Great Firewall in full force, it is handled by a subset of the Great Firewall.
+A reason for these struggles is the "Great Firewall of China", which protects the Chinese part of the Internet and filters traffic to China. Nearly all traffic running from People's Republic of China to outside of China, except the special administration zones like Hong Kong and Macau, passes the Great Firewall. The traffic running through Hong Kong and Macau doesn't hit the Great Firewall in full force, it's handled by a subset of the Great Firewall.
 
 :::image type="content" source="./media/interconnect-china/provider.png" alt-text="Diagram shows provider interconnect.":::
 
@@ -43,7 +41,7 @@ Depending on the provider and your needs, you now need to purchase one of the fo
 
 Next, you need to agree with that provider to give a breakout to the Microsoft Global Network and its Edge Network in Hong Kong, not in Beijing or Shanghai. In this case, Hong Kong is very important because of its physical connection and location to China.
 
-While most customers think using Singapore for interconnect is the best case because it looks nearer to China when looking on the map, this is not true. When you follow network fiber maps, nearly all network connects go through Beijing, Shanghai, and Hong Kong. This makes Hong Kong a better location choice to interconnect to China.
+While most customers think using Singapore for interconnect is the best case because it looks nearer to China when looking on the map, this isn't true. When you follow network fiber maps, nearly all network connects go through Beijing, Shanghai, and Hong Kong. This makes Hong Kong a better location choice to interconnect to China.
 
 Depending on the provider, you may get different service offerings. The table below shows an example of providers and the service they offer, based on information at the time this article was written.
 
@@ -90,17 +88,17 @@ A sample architecture could look like following example:
 
 :::image type="content" source="./media/interconnect-china/sample.png" alt-text="Diagram shows sample WAN.":::
 
-In this example, the China branches connect to Azure Cloud China and each other by using VPN or MPLS connections. Branches that need to be connected to Global Services use MPLS or Internet-based services that are connected directly to Hong Kong. If you want to use ExpressRoute in Hong Kong as well as in the other region, you need to configure [ExpressRoute Global Reach](../expressroute/expressroute-global-reach.md) to interconnect both ExpressRoute Circuits.
+In this example, the China branches connect to Azure Cloud China and each other by using VPN or MPLS connections. Branches that need to be connected to Global Services use MPLS or Internet-based services that are connected directly to Hong Kong. If you want to use ExpressRoute in Hong Kong and in the other region, you need to configure [ExpressRoute Global Reach](../expressroute/expressroute-global-reach.md) to interconnect both ExpressRoute Circuits.
 
-ExpressRoute Global Reach is not available in some regions. If you need to interconnect with Brazil or India, for example, you need to leverage [Cloud Exchange Providers](../expressroute/expressroute-locations.md#connectivity-through-exchange-providers) to provide the routing services.
+ExpressRoute Global Reach isn't available in some regions. If you need to interconnect with Brazil or India, for example, you need to leverage [Cloud Exchange Providers](../expressroute/expressroute-locations.md#connectivity-through-exchange-providers) to provide the routing services.
 
 The figure below shows both examples for this scenario.
 
 :::image type="content" source="./media/interconnect-china/global.png" alt-text="Diagram shows Global Reach.":::
 
 ## <a name="secure"></a>Secure Internet breakout for Microsoft 365
 
-Another consideration is network security as well as logging for the entry point between China and the Virtual WAN established backbone component, and the customer backbone. In most cases, there is a need to breakout to the Internet in Hong Kong to directly reach the Microsoft Edge Network and, with that, the Azure Front Door Servers used for Microsoft 365 Services.
+Another consideration is network security and logging for the entry point between China and the Virtual WAN established backbone component, and the customer backbone. In most cases, there is a need to breakout to the Internet in Hong Kong to directly reach the Microsoft Edge Network and, with that, the Azure Front Door Servers used for Microsoft 365 Services.
 
 For both scenarios with Virtual WAN, you would leverage the [Azure Virtual WAN secured hub](../firewall-manager/secured-virtual-hub.md). Using Azure Firewall Manager, you can change a regular Virtual WAN hub to a secured hub, and then deploy and manage an Azure Firewall within that hub.
 
@@ -136,11 +134,11 @@ There are also options to terminate ExpressRoute from China, for example, in Sou
 
 This section discusses a design that where ExpressRoute is used for Hong Kong and other Branches. This option shows the interconnect using ExpressRoute on both ends. Here you have a different traffic flow than the other. The Microsoft 365 traffic will flow to the Azure virtual WAN secured hub and from there to the Microsoft Edge Network and the Internet.
 
-The traffic that goes to the interconnected branches or from them to the locations in China will follow a different approach within that architecture. Currently virtual WAN does not support ExpressRoute to ExpressRoute transit. The traffic will leverage ExpressRoute Global Reach or the 3rd Party interconnect without passing the virtual WAN Hub. It will directly flow from one Microsoft Enterprise Edge (MSEE) to another.
+The traffic that goes to the interconnected branches or from them to the locations in China will follow a different approach within that architecture. Currently virtual WAN doesn't support ExpressRoute to ExpressRoute transit. The traffic will leverage ExpressRoute Global Reach or the 3rd Party interconnect without passing the virtual WAN Hub. It will directly flow from one Microsoft Enterprise Edge (MSEE) to another.
 
 :::image type="content" source="./media/interconnect-china/expressroute-virtual.png" alt-text="Diagram shows ExpressRoute Global Reach.":::
 
-Currently ExpressRoute Global Reach is not available in every country/region, but you can configure a solution using Azure Virtual WAN.
+Currently ExpressRoute Global Reach isn't available in every country/region, but you can configure a solution using Azure Virtual WAN.
 
 You can, for example, configure an ExpressRoute with Microsoft Peering and connect a VPN tunnel through that peering to Azure Virtual WAN. Now you have enabled, again, the transit between VPN and ExpressRoute without Global Reach and 3rd party provider and service, such as Megaport Cloud.
 

articles/virtual-wan/interconnect-china.md

@@ -2,14 +2,11 @@
 title: 'Scenario: Azure Firewall custom routing for Virtual WAN'
 titleSuffix: Azure Virtual WAN
 description: Learn about routing scenarios to route traffic between VNets directly, but use Azure Firewall for VNet -> Internet/Branch and Branch to VNet traffic flows.
-services: virtual-wan
 author: cherylmc
-
 ms.service: virtual-wan
 ms.topic: conceptual
-ms.date: 04/27/2021
+ms.date: 02/13/2023
 ms.author: cherylmc
-ms.custom: fasttrack-edit
 
 ---
 # Scenario: Azure Firewall - custom
@@ -27,7 +24,7 @@ In order to figure out how many route tables will be needed, you can build a con
 | **VNets**      |   →|    Direct    |     AzFW      |     AzFW     |
 | **Branches**   |   →|    AzFW      |    Direct     |    Direct    |
 
-In the previous table, an "Direct" represents direct connectivity between two connections without the traffic traversing the Azure Firewall in Virtual WAN, and "AzFW" indicates that the flow will go through the Azure Firewall. Since there are two distinct connectivity patterns in the matrix, we will need two route tables that will be configured as follows:
+In the previous table, "Direct" represents direct connectivity between two connections without the traffic traversing the Azure Firewall in Virtual WAN, and "AzFW" indicates that the flow will go through the Azure Firewall. Since there are two distinct connectivity patterns in the matrix, we'll need two route tables that will be configured as follows:
 
 * Virtual networks:
   * Associated route table: **RT_VNet**
@@ -56,9 +53,9 @@ VPN, ExpressRoute, and User VPN connections are collectively called Branches and
 1. Add an aggregated static route for VNets into the **Default Route table** to activate the Branch-to-VNet flow via the Azure Firewall.
 
    * Remember, branches are associated and propagating to the default route table.
-   * Branches do not propagate to RT_VNet route table. This ensures the VNet-to-Branch traffic flow via the Azure Firewall.
+   * Branches don't propagate to RT_VNet route table. This ensures the VNet-to-Branch traffic flow via the Azure Firewall.
 
-This will result in the routing configuration changes as shown in **Figure 1**.
+This results in the routing configuration changes as shown in **Figure 1**.
 
 **Figure 1**