fix bookmarks

Author: asudbring

articles/load-balancer/load-balancer-custom-probe-overview.md

@@ -165,11 +165,11 @@ In addition to load balancer health probes, the [following operations use this I
 
 * Don't translate or proxy a health probe through the instance that receives the health probe to another instance in your VNet as this  configuration can lead to cascading failures in your scenario.  Consider the following scenario: a set of third-party appliances is deployed in the backend pool of a Load Balancer resource to provide scale and redundancy for the appliances and the health probe is configured to probe a port that the third-party appliance proxies or translates to other virtual machines behind the appliance.  If you probe the same port you're using to translate or proxy requests to the other virtual machines behind the appliance, any probe response from a single virtual machine behind the appliance will mark the appliance itself dead. This configuration can lead to a cascading failure of the entire application scenario as a result of a single backend endpoint behind the appliance.  The trigger can be an intermittent probe failure that will cause Load Balancer to mark down the original destination (the appliance instance) and in turn can disable your entire application scenario. Probe the health of the appliance itself instead. The selection of the probe to determine the health signal is an important consideration for network virtual appliances (NVA) scenarios and you must consult your application vendor for what the appropriate health signal is for such scenarios.
 
-* If you don't allow the [source IP](#probe-source) of the probe in your firewall policies, the health probe will fail as it is unable to reach your instance.  In turn, Load Balancer will mark down your instance due to the health probe failure.  This misconfiguration can cause your load balanced application scenario to fail.
+* If you don't allow the [source IP](#probe-source-ip-address) of the probe in your firewall policies, the health probe will fail as it is unable to reach your instance.  In turn, Load Balancer will mark down your instance due to the health probe failure.  This misconfiguration can cause your load balanced application scenario to fail.
 
 * For Load Balancer's health probe to mark up your instance, you **must** allow this IP address in any Azure [network security groups](../virtual-network/network-security-groups-overview.md) and local firewall policies.  By default, every network security group includes the [service tag](../virtual-network/network-security-groups-overview.md#service-tags) AzureLoadBalancer to permit health probe traffic.
 
-* If you wish to test a health probe failure or mark down an individual instance, you can use a [network security groups](../virtual-network/network-security-groups-overview.md) to explicitly block the health probe (destination port or [source IP](#probe-source)) and simulate the failure of a probe.
+* If you wish to test a health probe failure or mark down an individual instance, you can use a [network security groups](../virtual-network/network-security-groups-overview.md) to explicitly block the health probe (destination port or [source IP](#probe-source-ip-address)) and simulate the failure of a probe.
 
 * Don't configure your VNet with the Microsoft owned IP address range that contains 168.63.129.16. Such configurations will collide with the IP address of the health probe and can cause your scenario to fail.