fixed refs

Author: wtnlee

articles/virtual-wan/howto-connect-vnet-hub-powershell.md

@@ -18,7 +18,7 @@ Before you create a connection, be aware of the following:
 * A virtual network can only be connected to one virtual hub at a time.
 * In order to connect it to a virtual hub, the remote virtual network can't have a gateway (ExpressRoute or VPN) or RouteServer.
 * To connect a cross-tenant remote virtual network to the virtual hub, refer to [Connect cross-tenant virtual networks to a Virtual WAN hub](cross-tenant-vnet.md).
-* Make sure to check if you'd like to enable [bypass next hop IP for workloads within this VNet](howto-connect-vnet-hub.md#understanding-bypass-next-hop-ip-for-workloads-within-this-vnet) for your connection.
+* Make sure to check if you'd like to enable [bypass next hop IP for workloads within this VNet](howto-connect-vnet-hub.md#bypassexplained) for your connection.
 
 * Some configuration settings, such as **Propagate static route**, can only be configured in the Azure portal at this time. See the [Azure portal](howto-connect-vnet-hub.md) version of this article for steps.
 

articles/virtual-wan/scenario-route-through-nva.md

@@ -102,7 +102,7 @@ In **Figure 2**, there are two hubs; **Hub1** and **Hub2**.
 
 * This scenario doesn't support Secure Hubs with Routing Intent due to the [routing policies limitations](how-to-routing-policies.md#knownlimitations) regarding static routes. However, you can use the [BGP peering feature](scenario-bgp-peering-hub.md) to use indirect spokes together with Secure Hubs with Routing Intent.
 
-* Make sure to review the static routes placed on your VNet Connections and check if [bypass next hop IP for workloads within this VNet](howto-connect-vnet-hub.md#understanding-bypass-next-hop-ip-for-workloads-within-this-vnet) is enabled for your connection.
+* Make sure to review the static routes placed on your VNet Connections and check if [bypass next hop IP for workloads within this VNet](howto-connect-vnet-hub.md#bypassexplained) is enabled for your connection.
 
 ## <a name="workflow"></a>Scenario workflow
 

articles/virtual-wan/scenario-route-through-nvas-custom.md

@@ -177,7 +177,7 @@ To set up routing via NVA, consider the following steps:
 * Portal users must enable 'Propagate to default route' on connections (VPN/ER/P2S/VNet) for the 0.0.0.0/0 route to take effect.
 * PS/CLI/REST users must set flag 'enableinternetsecurity' to true for the 0.0.0.0/0 route to take effect.
 * Virtual network connection doesn't support 'multiple/unique' next hop IP to the 'same' network virtual appliance in a spoke VNet 'if' one of the routes with next hop IP is indicated to be public IP address or 0.0.0.0/0 (internet).
-* Make sure to review the static routes placed on your VNet connections and check if [bypass next hop IP for workloads within this VNet](howto-connect-vnet-hub.md#understanding-bypass-next-hop-ip-for-workloads-within-this-vnet) is enabled for your connection.
+* Make sure to review the static routes placed on your VNet connections and check if [bypass next hop IP for workloads within this VNet](howto-connect-vnet-hub.md#bypassexplained) is enabled for your connection.
 * When 0.0.0.0/0 is configured as a static route on a virtual network connection, that route is applied to all traffic, including the resources within the spoke itself. This means all traffic will be forwarded to the next hop IP address of the static route (NVA Private IP). Thus, in deployments with a 0.0.0.0/0 route with next hop NVA IP address configured on a spoke virtual network connection, to access workloads in the same virtual network as the NVA directly (i.e. so that traffic doesn't pass through the NVA), specify a /32 route on the spoke virtual network connection. For instance, if you want to access 10.1.3.1 directly, specify 10.1.3.1/32 next hop 10.1.3.1 on the spoke virtual network connection.
 * To simplify routing and to reduce the changes in the Virtual WAN hub route tables, we encourage using the new "BGP peering with Virtual WAN hub" option.