Merge pull request #252464 from wtnlee/fixGR

fixed GR

Author: prmerger-automator[bot]

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

@@ -213,29 +213,34 @@ When a Virtual hub is configured with a Private Routing policy Virtual WAN adver
 
 ###  <a name="expressroute"></a> Transit connectivity between ExpressRoute circuits with routing intent
 
-Transit connectivity between ExpressRoute circuits within Virtual WAN is provided through ExpressRoute Global Reach capabilities. Traffic between Global Reach enabled ExpressRoute circuits is sent directly between the two circuits and doesn't transit the Virtual Hub.
+Transit connectivity between ExpressRoute circuits within Virtual WAN is provided through two different configurations. Because these two configurations are not compatible, customers should choose one configuration option to support transit connectivity between two ExpressRoute circuits.
 
->[!NOTE]
->However, you may raise a support case with Azure to one ExpressRoute circuit to send traffic to another ExpressRoute circuit via a security solution deployed in the hub with routing intent private routing policies. Note that this capability doesn't require Global Reach to be enabled on the circuit.
+> [!NOTE]
+> To enable ExpressRoute to ExpressRoute transit connectivity via a Firewall appliance in the hub with private routing policies, open a support case with Microsoft Support. Note that this option is not compatible with Global Reach and requires Global Reach to be disabled to ensure proper transit routing between all ExpressRoute circuits connected to Virtual WAN.
+
+*  **ExpressRoute Global Reach:**  ExpressRoute Global Reach allows two Global Reach-enabled circuits to send traffic between each other directly without transiting the Virtual Hub.  
+* **Routing Intent private routing policy:** Configuring private routing policies allows two ExpressRoute circuits to send traffic to each other via a security solution deployed in the hub.
 
-Connectivity across ExpressRoute circuits via a Firewall appliance in the hub is available in the following configurations:
+Connectivity across ExpressRoute circuits via a Firewall appliance in the hub with routing intent private routing policy is available in the following configurations:
 
 * Both ExpressRoute circuits are connected to the same hub and a private routing policy is configured on that hub.
-* ExpressRoute circuits are connected to different hubs and private routing policies are configured on both hubs. Therefore, both hubs must have a security solution deployed.
+* ExpressRoute circuits are connected to different hubs and a private routing policies are configured on both hubs. Therefore, both hubs must have a security solution deployed.
 
 #### Routing considerations with ExpressRoute
 
 > [!NOTE]
-> The routing considerations below apply to all Virtual hubs in the subscription(s) that are enabled by Microsoft Support to allow ExpressRoute to ExpressRoute connectivity via a security appliance in the hub. 
+> The routing considerations below apply to all Virtual hubs in the subscription(s) that are enabled by Microsoft Support to allow ExpressRoute to ExpressRoute connectivity via a security appliance in the hub.
 
 After transit connectivity across ExpressRoute circuits using a firewall appliance deployed in the Virtual Hub is enabled, you can expect the following changes in behavior in how routes are advertised to ExpressRoute on-premises:
+
 * Virtual WAN automatically advertises RFC1918 aggregate prefixes (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) to the ExpressRoute-connected on-premises. These aggregate routes are advertised in addition to the routes described in the previous section.
 * Virtual WAN automatically advertises all static routes in the defaultRouteTable to ExpressRoute circuit-connected on-premises. This means Virtual WAN advertises the routes specified in the private traffic prefix text box to on-premises.
 
  Because of these route advertisement changes, this means that ExpressRoute-connected on-premises can't advertise exact address ranges for RFC1918 aggregate address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Please ensure you're advertising more specific subnets (within RFC1918 ranges) as opposed to aggregate super-nets and any prefixes in the Private Traffic text box.
 
 Additionally, if your ExpressRoute circuit is advertising a non-RFC1918 prefix to Azure, please make sure the address ranges that you put in the Private Traffic Prefixes text box are less specific than ExpressRoute advertised routes. For example, if the ExpressRoute Circuit is advertising 40.0.0.0/24 from on-premises, put a /23 CIDR range or larger in the Private Traffic Prefix text box (example: 40.0.0.0/23).
 
+Route advertisements to other on-premises (Site-to-site VPN, Point-so-site VPN, NVA) are not impacted by enabling ExpressRoute to ExpressRoute transit connectivity via a security appliance deployedi n the hub.
 
 ### <a name="encryptedER"></a> Encrypted ExpressRoute