done

Author: wtnlee

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

@@ -107,7 +107,7 @@ Consider the following configuration where Hub 1 (Normal) and Hub 2 (Secured) ar
 
 * Routing Intent simplifies routing by managing route table associations and propagations for all connections (Virtual Network, Site-to-site VPN, Point-to-site VPN, and ExpressRoute). Virtual WANs with custom route tables and customized policies therefore can't be used with the Routing Intent constructs.
 * Encrypted ExpressRoute (Site-to-site VPN tunnels running over ExpressRoute circuits) is supported in hubs where routing intent is configured if Azure Firewall is configured to allow traffic between VPN tunnel endpoints (Site-to-site VPN Gateway private IP and on-premises VPN device private IP). For more information on the required configurations, see [Encrypted ExpressRoute with routing intent](#encryptedER).
-* For deployments where static routes are specified on a Virtual Network connection, the **bypass next hop setting** that is configured on the Virtual Network connection is ignored and is considered to be set to **bypass/equals**. This means that if the connected Virtual Network address space (corresponding to the connection with the configured static route) is a subnet within the configured static route on the Virtual Network connection, traffic destined for the Virtual Network will be inspected by the security appliance in the Virtual Hub and routed **directly** to the destination IP in the spoke Virtual Network. Traffic will **bypass** the next hop IP configured in the static route. For a detailed example of this routing behavior, see **traffic behavior with Bypass Next Hop IP enabled** in the [bypass next hop IP](howto-connect-vnet-hub.md#bypassexplained) document.
+* For deployments where static routes are specified on a Virtual Network connection with **proagate static routes enabled**, the **bypass next hop setting** that is configured on the Virtual Network connection is ignored and is considered to be set to **bypass/equals**. This means that if the connected Virtual Network address space (corresponding to the connection with the configured static route) is a subnet within the configured static route on the Virtual Network connection, traffic destined for the Virtual Network will be inspected by the security appliance in the Virtual Hub and routed **directly** to the destination IP in the spoke Virtual Network. Traffic will **bypass** the next hop IP configured in the static route. For a detailed example of this routing behavior, see **traffic behavior with Bypass Next Hop IP enabled** in the [bypass next hop IP](howto-connect-vnet-hub.md#bypassexplained) document.
 * The following connectivity use cases are **not** supported with Routing Intent:
   * Static routes in the defaultRouteTable that point to a Virtual Network connection can't be used in conjunction with routing intent. Instead of using static routes on the defaultRouteTable, you  you can use the [BGP peering feature](scenario-bgp-peering-hub.md) or apply static routes on the Virtual Network connection with "static route propagation" enabled. Routes learnt via BGP or specified as a static route on a Virtual Network connection **are applied** to the next-hop resource specified in private routing policies.
   * The ability to deploy both an SD-WAN connectivity NVA and a separate Firewall NVA or SaaS solution in the **same** Virtual WAN hub is currently in the road-map. Once routing intent is configured with next hop SaaS solution or Firewall NVA, connectivity between the SD-WAN NVA and Azure is impacted. Instead, deploy the SD-WAN NVA and Firewall NVA or SaaS solution in different Virtual Hubs. Alternatively, you can also deploy the SD-WAN NVA in a spoke Virtual Network connected to the hub and leverage the virtual hub [BGP peering](scenario-bgp-peering-hub.md) capability.